Slashdot Mirror
Boost 1.36 Released
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."
it's a suppository. C++ may as well be...
Boost made one of my cross-platform projects extremely easy to write; wrapping network functions to account for differences between Windows and Linux was not fun.
they could get rid of the crappy_api_naming_conventions.
"Almost every modern C++ codebase uses Boost somewhere"? While I think it looks like a pretty useful set of libraries, I must admit that statements like this makes me less inclined to even look at it.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
For a real laugh, read the parent replacing "C++" with "C" and "Boost" with "C++"
Back in my day, we did metaprogramming the way god intended -- in the preprocessor, with recursive includes.
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.
~ C.
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
I know there are some people with a huge hard on over it. I've looked into it a couple times but it seemed overrated to me. It might be a good source of template tricks, but that's about it.
Do you even lift?
These aren't the 'roids you're looking for.
What's happening? Are these people from commercial sellers of C++ libraries saying bad things about Boost?
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 things about your code: The sizes and alignment requirement of types, the offset of members, whether methods with a particular signature resolve or not, etc.
Rather than funky template metaprograms which try to deduce these things by exploiting strange corner cases of the C++ standard, it would be nice if the metaprograms ran in a context where they had access to all of this information directly from the C++ compiler. It would be nice if the output of the metaprogram was source-code, too. (Much easier to debug that way, than by relying on obscure and cryptic error messages ala C++ templates). ..Of course, C++ is far too big and complicated for this to be done in a sane way. A much better bet is to design a new, smaller, cleaner language (aiming to have perhaps 10% of the complexity and 90% of the usefulness of C++). While you're adding metaprogramming in there, make some room for symbolic includes and a fast and robust incremental compilation system too. The textual includes of C and C++ are so backward its not even funny.
Get thee behind me, foul creature of Satan!
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.
24 beers in a case, 24 hours in a day. Coincidence? I think not!
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.
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 don't use Boost. But if it does what I needed, you can bet the farm I'd use it rather than waiting for Programming-Language-Du-Jour support on a given platform... For a frame of reference, consider the classic comeback to the apologist's "but Java runs on so many platforms" argument: "And how did you compile the JVM?".
I use DJGPP in DOS, you insensetive clod!
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 date/time functions?
If you aren't using boost, that's fine, but it is as excellent of a general purpose C++ library as we have available today.
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 so. He'll produce some awful, unreadable, undebuggable code.
Personally, I find boost quite useful, and I have never used it to write template metaprograms (it has other features as well). I think they are cool, but I just haven't run into anything where I needed that kind of performance boost.
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.
This sig used to be really funny...
Embedded compilers. Many of them don't support basic templates, much less all of Boost.
I still have more fans than freaks. WTF is wrong with you people?
Anyone that has taken the time to learn how to use boost::function and boost::bind will know that the boost libraries are brilliant. And that is only two of the many, many super cool additions boost brings to the table.
Boo hoo the errors are too hard to read. Grow a brain, no one said coding in C++ was easy.
Boo hoo it takes to long to compile. Get a quad-core, computing power is cheap.
You'll only take boost/shared_ptr out of my cold, dead hands.
The cake is a pie
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.
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.
Sam ty sig.
You know, your rant looks like something I would write. But if I had written it, I would do so knowing that I'm ranting only because of my personal discomfort with it and not because Boost is in any way flawed. I think you are doing the same.
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?
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?
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.
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++
ipv6 is my vpn
No room for doubt in this statement. You've just described white, black and all the greys in-between, but haven't specified any weight on these shades. "The associated statement is either true sometimes, true always, or true never" is a tautology—it's never false, regardless of the input.
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 all difficult things so that library user's lives are easier. And boost achieves that goal nicely.
Yes, a programming language with a clean, purpose-built metaprogramming facility would be extremely useful. But I think that doing it imperative style, as you seem to prefer, is a sure way to lose one's sanity.
For a frame of reference, consider the classic comeback to the apologist's "but Java runs on so many platforms" argument: "And how did you compile the JVM?".
By writing a ton of platform-specific code, spending hundreds of hours debugging compiler specific problems because none of them support the standards in exactly the same way, and in general spending far too long worrying about the details when there's a bigger picture to be dealt with :-|
... this is a comeback to be used *against* java? o_O
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Disagree, but not by a lot. I would say that boost emphasizes the aspects of C++ which both make it a powerful language, but also can make it a nightmare to understand. Boost is kinda like plugging into a nuclear generator: lots of power but very dangerous, and if you're not careful you'll spew radioactive garbage all over your code tree.
The overall success of applying the tool depends on the skill with which it is used. In the hands of novices, boost can turn a normal program into an unmaintainable disaster. Used sparingly, clearly, and with good design, boost can, well, "boost" your ability to write good code.
Yes, it would be cleaner if all the paradigms were in a new, clean, theoretical perfect language. However, for those people writing code now, C++ is pretty good, and boost can be a very useful addition in the right hands. Just be sure you know how to write good code before you start using it, and avoid any nasty explosions. :)
Even the gurus (Stroustrup etc) don't dare think about a new language.
I tried to use boost.bimap and my compilations got x10 slower. I then wrote my own bimap, with simpler interfaces of course, and compilation times got back to normal.
One of the biggest problems in C++ is header files. I am surprised they do nothing for this. The slowness of compilation of boost programs comes from parsing and compiling the huge amount of code that lives in the header files.
For some sort of argument like that you need to choose languages that are actually in the same space...
That's good advice, but you're missing something crucial: C++ and Boost are recommended by their diehard fans for application in almost *ALL* spaces, because of its very high-level facilities. As a result, the parent is right that Java can be directly compared with C++ and Boost, since there is a high degree of overlap in the claimed application domain.
Of course, such a recommendation is sheerest nonsense, so those diehard fans are just fanboys, rather than intelligent users. Unfortunately, there are a lot of them, and that's why C++ with Boost gets such a bad name, and why the proponents of languages such as Java and C# frequently point out how they can do far better.
That's the problem with having a high-level, versatile and highly capable library: it makes its less clueful users think that the application domain of the base language is now universal.
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.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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 I'm seeing of portability, compile-time performance, cryptic error messages, variable quality of documentation and the like are all fair.
Ultimately, Boost is a bit of a strange beast. C++ has a lot of merit as a practical, pragmatic language where you can get stuff done, but it's not a high level language by contemporary standards. Unless you actually need the low level flexibility and/or seriously high performance, it's usually a bad choice for new projects. Boost seeks to add the sort of high-level functionality C++ lacks and to work around some of the more serious limitations of the underlying language, but it's like a scary parody of Greenspun's tenth. If you really need to use C++, it has its place (but at a cost), but for most people who need that kind of functionality, there are numerous much better ways to get it (or to avoid the need for it in the first place) by choosing a more appropriate programming language.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I had a look in the cygwin mailing list archives a couple of months ago and insofar I recall, the issue was basically that gcc 4 doesn't implement exceptions in a way that is compatible with windows DLLs and apparently it's a lot of work for the few hardcore cygwin hackers to implement the necessary support.
VC++, GCC, Intel, Comeau... That's just off the top of my head. None of them are perfect, but they're close enough as makes no difference.
Either it works on your platform and compiler, or it sort of works, or it doesn't.
I find that to be the case with all software, everywhere.
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 oN tHe rIght tO uSe zAmbinian cAmel cAse.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Honestly ? Yes. Microsoft's compilers output better code and, in my experience, are faster at compiling than GCC is. Various IDEs for Windows let you use the (free as in beer) Microsoft compilers with them, so I honestly have no idea why someone would want to use MinGW unless they relied on GCC-specific extensions.
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.
----- 70% of all statistics are completely made up.
Replace "C++" with "assembly language" and "Boost" with "C", and you will get a Readers comments reply from a 1978 edition of BYTE magazine.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Which embedded platform are you on that has a C++ compiler? Most of them barely support the C standard.
That comment was at least seven different kinds of awesome.
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-case features and are very integral to the nature of templates. Admittedly, template syntax needs to be cleaned up a lot, but C++0x seems to be fairly on track for accomplishing a bit of that (meaningful compiler errors, yes please).
The debugging problem, as I understand, will be largely fixed in the next iteration of C++, that's just an implementation detail. As for taking forever to compile, well can you point to a language that supports the kind of metaprogramming C++ can do (as in, metaprogramming that produces code equivalent in speed and function to manually coded versions; things like C# generics just wouldn't cut it in C++) and compiles quickly? I honestly don't know.
A well designed template library can be a beautiful thing. I love using Spirit for non-trivial text parsing, for example; it's VERY straightforward and allows me to declaratively specify a text parser in just a few dozen lines of code in as close to direct EBNF grammar as you're likely to find possible in a general purpose programming language. The trick is just to isolate your parsing code in its own compilation unit and compilation speed isn't so much of a problem.
Oooh! I raise you an unholy combination of OpenWatcom and STLPort that barely works together for DOS targets.
Whoever designed Boost::ASIO has a fetish for the scope resolution operator.
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.
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 of it a lot (and use preprocessing to circumvent the differences).
We're talking mainstream here. Wanna go see what's going on on the lowest tiers of the market?
Of Code And Men
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 in GCC after writing it against VC++.
If you know of specific features that aren't well implemented across the mainstream compilers, please list them, but I haven't found anything that prevents me from using most features of the language (which is quite an improvement over just a few years ago).
Now if you step off the mainstream compilers, you will probably have trouble, but in those cases don't use Boost. You'll have to write more code yourself, but that's the price you pay for sub-standard tools.
Seriously... exceptions in C++ are the devil's spawn. Game developers don't use them at all, usually. The compilers for popular consoles even warn you not to use them, because of a performance penalty AND because they are not fully implemented in the compilers/libraries for that console (I'm not kidding).
Maybe you don't need to debug your programs. I cannot make a living as a programmer without doing so. When they do get it fixed (somehow, I doubt this assertion), I'll consider using Boost. Until then, no thanks.
There's no time to stop for gas, we're already late.
I only counted five. Help me out.
#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 are basing your complaints off of that. Why, then, would you be averse to using its portable networking library? Or its threading library? Or its filesystem access library? Or any of the other countless Boost libraries that provide very useful functionality without even touching template metaprogramming?
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 cross-compiler expression templates and dynamic type resolution libraries. I'm not talking export here, just using templates of templates to build expressions that should be inlined correctly at the end of the compiler pipeline. If it's compiled at all.
I won't find a real world code example, lets just say that when you enter the templates recursion, template operators and heavy template worlds, and you throw in some functors, binding and dynamic typeinfo (which are all standards, not some unsupported feature like export), what works on one compiler will choke the next one. I've had my share of "Internal Compiler Error". Those are nasty and almost impossible to resolve. And sometimes G++ just give up without an error code... oO
Saying that what works on one mainstream compiler should work on the other if you follow standard is the same as saying that coding POSIX guarantees you to work on all mainstream operating system. Theory is fine, practice showed us otherwise.
And boost came across these problems as well. Do you think the HEAVY use of macros and preprocessing is only there to render the code unreadable? :)
Of Code And Men
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 nightmares), but that just isn't a problem any more in my experience (and I do my fair share of template meta-programming). On the VC++ side 8.0 fixed most of the complaints I had, and on GCC 4.0 and onwards have been admirable as well. Intel's latest compilers have also been quite good in my (admittedly) limited experience. Comeau has always been very good. The differences just aren't that big any more, though again, there are some minor niggles (VC++ still has the odd internal compiler error, but I have been able to figure it out the couple of times it's happened the last few years.)
As for the features you mentioned, as I said I doubt the actual usefulness of export and so do most compiler writers apparently. That one doesn't bother me. Restrict was actually a new one for me, and I had to look it up. Looks like it's a C99 feature? You can hardly fault a C++ compiler for not supporting that. :)
Inlining seems to work wonderfully for me in any recent version of the big ones. They all support NRVO and RVO and do a very good job of eliminating static expressions, and unrolling static loops. I have a matrix math library that takes heavy advantage of this and I'm still stunned when I take a peek at the generated assembly. Deep recursive calls and huge functors compile down into nothing.
Implicit functions (If you mean what I think you mean, the old deprecated C feature) are not not allowed in C++.
All in all, the C++ compilers I work with are no longer standing in my way like they did some years ago, and it's bloody beautiful.
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++.
Need a Python, C++, Unix, Linux develop
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.
Need a Python, C++, Unix, Linux develop
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.
I still have more fans than freaks. WTF is wrong with you people?
Cross-compiling from Linux would be an argument for using MinGW. But not sure how the current state of c++ cross compiling is, especially in combination with boost.
I would also be rather interested in the experiences of others with MinGW+Boost. I'm currently trying to figure out if I should use ASIO for a new project (the other parts of boost don't matter that much for now for me) and I will work mostly on Linux but the stuff has to run on Windows in the end. And I usually use MinGW+gcc for the Windows part (although I also use the MS compiler often, if possible it compiles on all of them).