Comparing C ++ Standard and Boost
Should the C ++ community stick to the standard or move away from it to create better things with Boost?
Wait, not the library.
In March 2011, an ISO C ++ committee approved the final draft of the latest C ++ standard. The language, which was officially standardized in August of the same 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 ++ library Boost.
')
With the first version of the standard C ++ I included the official library specification. Prior to this, various organizations and individuals created their own libraries, sometimes based on templates and providing various types of containers, such as a vector or stack. One of these libraries, which deserved the attention of ANSI / ISO, was the Standard Template Library (STL), started by a guy named Alexander Stepanov. But at that time there was no standard for the language itself, and various compiler vendors had the opportunity to treat it as they please. (I remember how in the mid-90s there was an opportunity to “drop links” with the Borland C ++ compiler, which is now impossible with the release of the standard).
Templates were a problem because vendors implemented them in different ways. However, the emergence of STL has 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 honey, soon there were various implementations of STL. 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 partly resembled STL. The important point: none of these libraries were interchangeable. It was impossible to just take it and replace "#include" with 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 was a lot like the 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 instead use some other one - which was done by most organizations, including the one I worked for, a young engineer who created software for the telecommunications industry. In this company, the programmers who worked before me used the STL version from Silicon Graphics, and it took tremendous effort to move away from it and replace it with a 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 conform to 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 proven STL, and if STL, which version? Or stop at a great commercial library like Rogue Wave? They also understood that once choosing one of them, they will be forced to use it for a long time. As for the Standard Library itself, compiler vendors often created its own version, which did not always coincide with the original.
It was a mess. And partly, the problem was (and now is) the process of standardization. STL was first demonstrated to the Standardization Committee in 1993, but 5 years passed before the standard was released. In the interim, there was not even a standard for the language itself, let alone libraries, so compiler vendors got 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 impossible 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 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 switch to new compilers, because their old code would stop compiling. A lot of things happened in 6 years in the computer world, and compiler vendors continued to release new versions, despite the upcoming standard.
In this process, little has changed. In 2006 (3 years after a small update), it seemed the new C ++ standard should become a reality. He finally came out in 2011. A lot of time has passed.
In the early 2000s, a new library is gaining popularity - Boost.
Boost is a set of C ++ libraries that fill in various spaces not only in the Standard Library, but also in the language itself, moving it forward. C ++ was released in 1983, after 4 years of development, and was based on C, which was released in 1972.
Let's be honest: despite the fact that I love C ++ very much 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 chips built directly into the language — chips 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 references. If you need a string, you must 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 built into the language , not to mention list or dictionary things. Want a list in Python? Just type "a = [1,2,3]". Is done.
As for more advanced things, like lambda functions (which are also natively supported by many languages) - this is where Boost-type libraries will be useful.
Of course, the fundamental difference with C ++ is that it is fully compiled. But this is an argument with which one can argue ad nauseam, whether it is better and faster with C ++ of modern dynamic languages ​​both with and without JIT compilation.
The Boost library ultimately serves several purposes: first, it provides programmers with both advanced things, such as functional programming, and basic ones, like smart pointers. Secondly, it is a kind of incubator for new language features that can become standard.
Right on the main Boost page , it was noted that 10 libraries from its membership were included in the C ++ standard 11. Yes, and it was released in 2003 - 10 years ago, long before the standard was adopted.
Since the adoption of the standard of 2011 took so much time, many developers began to use Boost (or completely abandoned C ++). So let's compare Boost with Standard.
The C ++ 11 standard includes several changes in the language itself (for example, the template compilation mechanism is put in order, which makes it possible to use “external templates” (“extern template”), and how easy it is to initialize container objects; even type definition mechanism)). But the standard also contains many improvements in the Standard Library.
There is an important caveat mentioned earlier: although the standard includes the description of the Standard Library, it does not include the implementation of either the compiler or the language. All this remains on the conscience of third parties, such as compiler suppliers. 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 have deliberately divided them. This means that you can use only those libraries from Boost that you need. There are several interdependencies, but they are well documented. Thus, you can combine Boost with the Standard Library, if necessary. For example, the good old iostream are part of the Standard Library since the first standard in 1998, and Boost works with them easily (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 on SourceForge (1.53.0) is 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 fall into the category of “Language Features Emulation”. For example, the foreach construct, thanks to the template engine in C ++, allows you to write loops that go beyond standard C ++ cycles, like this:
Although you can easily write code using native loops, there are several reasons why you might want to write them in this way. The first is that coding becomes a little easier. Second, 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 ask you why this code sometimes works, and sometimes falls inside the functions from which it was called.
Boost also provides a huge range of powerful but narrowly specialized classes. For example, several years ago I needed a library for working with graphs. In Boost there is such. 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 implementation of Boost is not very simple, developers had to fill the library with compiler-dependent code. For example, the foreach implementation of a 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 the work was carried out over the standard throughout the years preceding 2011. It contains some good classes, such as your own regular expression class, which has a lot in common with Boost-like counterpart.
But what about the standard? Let's look at it from the point of view of vendors. C ++ standards took years to become complete. The 1998 Standard was important because it established many of the fundamental aspects of a language, such as templates or links. This made the lives of library creators much easier. But compilers are still different from each other, 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 irregularities in the libraries themselves.
In the course of 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 standardized products before the standard was completed. 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, with the exception of two small ones (Rvalue links for "* this" and "minimal support for garbage collection"). But the developers made it clear that this support is still in experimental status.
This table from Microsoft shows the status in Visual Studio 2012 - there are a lot of "no" and "partial". But pay attention to this small note on the Microsoft page, which gives an idea of ​​what it dealt with:
Attention here in the language itself. But what about the Standard Library? Microsoft got involved in working to meet the standard in its very early stages. However, they explained that some 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).
But the GNU implementation of the Standard Library . There are many elements labeled "N" and "Partial".
It took 10 years before the standard began to form and it took 2 years to approve it. A lot of changes happened during this time, and compiler manufacturers cannot risk implementing those features that can be later canceled. Not a very nice picture.
Boost, at the same time, well advanced. The developers did an excellent job, making sure their code works with different compilers. Boost is ripe, well tested and works well. The development process is moving forward without any hindrance from the standardization committee. It continues to evolve.
What about changes to the Standard Library? I already mentioned the regular expression 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 this 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 Standard Library implementation. If you want to use the Standard Library, you need to use a third-party product, often bundled with a compiler, such as GCC or a Microsoft version. And this is 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 one would you prefer to use in your products?
It took the Standardization Committee 8 years to figure out what should still be in the standard, and compiler manufacturers would have to wait until everything was settled before publishing their version of Standard Library. Instead, they published pieces that were, at best, alpha versions. And they still haven't finished. At the same time, the present C ++ community moves on, creating better things like Boost.
In a few years, a new standard will appear. We have already passed. By that time Boost will be even better.
Wait, not the library.
In March 2011, an ISO C ++ committee approved the final draft of the latest C ++ standard. The language, which was officially standardized in August of the same 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 ++ library Boost.
')
With the first version of the standard C ++ I included the official library specification. Prior to this, various organizations and individuals created their own libraries, sometimes based on templates and providing various types of containers, such as a vector or stack. One of these libraries, which deserved the attention of ANSI / ISO, was the Standard Template Library (STL), started by a guy named Alexander Stepanov. But at that time there was no standard for the language itself, and various compiler vendors had the opportunity to treat it as they please. (I remember how in the mid-90s there was an opportunity to “drop links” with the Borland C ++ compiler, which is now impossible with the release of the standard).
Templates were a problem because vendors implemented them in different ways. However, the emergence of STL has 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 honey, soon there were various implementations of STL. 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 partly resembled STL. The important point: none of these libraries were interchangeable. It was impossible to just take it and replace "#include" with 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 was a lot like the 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 instead use some other one - which was done by most organizations, including the one I worked for, a young engineer who created software for the telecommunications industry. In this company, the programmers who worked before me used the STL version from Silicon Graphics, and it took tremendous effort to move away from it and replace it with a 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 conform to 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 proven STL, and if STL, which version? Or stop at a great commercial library like Rogue Wave? They also understood that once choosing one of them, they will be forced to use it for a long time. As for the Standard Library itself, compiler vendors often created its own version, which did not always coincide with the original.
It was a mess. And partly, the problem was (and now is) the process of standardization. STL was first demonstrated to the Standardization Committee in 1993, but 5 years passed before the standard was released. In the interim, there was not even a standard for the language itself, let alone libraries, so compiler vendors got 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 impossible 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 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 switch to new compilers, because their old code would stop compiling. A lot of things happened in 6 years in the computer world, and compiler vendors continued to release new versions, despite the upcoming standard.
In this process, little has changed. In 2006 (3 years after a small update), it seemed the new C ++ standard should become a reality. He finally came out in 2011. A lot of time has passed.
Boost
In the early 2000s, a new library is gaining popularity - Boost.
Boost is a set of C ++ libraries that fill in various spaces not only in the Standard Library, but also in the language itself, moving it forward. C ++ was released in 1983, after 4 years of development, and was based on C, which was released in 1972.
Let's be honest: despite the fact that I love C ++ very much 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 chips built directly into the language — chips 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 references. If you need a string, you must 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 built into the language , not to mention list or dictionary things. Want a list in Python? Just type "a = [1,2,3]". Is done.
As for more advanced things, like lambda functions (which are also natively supported by many languages) - this is where Boost-type libraries will be useful.
Of course, the fundamental difference with C ++ is that it is fully compiled. But this is an argument with which one can argue ad nauseam, whether it is better and faster with C ++ of modern dynamic languages ​​both with and without JIT compilation.
The Boost library ultimately serves several purposes: first, it provides programmers with both advanced things, such as functional programming, and basic ones, like smart pointers. Secondly, it is a kind of incubator for new language features that can become standard.
Right on the main Boost page , it was noted that 10 libraries from its membership were included in the C ++ standard 11. Yes, and it was released in 2003 - 10 years ago, long before the standard was adopted.
Since the adoption of the standard of 2011 took so much time, many developers began to use Boost (or completely abandoned C ++). So let's compare Boost with Standard.
Standard 2011 and Boost
The C ++ 11 standard includes several changes in the language itself (for example, the template compilation mechanism is put in order, which makes it possible to use “external templates” (“extern template”), and how easy it is to initialize container objects; even type definition mechanism)). But the standard also contains many improvements in the Standard Library.
There is an important caveat mentioned earlier: although the standard includes the description of the Standard Library, it does not include the implementation of either the compiler or the language. All this remains on the conscience of third parties, such as compiler suppliers. 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 have deliberately divided them. This means that you can use only those libraries from Boost that you need. There are several interdependencies, but they are well documented. Thus, you can combine Boost with the Standard Library, if necessary. For example, the good old iostream are part of the Standard Library since the first standard in 1998, and Boost works with them easily (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 on SourceForge (1.53.0) is 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 fall into the category of “Language Features Emulation”. For example, the foreach construct, thanks to the template engine in C ++, allows you to write loops that go beyond standard C ++ cycles, 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 in this way. The first is that coding becomes a little easier. Second, 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 ask you why this code sometimes works, and sometimes falls inside the functions from which it was called.
Boost also provides a huge range of powerful but narrowly specialized classes. For example, several years ago I needed a library for working with graphs. In Boost there is such. 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 implementation of Boost is not very simple, developers had to fill the library with compiler-dependent code. For example, the foreach implementation of a 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 another standard.
So, Boost continued to grow, but the work was carried out over the standard throughout the years preceding 2011. It contains some good classes, such as your own regular expression class, which has a lot in common with Boost-like counterpart.
But what about the standard? Let's look at it from the point of view of vendors. C ++ standards took years to become complete. The 1998 Standard was important because it established many of the fundamental aspects of a language, such as templates or links. This made the lives of library creators much easier. But compilers are still different from each other, 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 irregularities in the libraries themselves.
In the course of 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 standardized products before the standard was completed. 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, with the exception of two small ones (Rvalue links for "* this" and "minimal support for garbage collection"). But the developers made it clear that this support is still in experimental status.
This table from Microsoft shows the status in Visual Studio 2012 - there are a lot of "no" and "partial". But pay attention to this small note on the Microsoft page, which gives an idea of ​​what it dealt 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 got involved in working to meet the standard in its very early stages. However, they explained that some 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).
But the GNU implementation of the Standard Library . There are many elements labeled "N" and "Partial".
Comparison
It took 10 years before the standard began to form and it took 2 years to approve it. A lot of changes happened during this time, and compiler manufacturers cannot risk implementing those features that can be later canceled. Not a very nice picture.
Boost, at the same time, well advanced. The developers did an excellent job, making sure their code works with different compilers. Boost is ripe, well tested and works well. The development process is moving forward without any hindrance from the standardization committee. It continues to evolve.
What about changes to the Standard Library? I already mentioned the regular expression 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 this 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 Standard Library implementation. If you want to use the Standard Library, you need to use a third-party product, often bundled with a compiler, such as GCC or a Microsoft version. And this is 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 one would you prefer to use in your products?
It took the Standardization Committee 8 years to figure out what should still be in the standard, and compiler manufacturers would have to wait until everything was settled before publishing their version of Standard Library. Instead, they published pieces that were, at best, alpha versions. And they still haven't finished. At the same time, the present C ++ community moves on, creating better things like Boost.
In a few years, a new standard will appear. We have already passed. By that time Boost will be even better.
Source: https://habr.com/ru/post/173639/
All Articles