C++11 and third party libraries - big issues

I really think the C++ standard's commitee is doing it wrong. They move slowly and they decide to add important libraries 10 years later than they actually should have been added. And look what kind of a situation this has created.

There are frameworks (MFC, Qt, etc) that have their own string classes, STL classes (Qt duplicates the STL - why oh why?), thread classes, networking classes. Where does std::thread fit in all this? Next they plan to standardize filesystem and networking libraries based on Boost.Filesystem and Boost.Asio - will probably take 5-10 years again.

This strategy doesn't do any good. By the time they realize that it's time to add more standard libraries, there are tens of 3rd party libraries with the same functionality - and they usually don't integrate well.

Languages like Java and C# seem to think about what the current trend is - programmers want to write networking code, let's offer them libraries to do it. With C++ it's like "Hey, people have been writing networking code for 30 years, every other languages has in-built support for it - it's about time we supported it too.".

Thank you captain hindsight? Are you just complaining about C++ and how Java is better?

Quote:

---

Originally Posted by Chris_F

Thank you captain hindsight? Are you just complaining about C++ and how Java is better?

---

No, C++ is a nice language, but the standard's committee are doing it completely wrong. What kind of a strategy is this? To add libraries 20 years too late when every codebase out there uses 3rd party alternatives - just to create a mess.

If you want to write code which can be easily adapted to a future standard, use Boost. That's where most of the new standard libraries come from, after all. It makes sense to me to have a "proving ground" like Boost where the community can play around with concepts and iron out the wrinkles, before finally standardizing. I agree it takes ridiculously long though.

Use of an alternative library is an intentional choice. Do you have a good reason for it? If so, cool, that reason is likely to still be valid even if a standard alternative becomes available.

I agree that it's somewhat annoying to have to deal with all these libraries that do essentially the same thing; but at the same time, it's nice to have options. Not every library is going to do things in exactly the same way, and those minor variations are where you find innovation.

What you don't understand that some of the main consumer of C++ are industries, whose development cycles that can be decades (!) long. A lot of them have C code that were written 30 years ago that are still in production. Maybe standardization is slow, but it is stable. I'm still working on projects that don't support templates because our supplied compilers don't handle them.

Java is how old again? And how many versions do we have? How many things that were original available in java are deprecated now? Does your java 1.1 code run with the java 1.6 JRE?

Nobody said C++ development is fast or easy. But it has been working for 3 decades now. This is what the community is trying to preserve.

Quote:

---

Originally Posted by Bssldr

Languages like Java and C# seem to think about what the current trend is - programmers want to write networking code, let's offer them libraries to do it. With C++ it's like "Hey, people have been writing networking code for 30 years, every other languages has in-built support for it - it's about time we supported it too.".

---

The problem with adding things too hastily is of course that you end up with deprecated stuff in the standard that needs to be supported forever even though there are better alternatives. Take a look at how many different approaches there are in C# to read an XML file. Having to figure out which of a handful of methods/approaches is still relevant certainly doesn't make a language easier to use IMO.

Quote:

---

Originally Posted by monarch_dodra

What you don't understand that some of the main consumer of C++ are industries, whose development cycles that can be decades (!) long. A lot of them have C code that were written 30 years ago that are still in production. Maybe standardization is slow, but it is stable. I'm still working on projects that don't support templates because our supplied compilers don't handle them.

Java is how old again? And how many versions do we have? How many things that were original available in java are deprecated now? Does your java 1.1 code run with the java 1.6 JRE?

Nobody said C++ development is fast or easy. But it has been working for 3 decades now. This is what the community is trying to preserve.

---

The length of development cycles is totally irrelevant. If some industry wants to write code according to a specific standard, there's no one forcing them to use a newer compiler. However, there are people who like to write code in the present world, not in the past. Also, it's funny how most new projects are done in Java/C# and the industry seems to prefer productivity over outdated stable standards.

I guarantee you, everything will eventually be added into C++ - I'd say by 2020 they'll be discussing about adding a GUI library. If they end up adding everything, why this delay? Why is the standard 10-20 years behind in time?

I haven't written Java for a long time, but all class files for earlier JVM versions should run in the newer ones. And you can even compile for older JVMs using the 'target' option of javac. C++11 also deprecates quite a few things.

