Boost 1.36 Released 166
AndrewStephens writes "Good news for C++ programmers: Boost 1.36 has been released with 4 new libraries (including very useful exception templates) and a host of updates. In particular, boost.asio (the cross platform AsyncIO library) has seen major additions and now supports asynchronous disk operations on Windows. Almost every modern C++ codebase uses Boost somewhere, and many of its features find their way into the official language specifications."
Really appreciate it (Score:2, Interesting)
Re:Really appreciate it (Score:4, Insightful)
Re: (Score:3, Funny)
- News at 11
Use of Boost? (Score:3, Insightful)
Almost every modern C++ codebase uses Boost somewhere
[Citation needed]
Boost is created and used by a highly vocal minority of C++ supergeeks. You can play with the definition of "modern", but it's only been in the recent past that Boost even compiled on more than the bleeding edge platforms. Most of the C++ projects I've worked on professionally are still worrying about whether to allow non-trivial use of templates or how to avoid screwing up exceptions, never mind trying to fight through the mess that is getting Boost installed and running these days and spending time getting lawyers to review the licensing terms.
Re: (Score:3, Informative)
While I agree that it's a bit pissy to imply that if you're not using boost in your c++ project, you're not 'modern', neither installation nor license ought to be much of an issue. The license is as clear cut as it can be:
Re: (Score:2)
I consider that really sad. For the most part, since about 2004 or 2005 compilers have been perfectly fine for Boost. If most shops are still wondering about this, most shops are using dreadfully old development tools.
That being said, I haven't done any really serious C++ development work since early 2006. I now consider C++ to be the language to go to when Python is just too slow for something. And for that there's Boost.Python [boost.org].
Though, I'm starting to get interested in intensive parallelization and Pyt
Re: (Score:2)
Re: (Score:2)
Not every environment looks like yours.
Where I live, 2005 is very recently, and compilers which were bleeding edge then are still not the only ones we use. God knows how old Sun's compiler is, or what kind of commitment they have to the C++ language ...
I'm happy if I can work with a code ba
Re: (Score:3, Insightful)
why is this bullshit even getting modded 5 Insightful? It's pure flamebait! Most half-decent compilers don't have problems with boost, the license consists of 5 sentences and .... how exactly can you screw up the installation of a mostly header-only library?
Re: (Score:2)
Most half-decent compilers don't have problems with boost
Ah, the no true Scotsman argument.
Unfortunately, the reality is that compilers outside of the mainstream ones like Visual C++ or GCC have only reached the level of support required for much of the wizardry in Boost relatively recently. If you're working on portable code and your project is more than a couple of years old, you are unlikely to have been able to use Boost when you started it.
the license consists of 5 sentences
That doesn't matter. In some businesses, including almost all large ones in my experience, any use of external software
Re: (Score:2)
It is always risky using a non-mainstream compiler for a low-level language like C or C++. The advantage of such languages is that you get good control o
Re: (Score:2)
That's okay. The differences between endianess, width of various data types, etc etc. would get you anyway if you try to simply reuse nontrivial x86 C/C++ code non-trivial on other architechtures.
C and C++ are too low-level to be easily portable. That's the price of doing things close to hardware, besides undefined behavior
Re: (Score:2)
Unless you are using one of the few parts of boost that require libraries, "installing boost" means copying it somewhere and putting a "-I" line that points to it in your build.
The licensing terms are themselves hardly cryptic.
Re: (Score:3, Funny)
Re: (Score:2)
Anyone who had seen Boost source code knows that there are plenty of old hacks and workarounds in it specifically to make it work (to some documented extent) on such archaic compilers as VC6 and g++ 2.95.
Re: (Score:3, Interesting)
Anyone who had seen Boost source code knows that there are plenty of old hacks and workarounds in it specifically to make it work (to some documented extent) on such archaic compilers as VC6 and g++ 2.95.
Sure, but those are by far the biggest targets. How many little hacks were in there to support the native compilers on IBM, Sun or HP workstations, or even older Macs before GCC took off there?
Sounds like the kind of people who might be surprised that C++ is already out of draft for some time, then.
You judge too quickly. The problem isn't a lack of understanding; some of the people I'm thinking of are among the smartest C++ hackers I've ever met, the kind of people who have been following the C++ newsgroups since some way back into the last century, been to their fair share of ACCU conferences, even filed the od
Re:Use of Boost? (Score:4, Insightful)
Boost is created and maintained by, among other people, the people who created and maintained the C++ STL.
If by "on more than the bleeding edge platforms" you mean "on something other than MSVC," then yes. Microsoft's compiler was tremendously shitty when it came to standards conformance until .NET 2003 edition (I believe). Not to mention that only applies to the more esoteric libraries (like lambda functions and spirit), and boost is quite modular so you could still use the parts that did work.
You're definitely a Windows developer, aren't you? You're just suffering from the fact that Boost isn't really built with or for MSVC, and the Windows development process is very non-standard with respect to every other OS out there. On my system installing boost is a process that consists of all the "mess" of executing ONE terminal command ('pacman -S boost' and when it gets done Boost is installed and ready to use).
As for the licensing terms, this [boost.org] is the boost software license. It is three (short) paragraphs long. Stick to the libraries that are covered by that license (most of them) and you won't have any trouble. If you need more libraries than that, I'm not aware of any that have meaningfully complex licenses.
Should I mention the fact that boost is the code base for much of the additions to the next generation of the C++ STL? I know templates can be big and scary, but really...
Re: (Score:2)
Boost is created and maintained by, among other people, the people who created and maintained the C++ STL.
Well, yes and no. Although Boost was begun by members of the C++ Standards Committee Library Working Group, participation has expanded to include thousands of programmers from the C++ community at large. [boost.org]
And of course, the STL was originally developed independent of C++ by Alex Stepanov and Meng Lee. When Stepanov was first throwing around the underlying ideas, C++ didn't even have templates yet [sgi.com].
If by "on more than the bleeding edge platforms" you mean "on something other than MSVC," then yes. Microsoft's compiler was tremendously shitty when it came to standards conformance until .NET 2003 edition (I believe).
Your prejudice is showing. Visual C++ has pretty consistently been among the most standard-compliant compilers si
Re: (Score:2)
Absolutely. It's good to have more people contributing.
Re: (Score:2)
Are these people from commercial sellers of C++ libraries saying bad things about Boost?
Yes, absolutely. There is no possibility that someone simply has different experiences to you that have caused them to criticise something based on objective reasons. Anyone who disagrees with you must have a vested interest.
It's not like I'm new here. Go ahead and check my posting history. You'll find I've got plenty of hours logged writing C++, and as surprising as you might find it, I do actually know what I'm talking about.
Be a good chap and pick up the tin-foil hat on the way out, would you?
Boost epitomizes everything that is wrong with C++ (Score:4, Insightful)
Boost is a great example of what a bloated, backward language C++ has become. It relies on complex intricacies from the standard that are difficult for compiler writers to implement correctly and robustly and without bugs. As a result, Boost itself is not very portable. Either it works on your platform and compiler, or it sort of works, or it doesn't.
Boost--and template metaprogramming in general--is a great exercise in intellectual masturbation. They identified a bunch of useful functionality that isn't supported by the language. Rather than design a new language that does support that functionality, or build external tools to provide it, they contort the template semantics of the language in order to try and squeeze that functionality out of nothing.
Well, template metaprograms are crap. They're nigh undebuggable, they produce unreadable error messages, they take forever to compile, and most C++ programmers don't know how to write (or even read) their implementations. They're an abomination.
Since meta-programming is clearly useful, and something that a lot of programmers want to do... why not add true compile-time metaprogramming support to C++ (or better yet, develop a 10x simpler and cleaner language and put proper compile-time metaprogramming support into it)? Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
Again: Boost exemplifies everything that's wrong with C++. All of the corner-case features of C++ that Boost exploits in order to provide useful and sane functionality in an insane way, should be removed from the language (or its successor). Instead, general and clean and low-level metaprogramming mechanisms should take their place so that the functionality embodied in Boost could be written directly by any mid-level programmer instead of an elite group of template wankers. :P
Re:Boost epitomizes everything that is wrong with (Score:5, Funny)
Re: (Score:2)
Replace "C++" with "assembly language" and "Boost" with "C", and you will get a Readers comments reply from a 1978 edition of BYTE magazine.
Re: (Score:2)
Re: (Score:3, Insightful)
As a result, Boost itself is not very portable. Either it works on your platform and compiler, or it sort of works, or it doesn't.
If you left this out you would've looked like less of a troll, seriously. Boost compiles with GCC4 (From 4.0.1 to the latest, on Mac, Linux and BSD), Intel's compiler collection (All OSes), Visual C++ (7.1 to 9.0Beta) and Borland.
If it isn't cross-platform enough, I'd like to know what platform and compiler you use
Re: (Score:2)
I use DJGPP in DOS, you insensetive clod!
Re: (Score:2)
Boost compiles with GCC4 (From 4.0.1 to the latest, on Mac, Linux and BSD)
But MinGW for Windows appears to have been stuck on 3.4 for years. So if I'm on Windows, should I be using Visual C++ Express instead of MinGW?
Re: (Score:2)
actually that is a good question. Why is mingw version stuck in 3.4 when I'm running 4.2 on mac and 4.3 on debian lenny?
does anyone know?
--jeffk++
Re: (Score:2)
Re: (Score:3, Informative)
Boost targets implementations which actually implement the C++ standard, not subsets of the standard for embedded purposes. The whole point of Boost's advanced functionality is that templates are the only way to express it in C++, short of implementing an actual metalanguage on top of C++, which would be even more heavyweight and incompatible.
Re: (Score:2)
Boost targets implementations which actually implement the C++ standard
And how many of those are there, exactly?
(As far as I'm aware, the answer to that question is still "one", and that one only fairly recently.)
Re: (Score:2)
Re: (Score:2)
VC++, GCC, Intel, Comeau... That's just off the top of my head
Out of my head: the restrict and export keywords. If I remember correctly, only one of the compilers you mentioned really respect export, three respecs restrict, and they are errors for the others (left as an exercise to the reader). And let's talk a bit about inlining and implicit functions...
None of them are perfect, but they're close enough as makes no difference.
They do make a difference. They are not 100% compatible to the standard, and it means that code that would work on one compiler may not on the other. I've faced this in projects, and I'm sure the Boost guys are aware
Re: (Score:2)
Well export is regarded as a mistake by the only people that have actually tried to implement it, so I can't say I'm really shedding any tears over that one.
As for the rest, the only problem I've encountered recently is VC++ being too lenient in what it accepts. It still does fine with code written to the standard though, so once you have tweaked your code to work in GCC for example, it usually works in all of them. And this tweaking is hardly difficult. Took be about an hour to bring my game framework up i
Re: (Score:3, Informative)
I've given you two keywords (restrict, export) and two features (implicit functions, inlining) that aren't well implemented (okay, lets say different enough so that one code might not be compatible) across the mainstream compilers, but I'll tell you another one: template metaprogramming and typename.
I don't know about the state of VC2008 and Comeau since I've stopped working with them a while ago (working on OSX with intelc and g++), but I remember by my young self having a lot of difficulties building cro
Re: (Score:2)
Of course not, but Boost caters for a lot of compilers that have been superseded for years and years already. It goes to great lengths to hack around the limitations of VC++ 6 for instance, and that was released before the C++ standard was even ISO approved. There's also lots of fixes for old Borland compilers. If you removed all the old baggage, I think even Boost code would be relatively readable.
I can certainly relate to the experiences of your young self with template trickery (VC++ 6 still gives me nig
Re: (Score:2)
Which embedded platform are you on that has a C++ compiler? Most of them barely support the C standard.
Re: (Score:2)
Don't most of them simply use gcc these days? (And some stripped-down Linux distro as an OS.)
There's something called "Embedded C++" for compiler writers who need an excuse not to write a working C++ compiler, but I haven't heard of anyone who has used it.
Re: (Score:2)
ARM for one. With the fun of needing to support 3 versions of the compiler for partners.
Most of them have a C++ compiler, however the number of quirks and features missing vary greatly.
Re: (Score:2)
Maybe that is why the next version of C++ will implement many of the features and libraries in Boost, but natively, avoiding some of the mental masturbation issues you mentioned.
Re:Boost epitomizes everything that is wrong with (Score:3, Insightful)
Wait - You actually mean to say you'd rather see an entirely new language appear to address mere oversights in an existing one, than extend the single most widely supported (in the sense of "used" and "dev tools exist on platform-X") language to do a few new tricks?
As an aside, I d
Re: (Score:3, Insightful)
Well, template metaprograms are crap. They're nigh undebuggable, they produce unreadable error messages, they take forever to compile, and most C++ programmers don't know how to write (or even read) their implementations. They're an abomination.
Since meta-programming is clearly useful, and something that a lot of programmers want to do... why not add true compile-time metaprogramming support to C++ (or better yet, develop a 10x simpler and cleaner language and put proper compile-time metaprogramming support into it)? Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
This isn't proof that template metaprogramming or even the boost implementation of it sucks. This is proof that you've seen some bad code written with that feature. So what? Get in line! I've seen rotten code written using too many macros, I've seen rotten code written using too many templates, I've seen rotten code written using too many classes.
Basically, name a language feature, find some engineer who decides that feature is the final greatest achievement in programming, and then give him a year or s
Re:Boost epitomizes everything that is wrong with (Score:2)
You'll only take boost/shared_ptr out of my cold, dead hands.
Re:Boost epitomizes everything that is wrong with (Score:2, Insightful)
Boost is not a "template metaprogramming" library, as you seem to be implying. It's just a good library that happens to use template techniques for some purposes for which it is very well suited, for example, the Spirit parser.
You don't need to know template metaprogramming at all to use Spirit. In fact, what Spirit does is make the specification of parsers look like BNF but in C++ syntax. Internally, yeah, the library is awfully complex. But that is the point of a library - it implements once and for al
Re:Boost epitomizes everything that is wrong with (Score:2)
Well, template metaprograms are crap. They're nigh undebuggable, they produce unreadable error messages, they take forever to compile, and most C++ programmers don't know how to write (or even read) their implementations. They're an abomination.
You are describing STL not boost. Boost fixes the majority of these problems. C++ has evolved since STL was developed. Now these extensions can be written using readable, and debuggable code, and they have, in boost.
Any reasonably intelligent programmer should be able to understand most of the boost headers. And see why they are great. If you can't you should probably be working in another language. C++ is not C. Your arguments died over 20 years ago.
Re: (Score:2)
This confuses me greatly. Templates ARE true compile-time metaprogramming support. Perhaps just not exactly the design that you want? Contrary to what you seem to believe, things like partial template instantiation are NOT corner-
Re: (Score:2)
#1, it's perfectly possible to debug programs made with boost. Heck, unless the error you're encountering deals specifically with the mechanics of a specific template instantiation, it shouldn't really be any different than any other kind of debugging, aside from having to see ridiculously long type names.
#2, not all of boost is obscure template magic. You seem to be under the impression that even touching Boost will contaminate your code with heavy preprocessor recursion and metaprogramming trickery and
Re: (Score:2)
I agree with you that somewhere inside C++ is a small, elegant language screaming to get out. So, please write it already! :-) Until then, I'll use Boost.
And no, I won't use your language if it requires extensive runtime support such as garbage collection, if it isn't statically compiled to machine code, or if it doesn't allow me to do the low-level fiddling I can do with C or C++.
Re:Meta-programming (Score:2)
Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
It is my intuition that you must define metaprograms in a pure functional language if the resulting programs are going to be statically compiled into machine code with little or no runtime support. This is especially true if the language supports multiple disjoint compilation units that produce object code that requires no compiler support to link together into an executable program.
The main thing missing, is introspection (Score:3, Interesting)
The main drawback of metaprogramming via preprocessor is the same as metaprogramming via any external tool--lack of introspection.
What you want is metacode that can be embedded in your normal C++ code, read by the C++ compiler, and can run with access to the AST or some other high-level representation of what the compiler has parsed. It should be able to read, interpret and modify the declarations that have already been parsed--generating new methods or typedefs on the fly, for example.
The compiler knows t
Re: (Score:2)
As long as I can still implement an ALU in the preprocessor, I'll be happy.
Re: (Score:2)
With all this talk of metaprogramming, I'm really surprised no one has mentioned Common Lisp.
Then again, this is a post about a new version of a C++ library which seems to have devolved into a language gang war...
Re: (Score:3, Insightful)
What you want is metacode that can be embedded in your normal C++ code, read by the C++ compiler, and can run with access to the AST or some other high-level representation of what the compiler has parsed. It should be able to read, interpret and modify the declarations that have already been parsed--generating new methods or typedefs on the fly, for example. [...] it would be nice if the output of the metaprogram was source-code, too.
So what you're trying to say is (use 'lisp)?
(and
(macros-run-on-ast-p 'lisp)
(reads-decls-p 'lisp)
(interprets-decls-p 'lisp)
(modifies-decls-p 'lisp)
(outputs-source-code-p 'lisp))
Huh. I'm still using STL. (Score:3, Insightful)
Seriously. Boost lets you avoid maybe five lines out of every hundred at the lower levels, but that doesn't really improve performance, just make code less readable and more dependent on another library. If people wanna use Boost, fine, but not all "modern C++ codebases" use it or even like it.
Re: (Score:3, Funny)
Yuda man.
Re: (Score:2)
I'd rather user PCRE. Written in clean and simple C and BSD licensed.
Re: (Score:2)
Re: (Score:3, Insightful)
Five lines out of a hundred? That's an awfully specific number for something as huge as Boost. I know I saved a lot more than that on not having to implement a complete cross-platform signals/slot implementation myself. Or a threading library. Or a parser for Unicode data files from scratch. Or a smart pointer implementation. Or a specific graph implementation with corresponding algorithms every time I need one. I could go on.
Boost isn't about performance. It's about letting you get shit done instead of rei
Re: (Score:2)
Oh, and before I forget, you don't even need STL for PCRE as it has a native C/C++ binding.
Re: (Score:3, Interesting)
Soo, what happens to your game in case of an exception then? Always careful to clean up any allocated resources I assume? See, this is not a contest to see who can "handle" cleaning up memory himself. Any monkey can do manual resource management if he wants to. Personally, I just can't be arsed to twiddle pointers and exposing myself to memory leaks and other problems unless I have to. Not that I use manual memory allocation much at all.
Anyway, m
Re: (Score:2)
an exception
A what?
An exception (Score:2)
an exception
A what?
An exception is what the C++ standard library and your other libraries throw when they can't allocate memory for a game object, or they can't read a mesh, texture, map, wave, or music file from the disc, or a user-provided mesh, texture, map, wave, or music file is malformed.
Re: (Score:2)
My other libraries return a null pointer. Writing your application in C++ is fine if you can handle the complexity, but please gives me a library with a C interface.
--
Writing myFoo->doStuff() is rarely better than writing foo_doStuff(myFoo)
Re: (Score:2)
It's kind of sad when anyone states that graphs is a good example of what's not needed when writing games. I highly doubt that OpenAL keeps a core busy. It's not the number of threads that matters, it's whether you are actually saturating the CPU or not. And, well, smart pointers are never needed, but they are frequently nice, basically as soon as you might have otherwise wanted to write the cleanup code in multiple places (and that need includes exception handling, if you ever use that).
For me, Boost has
Re: (Score:3, Informative)
Hey, anyone else ever notice that games are, generally speaking, the buggiest, hackiest, most insecure pieces of software on a system? Other than spyware and "enterprisey" stuff, anyway.
- smart pointers (Seriously? You can't check pointers yourself?)
No, I can't, and neither can you unless you've found some way to replace your organic brain with a metal and wire positronic supercomputing device. Once you've managed that feat, you still have to overcome the impossibility of using exceptions properly without RAII. Stick to games.
How Boost features could be worked into a game (Score:4, Insightful)
And when using C++ [to write games], I don't need: regexps
Not even for parsing your game's preference file?
signals and slots
Not even for notifying game objects that things have happened to other objects?
smart pointers (Seriously? You can't check pointers yourself?)
Not even for disposing of a mesh and texture once no nearby game objects need it anymore?
Re: (Score:2)
For one thing, lacking smart pointers (by which I mean at least std::auto_ptr or boost::scoped_ptr), there's no way to write an exception-safe class that performs any heap object allocation in constructor, and deallocation in destructor.
Re: (Score:2)
Ummm, how do you think the smart pointers do it?
class HeapAllocate {
int *x;
public:
HeapAllocate() : x (new int()) {}
~HeapAllocate() { delete x; }
};
Of course if you want to do more than one allocation (of memory or any other resource) in a single class, then you'll have to have to use a smart pointer, or other RAII class for each one.
Re: (Score:2)
But, of course, there is far more stuff written in C++ than just games and software for embedded devices. And there, using exceptions makes total sense, because it's hard to use some other parts of the language without them.
Re: (Score:2)
It can, but it needs not, and there's no way to find out in a portable C++ code whether your host C++ implementation even has a Unicode locale at all, which kinds of them it has (UTF-8, UTF-16, UCS2...), and what are the names of those locales to load them. Nor do you get any guarantee that, in either the default or classic locales, wchar_t will be treated as Unicode codepoints by any locale-aware functions.
Re: (Score:3, Funny)
I'm merely saying, "I don't need a massively powerful library, I just need to get shit done."
Confucius say "Man who try to get shit done without library sit on pot with nothing to read."
Re: (Score:3, Insightful)
regexps - configuration parsing
signals and slots - game entities as properly isolated actors
smart pointers - duh. we'll talk again when a dangling pointer hits you where it hurts the most.
graphs - AI? pathfinding? don't really need those in games, do you?
Re: (Score:2)
Re: (Score:2)
Man, you're missing out. BIG time. I write games myself for fun and I would probably cry if somebody told me I couldn't use signals or smart pointers anymore.
Are we talking about the same library? (Score:2, Insightful)
I'm seeing tons of comments on this thread about how awful boost is and how all it does is cause global warming, start wars with middle eastern nations, and destroy the pristine beauty of C++. Huh?!?
Yes, boost includes meta programming libraries, but it also provides a number of other useful and relatively basic features which truly are missing in C++. The shared_ptr class is one example that nobody thought to include in STL for some unclear reason. What if you want non-platform specific threading or dat
Re:Are we talking about the same library? (Score:4, Interesting)
I think the problem a lot of people have with Boost is not related to how good/bad it is; but rather the complexity in understanding it, and the level of complexity that it brings to your program.
The problem as I see it is that if you're not one of the scary smart people that understands the way the boost developers think, then you will have problems integrating boost into your project, and debugging it when things go wrong.
A lot of those problems will be due to your own ignorance but at the end of the day if something isn't obvious or at least well documented (and boost documentation isn't exactly a light read at the best of times) people will be turned off by how difficult it is, no matter how useful or speedy or good or whatever.
I work with a scary smart C++ programmer who swears by boost. I primarily code in C, but he convinced me to write a project using C++ and boost to see how thoroughly useful it is.
With boost, you can in very few lines of code, write code that can do impressive stuff. This is very true. But what you don't realise when you start out is that when you include boost::asio or boost::threads or whatever, you're including hundreds of thousands of lines of other people's code into your program, perhaps unnecessarily complicating it and making it so when you have a problem, you'll be staring at the debugger going "my code failed where?!" with a backtrace stretching back to infinity (and making Java Exception backtraces look NICE).
Yes, reinventing the wheel is a bad thing, and should be discouraged. But what if you just need a simple wheel? A wheel that, I don't know, goes around and around. I don't need it to report on its air pressure, or self repair, or sprout wings and fly if I go off a cliff. I just need it to be .. a wheel.
And boost tries to be the best possible wheel for every occasion. Its the wheel designed by the Borg. Assembled by nanites, it itself is made from nanits and will, whether you like it or not, assimilate your program into the Borg.
Re: (Score:3, Funny)
whoops, replied to the wrong post. Oh well, this'll do :P
Re: (Score:2)
I think this is the first boost complaint I've seen on this thread I would agree with. Some functionality in boost can be very difficult to understand, even if it is powerful. The date/time is one that I used recently and found less than intuitive.
Most of this, however, is not a problem with the library, but rather a problem with the documentation. I find code that uses boost ends up being quite readable (assuming no metatemplate programming) however.
Re: (Score:2)
Re: (Score:2)
>The shared_ptr class is one example that nobody thought to include in STL for some unclear reason.
Thread-safety/performance tradeoff.
Re: (Score:2)
The philosophy of C++ has always been that you only pay a performance hit for the features you use. A shared_ptr class follows this rule of thumb accurately. It's a good reason not to use the feature (if you have code that cannot suffer that performance hit), but it is not a valid reason to exclude it from the standard implementations.
Basically, STL is a "good start" towards a general library. Boost is here to help us get a little further.
Trolls are modded insightful? (Score:5, Insightful)
Why is it that all the trolls are modded up? People that think that Boost is the same as STL are insightful. People that think Boost is for C++ supergeeks are insightful. People that think Boost epitomizes what is wrong about C++ are insightful. Boost represents a serious set of genius level code and design and helps thousands of programmers that understand how good it is.
I understand that trolls exist and that they will always be with us. I understand that ignorant people will continue to post until the end of time. What I don't understand is that the /. community apparently agrees with them. This is supposed to be a community of hard-core geekery that understand things like operating systems, and game programming, and the intricacies of complex, multi-paradigm languages likes C++. What I'm seeing here is that it's populated, in greater numbers, with ignorance and "I heard a sound bite from someone who doesn't know what they're talking about so now I know everything" kinds of people.
Have a look at what you know and what you don't know and then think about how intelligent your opinion actually is, and then post. And when you're modding that post, do the same thing.
Boost is a mixed bag (Score:5, Interesting)
I use C++ and Boost and like them. But it's a love-hate relationship. I mostly found the trolls to be insightful because they reflected that love-hate.
C++ is a great programming language in the sense that English is a great natural language. Undesigned, piecemeal, weird idioms, and a pig to learn. But expressive, powerful, portable. Boost plays the role of "the King's English" -- it's a style guide. Sometimes arguable, sometimes wrong, but mostly very good at pointing out how to avoid deficiencies in the language. C, C#, Delphi, Objective C, OCaml, Mathematica and Python are unquestionably better languages than C++. And Esperanto is better than English. But I speak English and use C++ because it does what I need it to do better than any of the alternatives.
Dealing with geeks is a problem for management to deal with. C++ is probably rightly the domain of ubergeeks. If you choose to use C++ because it suits your needs and your geeks like a bit of mental masturbation, good for you. No matter what language you use, your local geeks will push the boundaries. With C++, Boost mitigates the damage your geeks might cause when pushing boundaries (e.g. template metaprogramming). Boost is therefore a tool for managing geeks.
The biggest problem with C++ and Boost is also their biggest asset. The language is too plastic. Every new library, object or template comes with a domain-specific-language that you just have to learn. For example, using functors to create threads. That is counter-intuitive and hard. But with Boost, each domain-specific-language tends to be well designed, so that if you understand C++, then Boost will push you into using the features in a way that is portable and safe.
But an overwhelming gripe is that the online documentation is atrocious. In the sense of incomplete, unclear, impenetrable, useless examples, broken links, broken HTML, outdated. To the point where it becomes a good reason not to use Boost.
Re: (Score:2)
I mostly agree with you (well, entirely agree except for what I define as qualifying as a "better" language; I believe English is "better" than Esperanto just like I believe C++ is "better" in the general case than most other options). That said...
Really? I can think
Re: (Score:2)
My 2cents worth on the subject is this: Whenever you need to implement some code, it's worth seeing if there's a good library available t
Re: (Score:2)
You just have to deal with it all just as they have to deal with you. You're dealing with an open community and when you deal with an open community you can people of all types. How many script kiddies do you think read /.? I would say lots of them.
Here is the deal with /. moderation. It comes in two forms and all tags are Emotionally based except Interesting and Informitive. (sometimes even them!)
1) Emotional Moderation: Someone says something they can relate too, so they moderate it up. Doesn't make
Maybe they understand something you don't (Score:2)
I understand that trolls exist and that they will always be with us. I understand that ignorant people will continue to post until the end of time. What I don't understand is that the /. community apparently agrees with them.
If you can keep your head when all about you are losing theirs... they probably know something you don't.
You, and a few other posters who have labelled all the critical posts as trolls, seem to be assuming that those who make those criticisms are incompetent and/or uninformed. Why do you assume this? It is clear from the comments that many of the critics have used (or tried to use) Boost in various circumstances, and found it isn't the silver bullet so many of its advocates seem to make out. The criticisms
Re: (Score:2)
The whole moderation system does not need consensus, just enough people who agree to get the score up to 5. In addition, the reason why more languages exi
Re:Slight exaggeration? (Score:5, Informative)
Re:Slight exaggeration? (Score:4, Interesting)
A statement on /. makes you less inclined to look at a set of C++ libraries, I'm not quite sure how that logic works, has the statement made on /. somehow affected the quality of the libraries?
Re: (Score:3, Insightful)
Affecting the quality? Obviously not, but I won't stop you for being silly to try to make a point.
I'm seeing a release blurb which looks more like an abbreviated commercial press release - including the mandatory "we're the market leader" claim - for a pretty uninteresting update. While this sort of stuff weasels its way into slashdot every now and then, the whacked out of reality claims definitely raises the bullshit-o-meter alarm.
Allow me to demonstrate using the "Almost every modern uses somewhere" tem
Re:Now if only (Score:4, Funny)
Re: (Score:2)
Re:Now if only (Score:4, Insightful)
That's PascalCase. This is camelCase.
Re: (Score:2)
That's PascalCase. This is camelCase.
Nope: http://en.wikipedia.org/wiki/CamelCase [wikipedia.org]
Re: (Score:2)
Did you even read the link you posted?
Set theory (Score:3, Insightful)
Did you even read the link you posted?
Yes I did. The main terms are UpperCamelCase and lowerCamelCase. CamelCase is for for both. PascalCase is just another word for UpperCamelCase.
But I guess one can argue about the finer points for ever.
Martin
I iNsist (Score:3, Funny)
Re: (Score:2, Troll)
Given that it's also the one used by many other languages (Python and Ruby use it for method and variable names, for example), I don't see what's wrong with it. As they go, it's pretty readable. If you really want to see a
Re:I've never used it (Score:5, Informative)
A lot of the other nay-sayers appear to be just useless trolls. You don't, so I'm going to reply.
You're really selling boost and, by derivation, yourself short. Boost makes a ton of things simple and robust. I wrote the following, cross platform C++ code with boost:
C++ is old and that means that it doesn't have anything like a modern language has. What it's missing, Boost fills in (not completely, mind you, but it does a really good job). With C++ you get speed and controllable code (C# runs a close second, but I still wouldn't write an OS in it), and with Boost you get a ton of ease back in the language as well.
You're doing yourself a serious disservice by not looking into it. The one thing that I can't believe is that you really did look into it, and certainly not twice. If you did, you'd know it's not just a source of "template tricks"... far, far, far from it.
If you're not using boost, I can guarantee you're reinventing the wheel... badly.