Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
You might be reading this and about to flag it as a duplicate but wait. It's different from the others. I am wondering if I can use QT, under the LGPL 2.1 license. For single client programs. The programs are only made for one company to use.
Will LPGL be ok?
The basic point of LGPL is that you can freely build anything on top of it as long as you are linking dynamically against the original binaries. Once you modify the library itself, you need to obey LGPL and distribute the code (but only for the library itself).
There are some distribution quirks, but invoking the library installation from your install program was OK.
LGPL license is not about being commercial or not, it's about licensing the source code. In short:
You can keep your own code to yourself
If you modify any of the Qt code, you need to provide the source code of those changes to the client, that "one company" you mention. The modifications need to be licensed under LGPL (which means they can give it to anyone else if they want).
You're saying it's for internal use in one company (I'm assuimg your own - else there'd be two comapnies). That means you're not redistributing, just using. This is perfectly fine: LPGL gives you unrestricted rights to use. LGPL restrictions are only effective when distributing the application.
The precise quote is found in clause 0: "The act of running a program using the Library is not restricted"
Take the License to a lawyer to read. You don't want to violate the terms and then have to say that "stackoverflow said it was ok".
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
As far as I know C++ is an ISO standard, so they provide some sort of standards and list of features to be implemented for the coming release.
Is it the case that every platform owner will go and write their own implementation for those standards?
Or is there any core compiler code which is implemented once and then every other platform will write wrappers around it?
Or do they write their own C++ compiler from scratch?
Yes and no. Compiler basically consists of two parts: parser (a.k.a front-end) and code generator (a.k.a. back-end). Parser is responsible of recogninizing C++ grammar. Code generator constructs machine code for target platform (hardware type and operating system) based on information it gets from parser. While parser is platform independent, code generator part is tied to target platform. So, in order to support a new platform, one can reuse existing parser part, but has to write new code generator part.
Basically what ISO standards set is set of rules that should be followed by the compiler vendors.
But these are the standards for implementation and not the actual implementation.
Every major hardware vendor knows how to use its own hardware best
This includes aspects like
1) ABI support - This include things like binary formats, system calls and other interfaces
2) Shared Libraries.
3) Architecture Support.
So Microsoft, IBM, Intel, Oracle, and HP all have their own C++ compilers, which create optimal code on their latest hardware.
Standards, however do provide the draft that has to be purchased
https://isocpp.org/std/the-standard
The following table presents compiler support for new C++ features. These include C++11, C++14, C++17, and later accepted revisions to the standard, as well as various technical specifications.
http://en.cppreference.com/w/cpp/compiler_support
Likely once they where created platform specific, put simple a windows exe or com file wont run on linux, however later versions can be compiled trough older versions.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I want to create a standalone C++ desktop application which will be close-source, commercial and will not require the user to have the required DLLs in the machine.
It has, at least, to work for Windows. If it can be built for all platforms, that would be awesome.
This means I do not want the application to use the .NET Framework and all required DLLs must be shipped with the (only) executable the client will download.
I found and tested a dummy MFC application, it seems possible to do everything I require, but every comment I hear about MFC is that it is bad designed, about to be obsolete, bad choice, hard to use, etc etc etc.
I see lots of people recommend Qt, but I read that I can't ship the library unless I pay a commercial license, or the application has to be open-source.
wxWidgets, from what I read, seems to follow the same bad design of MFC.
However, many of the comments I read seem to be for years ago. It seems that Qt has changed its license, so something may have changed in the meanwhile.
If you were me and had these requirements, what framework/library would you pick and why?
I see lots of people recommend Qt, but I read that I can't ship the library unless I pay a commercial license, or the application has to be open-source.
This is wrong. Qt is available under the LGPL license, which means you absolutely can ship your application closed-source, as long as you provide a way for the end-user to be able to modify/update the Qt dependency. Typically this means using a shared Qt library and deploying the DLL files with your application, so that the end-user can replace the DLL files if they wanted to. However it is also possible to link statically in which case you must provide a way for your end-users to re-link it. This means that you'd have to ship compiled code (object files) with your application as a minimum. Note: I'm not a lawyer, and you should thoroughly investigate the license terms yourself before you make any decision.
However, many of the comments I read seem to be for years ago. It seems that Qt has changed its license, so something may have changed in the meanwhile.
As far as I can tell, Qt added LGPL as one of the available licenses in version 4.5 which was released in March 2009. So yes, those comments are almost 4 years out of date.
Note: Apart from the specific points I've addressed, it is hard to answer your question more generally for two reasons - (1) this site considers posts asking for recommendations to be off-topic, and (2) you've said, "if you were me and had these requirements, what framework/library would you pick and why", but you haven't actually said what those requirements are - it seems apparent that you want the library to be able to do GUIs, but what else? There are many different frameworks and libraries for C++ and they all do different things.
I really don't see what's the problem with Qt. I agree with what JBentley said - it implies that it would be in fact a good choice if you're looking for a modern framework. Qt offers much more functionality than MFC.
There is no problem shipping commercial, closed-source, statically linked applications that use Qt. Been there, done that, and it works just fine. Single .exe is all you provide. I'm not a lawyer, but generally what you need to provide on request is a static .lib file generated from your code's object files, so that it can be re-linked by the end user with their own copy of Qt.
There's nothing bad about that from a commercial standpoint -- if you can't afford the cost of a commercial Qt license, the requirement to make a .lib file if your compiled closed-source code shouldn't be a big deal. Make it a part of your build process, so that it's not an extra burden. You don't need to distribute this .lib file, just provide it on request. It doesn't have to be recompiled for the requester's platform or anything like that - whatever compiler you use to compile Qt and your application is all you need.
If one is serious about it, one will ask an IP lawyer to explain the implications of the licensing terms of any software you intend to redistribute with one;s product. So it doesn't matter if it's Qt or MFC, one goes and asks a lawyer. It's not like somehow LGPL implies "go to a lawyer", but a possibly much more complex Microsoft license doesn't. Unless one's stance is that it's OK to ignore MS licenses, but not OK to ignore FSF licenses :/
Have a look at these: http://en.wikipedia.org/wiki/List_of_widget_toolkits
Maybe SmartWin++? http://en.wikipedia.org/wiki/SmartWin%2B%2B
Cheers
MFC is alive and well and will meet your requirements. I (still) use it frequently. If your app GUI is basic and does not need most of the MFC features then ATL would be a very good choice. Both MFC and ATL can be statically linked so no DLLs need to be shipped with the app.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I would like to know generally what the process is to deliver a C++ application (binaries only, not source code) to a customer in the commercial world.
For example, what kind of documentation is generally delivered when only the binaries are delivered (a VDD, SVD, README, etc. etc.???).
What kind of documentation is delivered when both, the source code and the binaries are delivered?
I have always worked on DoD programs, and normally a VDD/SVD is delivered along with the source code. The VDD/SVD includes instructions on how to build binaries from the source code, so normally a list of binaries is not required to be on the VDD/SVD.
For commercial customers not getting the source code (only binaries), what is normally delivered in terms of documentation?
THanks.
If you are delivering binaries only, there should be a manual describing all the use cases for the user and a description of all the files and processes (including installation and removal) an administrator should be aware of without going into details about the source.
If you deliver the source, you should export Doxygen code comments, or whatever equivalent you are using, into a some mutually agreed upon format. There should also be a description of how the source is organized if it does not appear in the code comments somewhere. This in addition to the manuals.
This information is from my personal experience about what keeps customers happy. I do not really know what is "normal" per se.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I would like to write my own LDAP client under Linux, specific to our local environment. Most probably I will use QT4 to provide a shiny frontend without much hassle.
I found that there seems to be no standard C++ library for this. OpenLDAP provides a C API and there should also be a C++ API (experimental?) somewhere..
Do I need to use the C stuff or is there a C++ API out there worth of recommendation?
I've actually written a C++ wrapper for OpenLDAP's C API for my day job and it wasn't my most enjoyable experience.
I didn't find a suitable C++ wrapper out there for my purposes (this was in 2006 so things may have changed since). I wound up directly interacting with the C api, which wasn't terrible but it does have some oddities. Assuming you go to the C/OpenLDAP route I can offer you a couple of tips.
Something that I found a little weird, the C API is defined in RFC1823 which means that pretty much every library has the same API.
In the case of OpenLDAP however a number of the RFC1823 API calls have been deprecated, particularly around the authentication parts. Depending on who distributed your OpenLDAP library and what version it is will determine if these deprecated functions have been disabled.
The main changes to avoid the deprecated API are switching from ldap_init() and ldap_open() to ldap_initialize() and using ldap_sasl_bind() (which confusingly handles all types of auth)
I found following c++ wrapper useful. Open Source C++ wrapper
This question is not easy to answer without knowing specifics of libraries you need.
I would say if C++ library based on Qt and available in source code - that'd be the front runner for sure. And if C++ library depends on some other not-Qt framework - don't even try to mix it with Qt.
C-based libraries generally have less dependencies, though a bit awkward and require more attention to details (initialization / deinitialization) comparing to C++ (destructing class usually means releasing all tied to it resources).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I was looking at Qt and came to wondering, what is the most popular general purpose C++ framework, and what are some pros and cons of it?
The STL and Boost are both pretty popular, and they're pretty much the epitome of "general purpose".
Qt is very popular. It's available under open-source (LGPL) and commercial licenses, has fully-featured core and GUI class libraries and an integrated IDE and build system. It's also cross-platform.
It's under very active development and has a new declarative UI library (QtQuick including QML) due in the next release (4.7).
Definitely worth checking out for new projects.
For Windows-only work MFC is still worth a look. It's recently been updated.
The question as it stands is probably unanswerable; you'll probably end up with a list of people's interpretation of "framework" with no real way for distinguishing them.
Perhaps we need a definition of framework? I suggest it is a library that in some way determines the architecture of an entire application. However that is perhaps a definition of "Application Framework", but if you mean the term more broadly, then the question is probably too broad. This definition however makes say Qt a framework, while Boost remains just a library. That makes Boost no more or less useful, so I really don't understand what you are trying to discover from the question.
Here's a list of UI related libraries that might be considered "frameworks":
MFC
.Net
WxWidgets
Qt
KDE
GNOME
TurboVision ;-)
The most notable distinguishing feature is that some of them are cross-platform, and some are platform specific. Gnome is perhaps distinguished by having a C API (GTK+). .Net supports multiple languages, but requires C++/CLI rather than ISO C++ (but that is no worse than Qt's pre-processor IMO). MFC is a bit long in the tooth and not supported by free or third-party tools. TurboVision is antique and included for my amusement and geek nostalgia.
I know this post is old but I found it very useful.
I would like to add PoCo (POrtable COmponents) to the list
I used it for seleral projects and includes a consistent and well designed framework for:
XML
Multi threading
Networking
Cryptography
General purposes
It is also portable (I used it on Windows and Unix).