EDIT:
C++98. Were people writing multithreaded filesystem and networking aware applications at this time? Yes, yes, yes.
*13 years of heavy mindwork*
C++11. Only multithreading gets added.

In fact networking (I think also filesystem) was dropped due to this ridiculous 13 year long mindwork, they just wanted to get done with the standard. It amazes me how this huge amount of members in the standard's committe can't do what smaller design teams do in a few years. If I'm not mistaken the C# (language only) design team consists of less than 10 people.

What you may not be getting is that the C++ standard library is not meant to encompass every single bit of functionality. It is meant to provide a toolbox of useful things, but only to a point. Anything which is particularly specialized, you are supposed to find a 3rd-party library for.

I don't think a GUI library will ever be standard, for instance.

Quote:

---

Originally Posted by Lindley

What you may not be getting is that the C++ standard library is not meant to encompass every single bit of functionality. It is meant to provide a toolbox of useful things, but only to a point. Anything which is particularly specialized, you are supposed to find a 3rd-party library for.

I don't think a GUI library will ever be standard, for instance.

---

I'm quite confident they'll eventually add a GUI library, but of course not 100% confident. They probably also thought in 1998 that they'll never add networking, filesystem, threading. I hope they'll do a better job on predicting the future from now on.

C++ better never have a standard GUI library purposed. C++ like C is meant to be portable to any system. I can compile C++ for a 8-bit microcontroller. How exactly is a GUI library supposed to be ported to that?

If you want a language with a standardized way of doing everything from rendering GUI windows to wiping your tush, then stick with Java or C#. Java is a runtime environment and C# is based on .NET, which is a framework. C++ is simply a language and the standard library is simply a collection of useful tools, and I think you don't understand that.

Quote:

---

Originally Posted by Chris_F

C++ better never have a standard GUI library purposed. C++ like C is meant to be portable to any system. I can compile C++ for a 8-bit microcontroller. How exactly is a GUI library supposed to be ported to that?

If you want a language with a standardized way of doing everything from rendering GUI windows to wiping your tush, then stick with Java or C#. Java is a runtime environment and C# is based on .NET, which is a framework. C++ is simply a language and the standard library is simply a collection of useful tools, and I think you don't understand that.

---

Perhaps the GUI example was a bit extreme, but I think you're stuck with the old definition of C++. C++ is nowadays rather an application programming language than a low level language for systems programming. Search around and see what is expected to be in TR2: networking, filesystem, xml support, etc.

The problem is how the standard's committee works. When networking support is added, it's only a matter of time when they introduce a crypto library. But all this could have been done earlier. Would make more sense to introduce libraries when there's demand for them, not wait decades to realize that the standard library is in stone-age compared to other languages.

C++ is in heavy use in many many many many different systems. You forget that and think desktop and server code is dominating what C++ does. That's not the case, for every server that's running code written in C++, there is 10 embedded devices with c++ written code. Embedded devices rarely multitask, they rarely have file systems, they rarely do networking.

Also, one of the major advantages to third party libraries is that their code gets used by everyone so they get optimized really well. Everyone uses the same zlib code for instance, whereas each compiler implements their own std::string. One codebase = fewer bugs, more optimized code. Remember VC++6's string implementation problem?

And fyi, for most things there are not lots of third party libraries:
networking: everyone uses libcurl
threading: everyone uses pthread or Boost
xml: everyone uses libxml2 or tinyxml
graphics: everyone uses OpenGL or Allegro
sound: everyone uses OpenAL
pngs: everyone uses libpng
movies: everyone uses ffmpeg

There are one or two third party libraries that 99% of programmers use so they become the standard, it's not a huge cluster**** like you seem to be implying. C++ is a language, not a framework. Those are two very different things. FYI "java" is a language, it does not have any of the tools you mentioned. It comes with swing, which is a FRAMEWORK.

Quote:

---

Originally Posted by Bssldr

When networking support is added, it's only a matter of time when they introduce a crypto library.

---

As soon as you add crypto to the standard, you get stuck with encryption methods needing to be in the library forever, even after they're broken and useless.

Quote:

---

Originally Posted by Lindley

As soon as you add crypto to the standard, you get stuck with encryption methods needing to be in the library forever, even after they're broken and useless.

---

