March 21, 2013 at 15:04Comparison of C ++ Standard and Boost
- Transfer
Should the C ++ community adhere to or depart from the standard in order to create better things with Boost?
Wait, the wrong library.
In March 2011, the ISO C ++ committee approved the final draft of the latest C ++ standard. A language that was officially standardized in August of that year and became known as C ++ 11. Now, after 2 years, we can look back and look at some of the problems affecting the language (already since the adoption of the first international standard in 1998) and Compare its final version with the popular C ++ Boost library.
With the first version of the standard, C ++ included the official specification of the library. Prior to this, various organizations and individuals created their libraries, sometimes based on templates and providing various types of containers, such as a vector or a stack. One such library that deserved ANSI / ISO's attention was the Standard Template Library (STL), launched by a guy named Alexander Stepanov. But at that time there was no standard for the language itself, and various suppliers of compilers had the opportunity to interpret it as they pleased. (I remember how in the mid-90s it was possible to "reset links" with the Borland C ++ compiler, which is now impossible with the release of the standard).
Templates were a separate problem, as vendors implemented them in different ways. However, the advent of STL filled an important gap in C ++, in particular, the need for well-defined and well-tested container classes. But so that life does not seem like honey, various STL implementations soon appeared. I remember how I used the version from HP (which was one of the original ones), and my company at the same time chose the version from Silicon Graphics. At the same time, this wonderful library from Rogue Wave Software existed, which included tons of additional classes - some based on templates, some not; it was one of the most popular commercial libraries of the time and was somewhat reminiscent of STL. An important point: none of these libraries were interchangeable. You couldn’t just take it and replace "#include" to another library and expect that everything will work, even if it is assumed that the same classes and functions are used. They simply were not compatible. The fact that 2 libraries implemented the “vector” class, based on the original STL, did not mean that it was the same.
Then in 1998 a standard came out that included its own library specification, called the Standard Library. It looked a lot like STL and was actually based on it. Although it was part of the language specification, the Standard Library was not part of it in the sense that it was not built into the compiler. The library was a specification for a set of classes that vendors could develop in C ++ and ship with the compiler. This meant that you could ignore the Standard Library if you wanted, and use some other instead - which was what most organizations did, including the one I worked in, a young engineer who created software for the telecommunications industry. At this company, the programmers who worked before me used the STL version of Silicon Graphics, and it took a lot of effort, to move away from it and replace it with the Standard Library implementation. Of course, in 1999 we switched to the latest versions of compilers and made many changes, after which the vendors proudly announced that their compilers now comply with the standard, which meant that most of the code we wrote was not always compiled by new compilers.
And so, software developers were forced to choose when they started new projects: use the Standard Library or the proven STL, and if STL, which version? Or stop at a great commercial library like Rogue Wave? They also understood that once they chose one of them, they would be forced to use it for a long time. As for the Standard Library itself, compiler vendors often created their own version, which did not always match the original.
It was a complete mess. And partly, the problem was (and now is) the standardization process itself. The STL was first demonstrated to the Committee on Standardization in 1993, but 5 years passed before the standard came out. In the interval, there was not even a standard for the language itself, not to mention libraries, so compiler vendors received not only the freedom to create libraries, but the language itself. Around 1996, the mess reached its climax. Borland included many new features in its version of C ++, but it was not possible to simply compile their code with another compiler. And if you wanted to use STL, you had to find the version that was ported to your compiler.
By 1998, most vendors had updated their compilers in accordance with the standard, but this did not help much, because A huge amount of code was written for earlier versions. In fact, some companies could not upgrade to new compilers because their old code would stop compiling. A lot of things happened over 6 years in the computer world, and compiler vendors continued to release new versions, despite the upcoming standard.
Little has changed in this process. In 2006 (3 years after a small update), it seemed the new C ++ standard should become a reality. It finally came out in 2011. A lot of time has passed.
In the early 2000s, the new library was gaining popularity - Boost.
Boost is a set of C ++ libraries that fill in various gaps not only in the Standard Library, but also in the language itself, moving it forward. C ++ came out in 1983, after 4 years of development, and was based on C, which came out in 1972.
Let's be honest: despite the fact that I really like C ++ and even still use it (especially for multi-core programming, which is one of my freelance projects), the fact is that the more time you spend with modern languages, such like Java or Python, the more you find useful features built directly into the language - features that are still not part of C ++. Hell, the string type is still not built into the core of the language, but implemented as a template in the Standard Library. The language itself is still based on symbolic pointers and links. If you need a string, you should use one of the libraries and often call the c_str () method of the string class to get a pointer to a character, because string is not natively embedded in the language, not to mention things like list or dictionary. Want a list in Python? Just type “a = [1,2,3]”. Done.
As for more advanced things, like lambda functions (which are also natively supported by many languages) - this is where libraries like Boost will be useful.
Of course, the fundamental difference between C ++ is that it is fully compiled. But this is an argument with which one can argue to nausea whether C ++ is better and faster than modern dynamic languages, both with JIT compilation and without it.
The Boost library ultimately serves several purposes: first, it provides programmers with both advanced things, such as functional programming, and basic things like smart pointers. Secondly, it is a kind of incubator for new language features that can become standard.
Right on the main page of Boost , it was noticed that 10 libraries from its composition were included in the C ++ 11 standard. Yes, and it was released in 2003 - 10 years ago, long before the adoption of the standard.
Because adoption of the 2011 standard took so much time, many developers started using Boost (or completely abandoned C ++). So let's compare Boost with the Standard.
The C ++ 11 standard includes several changes in the language itself (for example, the template compilation mechanism has been put in order, which allows the use of "external templates", but how easy it is to initialize container objects; and even the type determination mechanism mechanism)). But the standard also contains many improvements in the Standard Library.
There is an important caveat mentioned earlier: although the standard includes a description of the Standard Library, it does not include the implementation of either the compiler or the language. All this is left to the conscience of third parties, such as compiler providers. There is no reference implementation. A standard is not a code, it is a description .
Also, one thing you need to know about Boost is that it actually consists of several libraries, and its designers deliberately divided them. This means that you can use only those libraries from Boost that you need. There are several interdependencies there, but they are well documented. This way you can combine Boost with the Standard Library if necessary. For example, the good old iostream have been part of the Standard Library since the first 1998 standard, and Boost easily works with them (but also includes its own iostream, if you prefer).
But Boost is, in fact, much more than the Standard Library. It contains about 175 classes, and the current version at SourceForge (1.53.0)it takes 93 MB (including documentation, and unpacked .hpp files in the amount of 9000 pieces take 90 MB). There are classes that I personally find incredibly useful in my work, for example, those that belong to the category “Language Features Emulation”. For example, the foreach construct, thanks to the template engine in C ++, allows you to write loops that go beyond the standard C ++ loops, like this:
Although you can easily write code using native loops, there are several reasons why you might want to write them this way. The first is that coding is a little easier. The second is juniors (or even seniors who you think should never be promoted) are less likely to make the same old mistake by writing something like " for (i = 0; i <= length; i ++) " , and then they will still ask you why this code sometimes works, and sometimes it falls inside the functions from which it was called.
Boost also provides a huge assortment of powerful, but highly specialized classes. For example, a few years ago I needed a library for working with graphs. Boost has one. Need a multidimensional array? How about a stack based container? Boost has it all. But what I like most about it is a whole set of good programming patterns and a useful library for working with regular expressions.
But the Boost implementation is not very simple, the developers had to populate the library with compiler-dependent code. For example, the implementation of the foreach construct includes the following code:
This is good for everyone using the library - it will work with most common compilers and completely abstracts from their subtleties.
So, Boost continued to grow, but work on the standard was carried out all the years preceding the 2011th. It contains some nice classes, such as its own regular expression class, which has a lot in common with its Boost counterpart.
But what about the standard? Let's look at it from the point of view of vendors. C ++ standards took years to get finished. The 1998 standard was important because it established many fundamental aspects of the language, such as templates or links. This made the lives of library creators much easier. But compilers are still different, as evidenced by compiler-dependent macros in Boost. In part, this is the fault of vendors who did not literally follow the standard, but also because of the random uncertainties in the libraries themselves.
During the several years preceding the 2011 standard, several changes were also made to it. Compiler vendors tried to bring their compilers and implementations of the Standard Library, hoping to have already standardized products before the standard was finished. But they shot at a moving target.
Let's take a look at 2 specific compilers: GNU GCC and Microsoft's C ++. According to this table , the current version of GCC 4.8 supports almost all new features, except for two small ones (Rvalue links for "* this" and "minimal garbage collection support"). But the developers made it clear that this support is still in experimental status.
This table is from Microsoft.shows the status in Visual Studio 2012 - there are many "no" and "partial". But pay attention to this small note on the Microsoft page, which gives an idea of what it was dealing with:
Attention here in the language itself. But what about the Standard Library? Microsoft has been involved in the effort to comply with the standard in the very early stages. However, they explained that some of the things in this library depend on new features of the language that they have not yet implemented. And as a result, these aspects of the library were also not implemented. (But they did not indicate which ones).
And here is the GNU implementation of the Standard Library . There are many elements labeled “N” and “Partial”.
10 years passed before the standard began to take shape and it took 2 years for its approval. A lot of changes have occurred during this time, and compiler manufacturers cannot take risks by implementing those features that can be undone later. Not a very nice picture.
Boost, at the same time, made good progress. The developers did a great job making sure their code works with various compilers. Boost is ripe, well tested, and works well. The development process is moving forward without any obstacles from the standardization committee. She continues to evolve.
What about changes to the Standard Library? I already mentioned the regex library, very similar and heavily influenced by Boost. But given the fact that the Standard Library still lacks the implementation of many things from the specification, does it matter? Remember, the C ++ standard is not code, and there is no reference implementation. The standard simply says what the C ++ compiler should do, and what should be in the implementation of the Standard Library. If you want to use the Standard Library, you need to use a third-party product that is often bundled with a compiler, such as the GCC or the Microsoft version. And here's what you actually choose from: GCC or the Microsoft implementation of the Standard Library or Boost, on the basis of which the Standard Library was modeled. And both of these implementations are not complete, and one of them is called "experimental." Which do you prefer to use in your products?
It took the Standardization Committee 8 years to figure out what all the same should be in the standard, and compiler manufacturers would have to wait until everything was settled before publishing their version of the Standard Library. Instead, they published chunks, which were at best alpha versions. And they still haven't finished. At the same time, the real C ++ community is moving on, creating better things like Boost.
In a few years, a new standard will appear. We have already gone through this. Boost will be even better by then.
Wait, the wrong library.
In March 2011, the ISO C ++ committee approved the final draft of the latest C ++ standard. A language that was officially standardized in August of that year and became known as C ++ 11. Now, after 2 years, we can look back and look at some of the problems affecting the language (already since the adoption of the first international standard in 1998) and Compare its final version with the popular C ++ Boost library.
With the first version of the standard, C ++ included the official specification of the library. Prior to this, various organizations and individuals created their libraries, sometimes based on templates and providing various types of containers, such as a vector or a stack. One such library that deserved ANSI / ISO's attention was the Standard Template Library (STL), launched by a guy named Alexander Stepanov. But at that time there was no standard for the language itself, and various suppliers of compilers had the opportunity to interpret it as they pleased. (I remember how in the mid-90s it was possible to "reset links" with the Borland C ++ compiler, which is now impossible with the release of the standard).
Templates were a separate problem, as vendors implemented them in different ways. However, the advent of STL filled an important gap in C ++, in particular, the need for well-defined and well-tested container classes. But so that life does not seem like honey, various STL implementations soon appeared. I remember how I used the version from HP (which was one of the original ones), and my company at the same time chose the version from Silicon Graphics. At the same time, this wonderful library from Rogue Wave Software existed, which included tons of additional classes - some based on templates, some not; it was one of the most popular commercial libraries of the time and was somewhat reminiscent of STL. An important point: none of these libraries were interchangeable. You couldn’t just take it and replace "#include" to another library and expect that everything will work, even if it is assumed that the same classes and functions are used. They simply were not compatible. The fact that 2 libraries implemented the “vector” class, based on the original STL, did not mean that it was the same.
Chaos
Then in 1998 a standard came out that included its own library specification, called the Standard Library. It looked a lot like STL and was actually based on it. Although it was part of the language specification, the Standard Library was not part of it in the sense that it was not built into the compiler. The library was a specification for a set of classes that vendors could develop in C ++ and ship with the compiler. This meant that you could ignore the Standard Library if you wanted, and use some other instead - which was what most organizations did, including the one I worked in, a young engineer who created software for the telecommunications industry. At this company, the programmers who worked before me used the STL version of Silicon Graphics, and it took a lot of effort, to move away from it and replace it with the Standard Library implementation. Of course, in 1999 we switched to the latest versions of compilers and made many changes, after which the vendors proudly announced that their compilers now comply with the standard, which meant that most of the code we wrote was not always compiled by new compilers.
And so, software developers were forced to choose when they started new projects: use the Standard Library or the proven STL, and if STL, which version? Or stop at a great commercial library like Rogue Wave? They also understood that once they chose one of them, they would be forced to use it for a long time. As for the Standard Library itself, compiler vendors often created their own version, which did not always match the original.
It was a complete mess. And partly, the problem was (and now is) the standardization process itself. The STL was first demonstrated to the Committee on Standardization in 1993, but 5 years passed before the standard came out. In the interval, there was not even a standard for the language itself, not to mention libraries, so compiler vendors received not only the freedom to create libraries, but the language itself. Around 1996, the mess reached its climax. Borland included many new features in its version of C ++, but it was not possible to simply compile their code with another compiler. And if you wanted to use STL, you had to find the version that was ported to your compiler.
By 1998, most vendors had updated their compilers in accordance with the standard, but this did not help much, because A huge amount of code was written for earlier versions. In fact, some companies could not upgrade to new compilers because their old code would stop compiling. A lot of things happened over 6 years in the computer world, and compiler vendors continued to release new versions, despite the upcoming standard.
Little has changed in this process. In 2006 (3 years after a small update), it seemed the new C ++ standard should become a reality. It finally came out in 2011. A lot of time has passed.
Boost
In the early 2000s, the new library was gaining popularity - Boost.
Boost is a set of C ++ libraries that fill in various gaps not only in the Standard Library, but also in the language itself, moving it forward. C ++ came out in 1983, after 4 years of development, and was based on C, which came out in 1972.
Let's be honest: despite the fact that I really like C ++ and even still use it (especially for multi-core programming, which is one of my freelance projects), the fact is that the more time you spend with modern languages, such like Java or Python, the more you find useful features built directly into the language - features that are still not part of C ++. Hell, the string type is still not built into the core of the language, but implemented as a template in the Standard Library. The language itself is still based on symbolic pointers and links. If you need a string, you should use one of the libraries and often call the c_str () method of the string class to get a pointer to a character, because string is not natively embedded in the language, not to mention things like list or dictionary. Want a list in Python? Just type “a = [1,2,3]”. Done.
As for more advanced things, like lambda functions (which are also natively supported by many languages) - this is where libraries like Boost will be useful.
Of course, the fundamental difference between C ++ is that it is fully compiled. But this is an argument with which one can argue to nausea whether C ++ is better and faster than modern dynamic languages, both with JIT compilation and without it.
The Boost library ultimately serves several purposes: first, it provides programmers with both advanced things, such as functional programming, and basic things like smart pointers. Secondly, it is a kind of incubator for new language features that can become standard.
Right on the main page of Boost , it was noticed that 10 libraries from its composition were included in the C ++ 11 standard. Yes, and it was released in 2003 - 10 years ago, long before the adoption of the standard.
Because adoption of the 2011 standard took so much time, many developers started using Boost (or completely abandoned C ++). So let's compare Boost with the Standard.
2011 Standard and Boost
The C ++ 11 standard includes several changes in the language itself (for example, the template compilation mechanism has been put in order, which allows the use of "external templates", but how easy it is to initialize container objects; and even the type determination mechanism mechanism)). But the standard also contains many improvements in the Standard Library.
There is an important caveat mentioned earlier: although the standard includes a description of the Standard Library, it does not include the implementation of either the compiler or the language. All this is left to the conscience of third parties, such as compiler providers. There is no reference implementation. A standard is not a code, it is a description .
Also, one thing you need to know about Boost is that it actually consists of several libraries, and its designers deliberately divided them. This means that you can use only those libraries from Boost that you need. There are several interdependencies there, but they are well documented. This way you can combine Boost with the Standard Library if necessary. For example, the good old iostream have been part of the Standard Library since the first 1998 standard, and Boost easily works with them (but also includes its own iostream, if you prefer).
But Boost is, in fact, much more than the Standard Library. It contains about 175 classes, and the current version at SourceForge (1.53.0)it takes 93 MB (including documentation, and unpacked .hpp files in the amount of 9000 pieces take 90 MB). There are classes that I personally find incredibly useful in my work, for example, those that belong to the category “Language Features Emulation”. For example, the foreach construct, thanks to the template engine in C ++, allows you to write loops that go beyond the standard C ++ loops, like this:
int i = 0;
BOOST_FOREACH( i, container )
{
…
}
Although you can easily write code using native loops, there are several reasons why you might want to write them this way. The first is that coding is a little easier. The second is juniors (or even seniors who you think should never be promoted) are less likely to make the same old mistake by writing something like " for (i = 0; i <= length; i ++) " , and then they will still ask you why this code sometimes works, and sometimes it falls inside the functions from which it was called.
Boost also provides a huge assortment of powerful, but highly specialized classes. For example, a few years ago I needed a library for working with graphs. Boost has one. Need a multidimensional array? How about a stack based container? Boost has it all. But what I like most about it is a whole set of good programming patterns and a useful library for working with regular expressions.
But the Boost implementation is not very simple, the developers had to populate the library with compiler-dependent code. For example, the implementation of the foreach construct includes the following code:
# if BOOST_WORKAROUND(BOOST_MSVC, <= 1300)
|| BOOST_WORKAROUND(__BORLANDC__, < 0×593)
|| (BOOST_WORKAROUND(BOOST_INTEL_CXX_VERSION, <= 700) && defined(_MSC_VER))
|| BOOST_WORKAROUND(__SUNPRO_CC, < 0×5100)
|| BOOST_WORKAROUND(__DECCXX_VER, <= 60590042)
# define BOOST_FOREACH_NO_RVALUE_DETECTION
# endif
This is good for everyone using the library - it will work with most common compilers and completely abstracts from their subtleties.
But now there is a different standard
So, Boost continued to grow, but work on the standard was carried out all the years preceding the 2011th. It contains some nice classes, such as its own regular expression class, which has a lot in common with its Boost counterpart.
But what about the standard? Let's look at it from the point of view of vendors. C ++ standards took years to get finished. The 1998 standard was important because it established many fundamental aspects of the language, such as templates or links. This made the lives of library creators much easier. But compilers are still different, as evidenced by compiler-dependent macros in Boost. In part, this is the fault of vendors who did not literally follow the standard, but also because of the random uncertainties in the libraries themselves.
During the several years preceding the 2011 standard, several changes were also made to it. Compiler vendors tried to bring their compilers and implementations of the Standard Library, hoping to have already standardized products before the standard was finished. But they shot at a moving target.
Let's take a look at 2 specific compilers: GNU GCC and Microsoft's C ++. According to this table , the current version of GCC 4.8 supports almost all new features, except for two small ones (Rvalue links for "* this" and "minimal garbage collection support"). But the developers made it clear that this support is still in experimental status.
This table is from Microsoft.shows the status in Visual Studio 2012 - there are many "no" and "partial". But pay attention to this small note on the Microsoft page, which gives an idea of what it was dealing with:
"После утверждения лямбда-функций в Рабочем Документе (версия 0.9) и изменяемых лямбд (mutable lambdas), добавленных в версию 1.0, Комитет по Стандартизации начал переделку. Это привело к появлению лямбд версии 1.1. Это произошло слишком поздно, чтобы быть включенным в Visual C++ 2010, но они есть в Visual Studio 2012."Attention here in the language itself. But what about the Standard Library? Microsoft has been involved in the effort to comply with the standard in the very early stages. However, they explained that some of the things in this library depend on new features of the language that they have not yet implemented. And as a result, these aspects of the library were also not implemented. (But they did not indicate which ones).
And here is the GNU implementation of the Standard Library . There are many elements labeled “N” and “Partial”.
Comparison
10 years passed before the standard began to take shape and it took 2 years for its approval. A lot of changes have occurred during this time, and compiler manufacturers cannot take risks by implementing those features that can be undone later. Not a very nice picture.
Boost, at the same time, made good progress. The developers did a great job making sure their code works with various compilers. Boost is ripe, well tested, and works well. The development process is moving forward without any obstacles from the standardization committee. She continues to evolve.
What about changes to the Standard Library? I already mentioned the regex library, very similar and heavily influenced by Boost. But given the fact that the Standard Library still lacks the implementation of many things from the specification, does it matter? Remember, the C ++ standard is not code, and there is no reference implementation. The standard simply says what the C ++ compiler should do, and what should be in the implementation of the Standard Library. If you want to use the Standard Library, you need to use a third-party product that is often bundled with a compiler, such as the GCC or the Microsoft version. And here's what you actually choose from: GCC or the Microsoft implementation of the Standard Library or Boost, on the basis of which the Standard Library was modeled. And both of these implementations are not complete, and one of them is called "experimental." Which do you prefer to use in your products?
It took the Standardization Committee 8 years to figure out what all the same should be in the standard, and compiler manufacturers would have to wait until everything was settled before publishing their version of the Standard Library. Instead, they published chunks, which were at best alpha versions. And they still haven't finished. At the same time, the real C ++ community is moving on, creating better things like Boost.
In a few years, a new standard will appear. We have already gone through this. Boost will be even better by then.