I have a few questions about the standardization, in particulair the prototype of Net TS1 coming this year (see here).
When does it exactly come?
Does it support portable binairy serialization?
Can it serialize to iostreams like files/std::cout etc?
Is there some other place where I can find the current status besides the mailing lists?
When will GCC/Clang implement it?
About the filesystem (Filesys TS):
It was supposed to be finished as prototype this month, why can't I find anything anywhere?
Is it the same a boost::filesystem? (So it can easily be ported.)
I hope I'm not asking too much questions, and I also hope some can be answered!
The latest full Networking Library proposal, based on Boost.Asio, was published in 2007. At that time, C++0x was still planned for sometime before 2010 and there was also a plan for a C++ Technical Report 2. The idea was to get the Networking Library into TR2.
Working on C++0x clearly stole everybody's attention, because not much else happened with the networking library until after it was published. In 2012, they produced a Networking Library Status Report and noticed that a lot had changed with Boost.Asio in the past 5 years. A study group was formed (SG4) to work on the Networking Library.
Now TR2 doesn't seem to be a happening, and it's full steam ahead for C++14 and beyond. As far as I can tell, there has been no explicit mention of a planned time frame for SG4. However, since it was formed, these are the most up-to-date papers from the mailings:
Using Asio with C++11 (N3388)
Urdl: a simple library for accessing web content (N3477)
C++ Internet Protocol Classes (N3477)
A URI Library for C++ (N3507)
IP Address Design Constraints (N3565)
A Three-Class IP Address Proposal (N3603)
Network Byte Order Conversion (N3620)
So combine these with the full TR2 proposal and you have a pretty good picture of the current status.
When does it exactly come?
There doesn't seem to be a specific time frame. Hopefully we'll see a technical specification sometime before C++14 (maybe even in 2013), but this is merely speculation. It'll be done when it's done.
Does it support portable binary serialization?
I don't think so. I can't find any mention of serialization in any of the papers. I think it's probably beyond the scope of the Networking Library.
Can it serialize to iostreams like files/std::cout etc?
See above.
Is there some other place where I can find the current status besides the mailing lists?
Not at the moment. However, they have been gradually making the mailing lists for each of the study groups public, so maybe SG4 will be made public soon. If it is, we'll get a better view of current progress.
When will GCC/Clang implement it?
Not yet!
In January 2013, revision 4 of the Filesystem Library proposal hit the mailing list. Again, I see no explicit time frame, but this and the Networking Library are the two library study groups with the most focus right now. Hopefully we'll be able to see a technical specification for this too sometime this year or at least before 2014.
It was supposed to be finished as prototype this month, why can't I find anything anywhere?
I haven't seen anything about a prototype, but I guess things sometime take a little longer than planned. Perhaps it just isn't public yet. The Bristol meeting is being held next month and all study groups' progress reports are on the agenda. I'm sure we'll see a technical specification when it's ready.
Is it the same a boost::filesystem?
Pretty much! Take a look at the latest revision; it mentions that it is heavily based on the Boost Filesystem Library version 3. There is a small section on differences:
In the Boost library, facilities in class path to handle narrow (i.e. char) character strings with encodings other than the operating system's native encoding depend on codecvt arguments. In the proposal, these facilities depend on locale arguments and additional UTF-8 facilities have been added. The Filesystem Study Group believes this approach is more reliable and useful, particularly as UTF-8 use continues to spread.
Otherwise, the proposal is very similar to the Boost library. Indeed, most of the proposed wording is generated from the same source as the Boost library's reference documentation.
Like all formal ISO C++ documents, Technical Specifications come when they're done. What it will support is hard to say up front. Features may be cut if they're not ready, or conversely publication may be delayed to get a wanted feature in. E.g. C++98 was delayed for ~2 years to merge in the STL.
The FileSystem TS is indeed being derived from Boost FileSystem, so there is very likely a high degree of commonality.
Related
There is lots of sweet stuff in TR2. Is that going to be in C++17?
I understand that TR1 was completed in 2005 and had to wait until C++11 to be standardized.
But I also understand that TR2 is already complete?
My link to C++17 doesn't mention anything about TR2, but I am hoping...
Maybe.
The point of TR (and now technical specifications) is to allow something to mature independent of the standard iteration process. They can publish a TS, see how it works, see if there are any problems in the implementation and/or use of the feature, and if everything works they can then "fold" it into the full standard.
Each TS is considered on its own merits to see if it will be folded into the next standard.
See http://isocpp.org/std/status (thanks #BenjaminLindley) for current status of the Technical Specification working groups.
Any of them, if completed well prior to 2017, could be folded into the standard. It is unlikely they all will be.
A goal is that we can get the std::experimental features to play with (and use if we are willing to accept the ground shifting under our feet) earlier, while having the features once added to std with fewer regrets and specification changes after that point. There are probably also massive organizational overhead advantages to decoupling the main line standard from each of these side projects and allowing them to evolve independently.
The purpose of a Technical Report, or Technical Specification as they are now, is to gain implementation experience and feedback from implementors and users, to better assess the suitability of features for standardization. One would need a crystal ball to know if a particular TS will be included in a future standard, and which future standard that might be.
Version 1 of the Library Fundamentals TS appears to have passed its final ballot at the November 2014 committee meeting, and version 2 is currently being drafted to incorporate feedback and new proposals. This means it is getting closer to being something which implementors and industry users are happy with, and version 1 is now an immutable specification which implementors can choose to conform to. It is still more than possible for later versions, and later standards, to change in ways which would be incompatible with version 1.
Here's a list (from your wikipedia link) of the features of TR2 - and my comments:
Threads - Included in C++11
The Asio C++ library - this is being considered for a future C++ standard
Signals/Slots - no action at this time (that I know of)
Filesystem Library - FileSystem Technical Specification
Boost Any Library - Part of the Library Fundamentals Technical Specification
Lexical Conversion Library - no action at this time (that I know of)
New String Algorithms - no action at this time (that I know of)
Toward a More Complete Taxonomy of Algebraic Properties for Numeric Libraries in TR2 - no action at this time (that I know of)
Adding heterogeneous comparison lookup to associative containers for TR2 - * Included in C++14*
Herb Sutter writes here (on his ISO C++ Spring 2013 meeting trip report) that a networking library is planned to be added to C++14.
What features would this library have initially? What is it based on? Is there a proof-of-concept implementation? My Google-fu must be seriously lacking, because I can't even find the proposal draft.
There are a series of blog posts on http://meetingcpp.com/ listing the proposals for C++14: part 1, part 2, part 3 and part 4. Among all these, I can only find two network-related proposals:
N3555 - a URI Library for C++ (sorry, no link; though its predecessor is N3507.)
N3603 - A Three-Class IP Address proposal (with a related earlier paper N3565 - IP Address Design Constraints.)
Is this all? Will the C++ network library have only these facilities? I don't even know whether these passed the vote or not, as Michael Wong's two part review of the same meeting (Bristol, April 2013) doesn't even mention them.
a networking library is planned to be added to C++14.
A networking library (or set of library components) will appear as a separate Technical Specification, not as part of C++14.
I can only find two network-related proposals
The blog posts don't list all the proposals in the mailings, just the ones someone has found time to write up, there are others such as:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3360.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3374.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3388.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3389.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3565.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3620.pdf
What will be part of the TS isn't decided yet AFAIK.
I have seen lots of people suggesting the Boost library on Stack Overflow, so I am also thinking of learning it. But today I came across this link: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Boost
I wanted to know about its acceptance in industry at a broader level. My current company also doesn't allow me to use this so I am confused whether to look into this or not.
Parts of Boost library is currently being accepted into the Standard library for C++0x and it is regarded as one of the top libs with a high industry acceptance. I'm actually unaware of any other library getting accepted into the C++ Standard Library on such a large scale.
"Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2."
You should definately look into this. Don't go by Google or any other large institution. They generally have to work to a subset of any complex language like C++. Hence, they'll have restrictions on which parts they can use so that it's easier to hire and train engineers to use the code base.
Additionally, Boost leverages many aspects of the higher forms of functionality within C++, case in point template meta-programming. Boost provides for a safer, though bulkier, form of functions as first class objects. They add in a more powerful "bind" which works so well with the standard library that I'd be lost without it. Finally, they have in place tuples and hash tables, both fundamental datatypes in modern development libraries.
In short, I really can't name one reason why you wouldn't want to look at Boost, even just to learn something. It's peer reviewed and largely platform independent. The source code is a treasure trove of information and more advanced programming techniques.
I think the who is using boost web page speaks for itself. Notably: Adobe, McAfee, and Real Networks probably qualify as industry.
My current company also does not allow me
to use [boost]. So I am confused whether
to look into it or not.
You might want to dig a little further and find out why. As others have said, Boost is a fantastically useful set of open source and peer reviewed libraries of extremely high quality. Look at their development LOC chart for an idea how long and how much $$ it would cost your company to reinvent the wheel.
** Please people, this question is not meant to begin any flame war. **
I am trying to understand what happens to existing libraries implementing some functionality when the same functionality that was not previously there in the language now comes in as part of the language? For e.g. C++ would soon have std::thread as part of the language standard so what happens to the POSIX or Boost Libraries?
I would also be keen to understand what experiences users of other programming languages might have in this regard.
Adoption of new technology never happens overnight. There will be a lag while compilers implement the new Standard Library versions, and then another lag while those compilers reach developers.
My last two jobs have featured occasional interaction with Visual C++ 6, which is over 10 years old. There is great reluctance to move from working code to a new if improved model.
If old libraries do die, it's through a process of gradual obsolescence rather than sudden mass extinction.
Depending on the library, it's possible that the upcoming standard simply captures a snapshot of current function, and the parent library will continue to evolve as an incubator for C++1x, C++2x and so on.
Sometimes library authors continue to maintain their library because their library does something slightly different than how it is done within the language: either this difference offers a unique advantage or is fundamentally easier to grok. Whatever the case, if there is enough user desire to see it continue or if the author is stubborn it will continue to be maintained. Eventually, though, people just use what comes naturally in a language if the advantage is not great enough.
C++ std::thread is in large parts based on boost threads. So boost threads will never really disappear, they will live on in the standard C++ library.
Additionally, on many platforms boost threads use posix threads as backend, so they will never disappear too.
Such thing hasn't happened yet. C++ has only one implementation so far.
Possible duplicates
Is there a reason to not use Boost?
What are the advantages of using the C++ BOOST libraries?
OK, the high-level question is "Please provide me with what you consider to be the most effective arguments of why entire Boost, or some specific parts of it, should be compiled on our company's system and endorsed in software engineering standards".
Details of what I need:
Would gladly accept both positive arguments (why install), as well as proposed rebuttals of likely counter-arguments I might hear (see question context below).
Arguments should be made aimed at both technical Software Engineering team members and/or very technical senior managers - in other words, for the latter, the details of the argument may/should be technical, but the thrust of the argument should be "how would this make/save the company X money vs losing the company Y money as a cost of adding it to our toolset".
Context of the question:
I'm a developer in a company with several hundred developers, many dosens of whom do C++.
I had the (mis)fortune of being reassigned from my beloved Perl development spot to a team where I am also doing C++ development. So far I found numerous things that I could easily have done in Perl that are very hard/cumbersome to do in C++ (foreach loop as an example), and anytime I hit one of these, the answer 50% likely ends up being "You can't do this in standard C++ but you can do it with Boost"
Our toolkit includes some legacy RogeWave libraries, and VERY limited number of Boost libraries (e.g. no regex, no foreach), of very old vintage.
Any development must use libraries compiled and vetted by Software Engineering team. That is a hard and fast rule.
SE team is somewhat resistant to adding new libraries, for a variety of reasons (e.g. effort to do this; functionality conflicts with RogeWave, for example for RegEx; the risk of installing and using any new software; cost of educating developers, etc...). They will add the libraries if presented with sufficient business need or majorly convincing cost/benefit ratio argument, but they have pretty tough threshold.
So, I'm looking for examples of which parts of Boost are so wonderful (with exact cost/benefit estimates) that installing them would be an Obviously Worth It Effort for Software Engineering.
Thanks in advance for any ideas/suggestions/examples.
Please don't mark this question as subjective as I am looking for measurable answers, not merely wonderful feelings :)
Wherever I worked in the last decade, when they had their own smart pointer class, I found bugs in that - usually within a few weeks. And, no, I never went and looked at it hoping to find errors.
I got into the habit of posting the following quote from the TR1 smart pointer proposal:
The Boost developers found a shared-ownership smart pointer exceedingly difficult to implement correctly. Others have made the same observation. For example, Scott Meyers [Meyers01] says:
"The STL itself contains no reference-counting smart pointer, and writing a good one - one that works correctly all the time - is tricky enough that you don't want to do it unless you have to. I published the code for a reference-counting smart pointer in More Effective C++ in 1996, and despite basing it on established smart pointer implementations and submitting it to extensive pre- publication reviewing by experienced developers, a small parade of valid bug reports has trickled in for years. The number of subtle ways in which reference-counting smart pointers can fail is remarkable."
This plus a detailed analysis of the bug(s) I found usually got me the job of incorporating the boost libs into the code base. :)
It seems to me you're doing this the wrong way around. Since proposals to add new libraries are going to be met with a lot of resistance, don't even bother trying to argue for boost as a whole. Choose your battles instead.
Find the specific Boost libraries which you know (with your knowledge of the application it's to be used in) will be useful and save time and money. And then propose adding those.
I could easily list the Boost libs I've found useful, and why I think they're great, but I don't know if they'll be of any use in your application.
Push for individual boost libraries to be included, and then perhaps, over time, so many of them will be included that it'll be simpler for everyone to just include all of Boost.
It's an open standard not controlled by a specific company ( no licensing costs )
It's cross platform
It's expertly designed / written and very fast / efficient extensively tested
There are open source implementations which your team can compile themselves.
Boost will soon become part of the standard C++ STL
Here is a slightly oldish 2005 article on Dr. Dobbs discussing the upcoming C++0x standard.
http://www.ddj.com/cpp/184401958
I had to maintain a component using that old vintage Tools.h++ from Roguewave, on a Solaris system.
On Solaris, if we want to use boost, we need to use either gcc, or SunStudio with STLport implementation of the standard (instead of Roguewave one). And as Tools.h++ requires the old Roguewave pre-standard implementation of the standard -- on Solaris --, I had to give up on boost.
In the end I rewrote a simplified version of a few boost-like features I needed.
If you are in that same situation (*) , you would not be able to move from Roguewave library to boost that easily. There is a non negligible cost in this operation, as for instance pointer containers from both libraries have quite different interfaces.
(*) Where we can't slowly change bits by bits of the old code to progressively use boost. In that situation, the migration has to be radical and to change simultaneously every occurrence of Tools.h++ by something more trendy, or even better.
NB: Most people are able to progressively use boost in old projects, and may miss a very important, and yes technical, point. Hence my negative answer.
Boost is a great tool and an invaluable part of our product development (we'd be lost without smart_ptr)... but because it is changing so fast the stability of releases can be effected.
For example, we were happily introducing new versions of Boost as soon as they came out without thinking twice. That is until we were stung with a bug in the 1.35 threading library that produced occassional (ie difficult to debug) but critical errors. Fortunately we identified the issue before anything was released to the public and could move back to 1.34.
Ever since then we've taken a specific version, extensively tested it, and not updated without a compelling reason to do so.
Here are two suggestions for advocating boost:
Who's Using Boost? (http://www.boost.org/users/uses.html)
lots of major projects use boost: (e.g., adobe photoshop, CERN)
Boost Project Cost (http://www.boost.org/development/index.html)
How much it would cost to hire a team to write boost from scratch? There's a nifty (somewhat gimmicky) calculator there that helps to put it in perspective.