Good point, C++ is almost always backwards compatible. Very few things get deprecated, whereas java has loads of functions and classes marked as deprecated. I'm pretty sure the entirety of awt has been deprecated and replaced with swing (maybe its the other way around.) They will either some day take awt out and break tons of projects, or have to leave it in and start bloating java.

There are also often cases where you want options. Some libraries are just designed for different things even though they offer the same functionality. Some libraries give you high level functionality but hide the details which makes it easy to use, but makes it rigid, some give you the basic chunks and you put them together yourself, which provides more flexibility. The good ones tend to offer both.

Quote:

---

Originally Posted by Chris_F

C++ better never have a standard GUI library purposed. C++ like C is meant to be portable to any system. I can compile C++ for a 8-bit microcontroller. How exactly is a GUI library supposed to be ported to that?

---

Easy: they just leave it out for the set of required libraries for freestanding environment implementations.

I suggest watching the 2nd day keynote (by Herb Sutter, member of the standard's committee) of the ongoing GoingNative 2012 conference. In the last part of his talk he points out that the biggest weakness of C++ is the too small standard library (he compared it to C#/Java that have tens of times bigger standard libraries). According to his words the standard's committee is going to work together with big companies/organizations/library vendors like Boost, Poco, Qt, Adobe, Microsoft, Google, Facebook, etc to deliver more useful consistent libraries during the next few years. He mentioned that what the committee has in mind are: filesystem, networking, serialization, HTTP, HTML/XML/JSON, compression, cryptography, audio/image/video manipulation, database interaction, etc.

This shows that the criticism against a too small standard library is justified, the standard's committee has itself realized that fact. For those who think that C++'s standard library is supposed to be tiny and you are supposed to get your libraries from the outer space, you're wrong. Won't stay that way.

Maybe so but that doesn't make the language a bad one. After all, in my opinion both C and C++ have proven that they keep being good enough compared to other languages to earn their place as still being very popular languages.

Quote:

---

Originally Posted by Bssldr

For those who think that C++'s standard library is supposed to be tiny and you are supposed to get your libraries from the outer space, you're wrong.

---

No, it simply means there is s difference of opinion. As it's been stated many times in this thread, C and C++ have been around decades longer than C# and Java. They still serve their purpose just as well as they always have. Lets see if either C# or Java can stand the test of time half as well.

I agree with Chris_F, just consider that the standard committee rarely votes unanimously on key decisions ( see the c++11 concept proposal, for instance ).

as other said, what makes a library or a framework different from the standard library is that the latter should be stable in time. You can abandon a library if it gets out-of-date or if better libraries are developed ( how many libraries have been developed during the years ? how many of them have survived ? ). But this is unacceptable for a standard library.
This does not mean that the STL should be tiny, this just means that in order to be included in the STL a design must reach that level of (supposed) generality and robustness guaranteeing wide adoption both in space and in time.

Now, given that the robustness and stability of a design depends firstly on the stability of its usage scenarios, this automatically implies some delay on the standardization process: for example, in order to design a standard GUI library you need a sufficiently stable UI usage pattern and a well proven UI software design. And we have neither of them: user interfaces are evolving continuously and there is a proliferation of UI libraries, each with its own design spirit, each with its own pros and cons and usage base. At present, the very idea of UI is not sufficiently mature to be standardized effectively, IMHO.

And in any case, an hypothetical standardized GUI library would not resemble existing "omnipotent" GUI frameworks, it would probably present an abstraction of a GUI system leaving to the implementation or user/OS provided components things like user input systems, graphical elements, etc ... in the same way as STL streams provide an abstraction of buffered character based data exchange.

For example, consider the recently standardized regex library: its design is totally indipendent on regex syntax; the implementation guarantees support for some selected grammars ( like the ecmascript regex standard ), but it would nicely support any new grammar you like, the only requirement being that a "regular expression" should be able to split and match char patterns in a consistent way. Do you see the difference ?
My string processing code relying just on the standard regex interface will work effortlessly with that new grammar as well ... but this is possible only thanks to the stability of the library interface, that is guaranteed to remain immutable or backward compatible, or at least at a guarantee level given by the top-experts at the time of standardization.

Of course, if you are not capable of exploiting the value of stl ( for example, by mixing code using iostream and c style io, mixing code processing regex result exrtaction with regex expressions manipulation, writing code not respecting standard guarantees, etc ... ) then all this will appear to you as a pointless waste of time ...