Comparing the C++ Standard and Boost 333
Nerval's Lobster writes "The one and only Jeff Cogswell is back with an article exploring an issue important to anyone who works with C++. It's been two years since the ISO C++ committee approved the final draft of the newest C++ standard; now that time has passed, he writes, 'we can go back and look at some issues that have affected the language (indeed, ever since the first international standard in 1998) and compare its final result and product to a popular C++ library called Boost.' A lot of development groups have adopted the use of Boost, and still others are considering whether to embrace it: that makes a discussion (and comparison) of its features worthwhile. 'The Standards Committee took some eight years to fight over what should be in the standard, and the compiler vendors had to wait for all that to get ironed out before they could publish an implementation of the Standard Library,' he writes. 'But meanwhile the actual C++ community was moving forward on its own, building better things such as Boost.'"
Boost Sucks (Score:2, Insightful)
There, I've said it. It's obscuratist beyond all reason and results in incomprehensible code of the type that any professional programmer should be ashamed of.
Re:Boost Sucks (Score:5, Insightful)
Boost is sort of like CPAN for perl- its a repository of libraries you can pick and choose from. It has some really useful things in it and a lot of crap. Talking about how good/bad Boost is is pointless, from a code perspective. Talk about how well or not well it works as a repository.
Of course, that makes the linked article pointless too- programmers write libraries for a language faster than the standards committee updates it? No shit. If they didn't, we ought to be worried.
Re:Boost Sucks (Score:5, Insightful)
Boost has on the order of 100 libraries [boost.org] , each of which undergoes a peer review
CPAN allows anyone [cpan.org] to upload their own code and has on the order of ~120,000 libraries.
Boost is a lot less like cpan and more like the development branch of the next standard library.
Re:Boost Sucks (Score:5, Insightful)
It sounds like you're missing the significance of Boost. I cant think of any other thing like it, CPAN included. Yes, it's a collection of libraries. That's not the interesting part. There's a reason so many of the C++11 library additions were taken directly from it with little to no changes.
Most projects you'll find code to the standards of the one or two people making them. The good ones are fairly flexible, but many of them fulfill just the specific needs of those authors.
Boost lies somewhere between that typical project design and a standards body. Its review process demands high-quality standards-worthy code without taking years to debate on something before anyone actually writes any code. Once libraries actually get in, it serves as an incubator to find out what works and what doesn't. Because it is coded to such a high quality and people are actually using it, it gives the standards body a lot of data to work with in deciding what should be next for the language. That's what makes it special.
Re: (Score:2)
I completely agree with you about the totally obscure error messages, but then even the STL is hardly immune to that. I think the biggest feature needed in the C++ standard is a convenient way to make template programming/meta-programming generate clean compiler errors. I believe there's actually a boost library dedicated to doing just that, but it's not nearly as convenient or reliable as something built into the language would be.
Re: (Score:2)
You didn't read the whole comment now, did you? :)
Re: (Score:2)
This is hilarious in so many ways. I don't care what boost is doing under the hood, I just want it to do what its interfaces say it does and to a great extent, it does.
That works well and dandy until you get incomprehensible (or hard-to-track) compilation errors. Then you want to know what boost "is doing under the hood". The panacea of interfaces that one can program against w/o zero problems has never existed, it never will.
Just the single boost::shared_ptr was fantastic in its time. Now we have a std implementation. There are many things in boost that are extremely useful.
True as it may be, it is non-sequitor to the original point you are replying to. Plus, shared_ptr is just one example within boost of a small, uncomplicated interface to something that does one single job well. There are other things that we could pi
Re: (Score:3)
This is why I hate javascript libraries like jQuery. The resulting code looks incomprehensible to someone who never used jQuery. Adding a 80KB+ download and another layer to a godamn interpreted language is just the cherry on top of the insanity.
Re: (Score:2, Flamebait)
This is why I hate javascript libraries like jQuery. The resulting code looks incomprehensible to someone who couldn't be bothered to spend five minutes leaning the basics of jQuery.
FTFY
Re: (Score:2)
the average jQuery download per page is way less than 80KB
The minified jQuery 1.9.1 is 91KB. Still small enough for your 'Net connection to barely notice though.
Re: (Score:2)
Re: (Score:2)
What I'd like to see is some way of automatically creating a custom, minified jQuery which only has the parts that your website actually uses. Suppose for instance you only use a handful of jQuery functions to do some cool effects; you don't need the entire library, just a small part of it. Why not make a custom version that's only ~10KB, just for your website?
Re: (Score:2)
Re: (Score:2)
Maybe the hope that someone else had thought of it before me and had already done it, and I just never heard of it? I'm under no illusion that all my ideas are totally original.
Re:Boost Sucks (Score:5, Insightful)
There, I've said it. It's obscuratist beyond all reason and results in incomprehensible code of the type that any professional programmer should be ashamed of.
Agree 100%.
Libraries are supposed to be understandable and easy to use. Boost just isn't. I don't know if the documentation or the design that's at fault but it always seemed totally opaque to me whenever I looked at it.
I could probably grok it if I invested enough time/effort, but what I get in return (eg. a reference counted pointer) never seemed worth that investment.
YMMV.
Re: (Score:2)
I wish they had taken a look at Qt instead. Qt is pretty similar in that it's C++ metaprogramming, and adds a bunch of libraries on top of C++ and new keywords and such (like foreach for dealing with container classes). However, the resulting code is extremely easy to read, unlike the Boost examples I've seen.
Re: (Score:2)
Agree, a template mess with ass backwards documentation.
The underlying problem is actually the use of templates themselves.
Outside of these monolithic libraries templates are mainly used to implement custom generics, but ultimately its a horrible way to have to do it unless you dont give a rats ass about type constraints and the eventual nearly-useless error messages that will result from not giving a rats ass about type constraints.
Essentially, to do generics well in C++ requires a mountain of boiler plate, which leads to an entirely new definition of the
Re: (Score:2)
Templates do a very good job of implementing generics. A std::vector carries all type information along with it, and its member functions can be specialized as needed. They are something that's a lot easier to use than to write properly, and there's a bit of an art to reading the error messages, but overall I've found them to work very well. Stroustrup's introductory programming book "Programming: Principles and Practice Using C++" starts the newcomer out with their use.
I do keep wishing I had Common
boost? (Score:2)
what are the odds.
need more meat in that article (Score:5, Informative)
instead of verbose vagueness need to have lists of comparisons between standard libraries and boost. is this author practicing to be paid by the word?
Re: (Score:2)
The author is a slashvertising Dice employee who clearly isn't that much of a programmer judging by what he wrote. His story read more as kind of a 'heres how I show you I'm a newb' than anything else.
C-like C++ is the way to go (Score:5, Insightful)
I just cannot embrace the mess C++ became anymore. Life is too short to learn C++. Basically I'm using "C with classes" today, without STL, Boost or any of these aberrations.
Re:C-like C++ is the way to go (Score:5, Insightful)
The container classes (list, map, vector, etc) in the STL are good enough to be worth using. And of course string. Going full out with functors, generic programming, etc does frequently make an unreadable mess, but no need to throw out the good parts with the bad.
Re: (Score:3)
I have to agree 100% with your comment. If you want to make a mess, C++ sure will let you (kinda like C). But, if you don't let yourself wander around with all of the possible functionality and just stay with the basics, C++ will allow you to do just about anything you want in a truly readable and supportable way.
Re: (Score:2)
Hell, last place I worked they gave me a reference implementation of a C# webservice that had a single method call... that was comprised of 60 .cs files. (yes!! I know!!)
So its easy to make a mess in any language, it is entirely down to the coder. If you consider yourself a uber-coder who can write the most convoluted templated C++ code, then I have to tell you that you're useless. Similarly, if you take 60 classes and interfaces to make a single-method web service, you're also useless. It doesn't mean C++
Re: (Score:3)
I have to disagree - if you actually *are* an uber-coder who can write *reliable* convoluted code you may be extremely valuable *if* properly utilized. Because sometimes truly hideous convoluted code really is the best solution, *if* it allows you to concentrate a lot of ugliness that would otherwise be scattered throughout the larger code-base behind a simple, clean interface - just look at the actual implementations of some of those nice, easy-to use Boost and STL libraries.
Heck, I've written some truly n
Re:C-like C++ is the way to go (Score:4, Insightful)
I don't know what practical problem does std::string solve, because sure as heck it doesn't provide most of what you actually need to use strings in real life applications. Qt's QString and the associated codec infrastructure is pretty much what you need. std::string is a solution to a problem that nobody has. If all you need is to pass around safe arrays of characters, then std::vector does it for you, duh. std::string is a safe wrapper for C strings, and that's the whole problem: modern software has outgrown C strings two decades ago.
Re:C-like C++ is the way to go (Score:4, Insightful)
However, the std::string classes were designed too soon, and a lot of the member functions are clumsy and should have been offered as generic stl algorithms. It's probably best to consider them deprecated.
Re: (Score:2)
Then you're not making the most of it, or not doing anything sufficiently complicated to warrant use of such a library.
That's fin. You're not the target of these things. But maybe you are. But be aware by using a best-of breed toolkit:
- Common operations are always done by 'best-practices'. Your employment and talent pool are 'standard' meaning finding talent that knows how to work in your code base is not a problem. As well as you knowing how to work in other's code.
- simple stuff like foreach() and other
Re: (Score:2)
To me, the distaste for iterating over a counter (i.e. a traditional C for loop) is the perfect example of much ado about nothing. If your implementation of "apply" gives me parallelism for free, then great, but otherwise it's one of those obsessive stylistic things that really does not matter.
Re: (Score:2)
Disagree. Using foreach with a function pointer or functor separates the body of the code from the loop implementation and greatly increases debugging time and maintentance cost. It hurts more than it helps. This isn't true for other languages like perl, Java, etc where the implementation is cleaner, but the STL foreach is garbage.
Re: (Score:3)
Agreed. If C/C++ at least had local functions, you could put the body somewhere close, or even right where it belongs by using a wrapper macro. I find it hilarious that shit that was a well solved problem in Pascal never made it to C++. The pimpl idiom is completely unnecessary in Pascal, because separation of implementation from interface is a part of the language. In C++ it's a yet another manual task you have to deal with, and you always pay for it in non reference-counted classes -- it costs you the ext
Re: (Score:2)
Apparently you either haven't heard of Linux, or are under the delusion that it "isn't sufficiently complicated". Plenty of "sufficiently complicated" software gets implemented fine using C in a "C with classes" style sans STL, Boost, etc. C++ with STL, Boost, etc. is a way to do what you describe, not the way to do it.
Re: (Score:2)
That's a very short-sighted view. Boost is a credit to the community that created it and so is the STL. They might not be the best tools for every situation, but I dare say they aren't "aberrations". C++ and the STL aren't really difficult as long as you're a disciplined programmer.
Re: (Score:2)
If you're using malloc() instead of std::vector, std::string, etc. then you're doing it very very wrong.
RAII is what makes C++ robust, reliable and scalable, and you're fighting against that.
ps: new[] and delete[] are nearly as bad as malloc() (and are one of the few things that should be deprecated from the language IMHO).
Re: (Score:2, Insightful)
I just cannot embrace the mess C++ became anymore. Life is too short to learn C++. Basically I'm using "C with classes" today, without STL, Boost or any of these aberrations.
Out of curiosity, is this desire for self-inflicted misery part of a larger BDSM kinda deal or is it due to willful ignorance of standard practices and idioms that have been well entrenched in the C++ community for the better part of a decade now?
Re: (Score:3)
C, **not** C-like C++ is the way to go (Score:2)
C-like-C++ kinda combines the worst of both worlds.
At that point, I think you'd be better off using straight C (which I like a lot and think is the best tool for most jobs), or full C++ (which bugs me, but I admit I like the STL better than C collections).
Re:C-like C++ is the way to go (Score:5, Funny)
all the readability of Perl with the compilation times and ease-of-debugging of heavily templated C++, woohoo!
Re: (Score:2)
C is the way to go (Score:5, Interesting)
C code doesn't have to be procedural. You can implement classes and objects and what's more, you can actually understand how they work when you do. You can create just about anything you want (not everything, but very near.) You'll know what you are writing. You won't be including incredibly overweight code that bloats your app and slows it down. You can manage memory intelligently, you can construct very maintainable code, and you can be quite concise about it.
What you're running into, I suspect, is programmers that aren't experts in either C or OO. They know how to use the bits of OO that C++ "cans" for them, but if you told them to build such things... C++, like any HLL, has its place holding the hands of mediocre programmers, and also in empowering truly excellent programmers. But C is enormously capable and from my personal experience, it's hugely more maintainable, less verbose, and more to the point than C++ simply by virtue of the fact that the language space is much smaller -- only as large as it actually needs to be, with very few exceptions. A true object can be built in C without any of the cruft or "mommy" limits; it can be highly efficient in terms of both memory used and execution time. It won't end up being megabytes just to get a basic UI going.
The amount of "stuff" a programmer needs to know about a language gets in the way of the amount of "stuff" that same programmer needs to know about programming techniques in general and the specific task(s) at hand.
Every once in a while, I have to write in C++. I'm pretty good at it -- experts in C tend to have a good basis to add C++ concepts on top of. I even enjoy it. But contrary to your experience, I have found that most C++ code I have to deal with from others is very bad from the POV of maintainability, bugs (and they get a lot more obscure) and in being much more verbose (just a typical C++ header file makes that point rather well, without even getting into code.)
The worst thing I run into is the assumption on the part of OS documents that you will be writing in C++; pretty soon, you have to capitulate and get the C++ written, just so you can interface with the bloody system. All of a sudden, you're pulling in huge chunks of code you never heard of and have no interest in, and you have a form of the classic many-megabyte "hello whirled" program. Ugh.
Re: (Score:2, Troll)
C code doesn't have to be procedural. You can implement classes and objects and what's more, you can actually understand how they work when you do. You can create just about anything you want (not everything, but very near.) You'll know what you are writing. You won't be including incredibly overweight code that bloats your app and slows it down. You can manage memory intelligently, you can construct very maintainable code, and you can be quite concise about it.
Ok, but on the other hand you can also end up with things like GTK.
Re:C is the way to go (Score:4, Insightful)
Ok, but on the other hand you can also end up with things like GTK.
You mean like, an object model that provides dynamic signal-slot binding, properties, introspection, and bindings to really productive high level languages such as JavaScript and Vala? Count me in favor.
Re: (Score:3)
Re: (Score:3)
Of course not. What I can do, however, is point out that people who write in C++ don't write those things; they use the language's own constructs, and so they don't know what's going on -- only that it is.
Because then I know what it does and so can both modify it at the most basic level if need be, it
Re: (Score:3, Insightful)
What I can do, however, is point out that people who write in C++ don't write those things; they use the language's own constructs, and so they don't know what's going on -- only that it is.
Most C++ programmers I know, myself included, know very well about what's going on in the code that compiler generates. Don't assume that just because something is automated, people who use it are unaware of how it works.
Re: (Score:3)
Do you have experience with C++-style memory management, and what's your opinion of it?
You mean through a GC library, or are you just talking about heaps, new and delete as opposed to malloc and free and so on?
He almost certainly means RAII. Which is something that is, indeed, sorely missing from C, necessitating ugly goto-based cleanup path for most nontrivial functions.
Note that this doesn't necessarily imply objects and destructors. Just basic scope guards as a language feature would make vanilla C so much less painful to write safe and correct code in.
I never liked the idea of C++0x11 (Score:4, Insightful)
We had decent (not perfect) C++ support. Now we go and fragment the industry by inventing a new standard. Code developed to the 0x11 standard won't work on legacy systems with legacy compilers.
Meanwhile boost and Qt worked around the C++ limitations without introducing any compiler differences. I think that was the right approach. True not all things could be delivered without messing with the compiler, but a good many were.
Now my only problem is that Qt (the leading C++ library aside from stl) and boost are not compatible. Boost has the more permissive license, but it is its own license, and boost additions can be under their own license. The Qt library is now LGPL (or commercial), and as of Qt5, Qt is divided into even smaller modules.
I hope the community does not fork again (C++ vs 0x11) with boost vs Qt. I cannot decide whose library should be adopted. But whatever comes to pass, I hope either Qt adopts boost or boost adopts Qt, to prevent further fracturing of C++ community.
Re:I never liked the idea of C++0x11 (Score:4, Interesting)
> Now my only problem is that Qt (the leading C++ library aside from stl) and boost are not compatible.
You write as if you know what you're talking about, but this is flat-out wrong.
Certainly there are duplicated ways of doing things (improved filesystem support immediately springs to mind), but I've worked on lots of commercial code that uses both libraries, and I've seen similar elsewhere. Generally speaking, using Qt for GUI and other system-type abstractions, and boost for lower-level things such as multi-dimensional arrays, geometry, testing (even smart pointers back in the day). I've written boost AND Qt based code today, for the same project. There is no reason not to use both in any given project.
Re: (Score:2)
I've worked on projects that have used QT and ones that used Boost, and one giant mess that used both, and so I have to disagree on the hope that they adopt each other.
Both provide useful tools that don't need to be mixed up. Boost is (afaik) the leading edge for what the next C++ standard will contain. Boost does the crazy things, the good ones get polished and eventually become standard C++.
I love QT, but I can't imagine it becoming part of the C++ standard. So much overhead for things that you don't alwa
Re: (Score:2)
We had decent (not perfect) C++ support. Now we go and fragment the industry by inventing a new standard. Code developed to the 0x11 standard won't work on legacy systems with legacy compilers.
Yeah, and while they're at it they should roll back the c++98 standard too, since a previous employer was stuck with a pre-standards compliant C++ compiler and couldn't use such useless features as the STL. Personally, I think you write code to your requirements. No need to hold the industry back because your system only understands COBOL 74. C++ desperately needed an update. Unfortunately it still needs it, but at least it's incrementally better.
Re: (Score:3)
I hope the community does not fork again (C++ vs 0x11) with boost vs Qt.
There is not much of a united community to split along these lines. Pragmatic developers and open source folks tend to use Qt. Wankers who like complexity for complexity's sake, and some developers who build monolithic applications for in-house use may prefer Boost. It's very impractical to use Boost with reusable code, which for the past couple decades means shared libraries. The generative programming wankers who have been shaping the design of C++ never noticed the importance of shared library support. Y
Re: (Score:2)
Again, more confusion created by crappy naming scheme.
Re: (Score:2)
I'm talking about forward compatibility, not backward. It's easy for some new project to get the latest compiler, but this is not the way software development is done. Real people on real projects develop code bases which must be maintained for a decade or more. Sometimes we can just pick a new compiler, sometimes we can't due to regressions and such. Meanwhile new features are being developed in the real world, features like XML parsing, JSON, etc. The libraries for these, if developed in C++0x11-17/5*pi w
Re: (Score:3)
You don't have to use Qt's build system to build programs using Qt.
While on topic, their container and string classes have such great APIs that I often use it in school projects just for that.
Re: (Score:2)
CMake is a custom build system, and a really badly documented build system on top of it.
waiting, waiting (Score:2)
If you wait for another decade to come up with an update to the standard, you'll find even more independent libraries and implementations. People need to solve their problems now, they can't wait for somebody else to decide what to include into a standard. Example: a native string object must exist in a language of 21st century, so must a list, a set and a map.
Re: (Score:2)
oh, and should that string object only support the unicode encodings, or also the extremely popular character encodings that have been in use in countries for decades that all their systems currently use? what if a country has proposed a better unicode set than what the standards committee rammed down their throat?
Slam me all you like (Score:2, Informative)
But the day I walked away from C++, Boost and MFC (mutha fucking classes) and joined a C# .Net shop was the happiest day of my life. Slam it all you like, but for UI development, Boost and MFC /Win32 is the worst platform to develop on unless you are a clueless sadomasochist that enjoys pain and suffering.
Re: (Score:2)
But the day I walked away from C++, Boost and MFC (mutha fucking classes) and joined a C# .Net shop was the happiest day of my life. Slam it all you like, but for UI development, Boost and MFC /Win32 is the worst platform to develop on unless you are a clueless sadomasochist that enjoys pain and suffering.
Don't worry, everybody hates MFC/Win32. Use Qt if you want C++, C# if you don't and I think there's a full dozen more obscure languages/toolkits I'd try before MFC *shudder*.
Re:Slam me all you like (Score:5, Funny)
"the day I walked away from C++, Boost and MFC"
I have considered this in detail, and I think I may have spotted a problem with your argument. It can perhaps best be explained with the following example:
"the day I walked away from peanut butter, jelly, and shit sandwiches"
Use the right tool for the job (Score:2)
Boost and MFC /Win32
Agreed. Writing GUIs in C++ isn't that much fun, and GUI logic doesn't need the theoretical performance that C++ could give anyway. Just because C++ is not the right tool for every job does not mean that it is intrinsically bad.
Re: (Score:2)
As someone who absolutely loves C++ and hacks on it all night and weekends, but writes C# at work, I have to agree with you. It has nothing to do with the language, really, but the libraries.
C# has far better libraries available than C++ does. I think if C++ got WPF, LINQ, and all the networking libraries like C# has, I'd be just as happy to work in it. Actually, it does have LINQ now.
Re: (Score:2)
lord no, not the convoluted, bloated, slow mess that is WPF. Even MFC was better for coding GUIs than that. Sure, its more powerful, but the hoops you have to jump through to make it work! A class with a variable and a get/set property for every control you want to get the data from. The IPropertyChangedNotification interface that needs implementing. The binding declarations in XML! Horrible.
C# has more libraries in one place than C++ has, which makes people think its got more of them. The trouble with C++
Re: (Score:2)
C++ isn't lacking for libraries, but it is lacking in consistently designed standards-quality libraries. That's all I meant. A UI, I think, shouldn't be built into C++. The majority of the stuff in the .NET framework certainly could and should be.
Re: off-topic opiniony things:
WPF is quite pleasant to use after you get the hang of it. Not to imply that you haven't got the hang of it, of course. I've never used MFC (just stuck with plain Win32) so I can't compare to that, but it's by far the best of the UI fr
Re: (Score:2)
joined a C# .Net shop was the happiest day of my life. Slam it all you like, but for UI development, Boost and MFC /Win32 is the worst platform to develop on unless you are a clueless sadomasochist that enjoys pain and suffering.
MFC was pretty nasty, especially back in the late 90's when it was changing around quite a bit. I switched to Windows Forms when it became available and now I'm stuck, kinda used to that and finding it a tough go to use WPF. I can relate to your comment, I like C# and am glad to be away from C++.
Re: (Score:2)
The day you gave up using the wrong tools for the job on a MS platform was a happy one? What a surprise.
Re:Bit stale (Score:5, Insightful)
I don't consider myself a "professional" programmer, though I've certainly programmed things that are used in my workplace, saved quite a lot of money for employers by doing so, and programmed things since I was a child on any number of languages. If I see a program and can't work out how it does what it does, I'm quite happy to tear it apart just to see how they did it, and even - when source isn't available and reverse-engineering isn't practical - re-create my own version to see if my hunches were right.
C++, to me, is just gibberish. I sat and read any number of books on how great OOP was and how C++ use these things and I have to admit, for many years, I was convinced. It was only when I got out of contrived examples and tried to understand another programmer's code that I realised that - actually - C++ just gets in the way. Boost even more so. I'm sure there is a way to make it lovely and I'm sure if you do it day in, day out and nothing else, that you get used to it and begin to see it - like reading music or anything else.
But a programming language is a LANGUAGE - something that facilitates communication. That's not *always* just between the computer and a human, but between two humans using computers, for instance. And there, C++ really falls down. I've seen projects that were created in C, built up in C, got famous in C and then converted to C++. I followed everything in them, even sending patches and hacking my own code into them, right up until they converted. And then they became a mess that I didn't like to touch, and certainly couldn't contribute patches to any more.
I get a lot of flak for that opinion, but I can write C99 code that does just about anything I ever want. I haven't yet thought "What this really needs is C++". I've even re-created object-oriented concepts in C99 and been perfectly happy with how they work and how to understand them.
And the fact is that a random bit of C99 code posted by a decent programmer - you can normally get the grasp of it quite quickly. A random bit of C++ code? You could be there forever checking overloaded operators and class declarations to see what the hell it actually does. Sure, you can obscure code in either language, but C++ seems to go out of its way to make even simple concepts obscure when expressed within it (don't even get me starting on templates).
I'm just not sure that the effort of "learning" C++ inside-out to the point where all that gibberish just becomes second-nature is actually worth it for the return, compared to just working a little harder on some basic C99 code to do the same things.
Re:Bit stale (Score:4, Insightful)
The problem with your C99 comparison that, by comparison, a random bit of C99 code does trivial things described in great detail, whereas an equivalent bit of modern C++ code is able to execute orders of magnitude more business logic. Don't get me wrong: C99 is great for close-to-the-iron bit twiddling and severely resource constrained execution environments, but C++11 is able to offer equivalent performance, the ability to tackle complex problems and vastly greater expressiveness.
There is of course one major caveat: C++ requires more experience of the programmer to produce maintainable code. Otherwise, you are even more likely to end up with unmaintainable gibberish than you are in C99. But against poor programmers the gods themselves debug in vain.
Re: (Score:3)
boost.function, boost.asio, boost.optional, boost.foreach, boost.shared_ptr, boost.ptr_container
start using those libraries (at a minimum), and C++ coding starts to become as easy as scripting. Of course, you'd have to learn C++ first.
Re: (Score:2)
Is your problem with C++ specifically? Or are are you having trouble getting your head around object orientation? And no "re-created object-oriented concepts in C99" isn't real object orientation.
Have you actually done much with another real OO programming language? Java, Objective-C or C# for example?
Re: (Score:2)
Computer languages are meant to be read and written by people, yes. Your complaint, however, that "C++ really falls down", coming from someone who admittedly doesn't know the language and library, is a bit like me complaining that "French really falls down" when I haven't bothered to learn French. Or that idiomatic English constructs like "I couldn't care less" (which means exactly the opposite of its literal meaning) imply that "English really falls down". I can't read Lisp well ... but I don't have the
Re: (Score:2)
How I have seen the phrase "I could care less" is as one with an implied clause beginning with "but" following it.
ie.... "I could care less [but then I would have to work at disliking it]" or something similar. Slight emphasis is implied on the word "could".
Taken by itself, literally, it makes no sense, of course.
Re: (Score:2)
Re: (Score:3)
Fair warning: I program but am not a "programmer". That is to say, I have educational background in object oriented programming, STL constructs, and design patterns, but I'm not a software engineer so it doesn't get used much. What does get used is C, because in embedded systems it come sup quite a bit.
The issue I have with any argument about which tool is better is that the problems solved by C++ don't come up much for a large swath of problems, but they come up constantly for others. If the object-orient
Re: (Score:2)
So how do you create generic arrays in C99?
By using #define's?
That's the way we used to do it, but thank heavens, we have templates now.
Yes, C++ is a mess, but please don't tell me that C99 is everything.
Re: (Score:2)
na, you just haven't understood the language, that's the problem.
I would recommend starting with "C with classes" to get started, and use a C++ compiler so you can use the STL collections like map and list. (no more writing your own list class!)
C with classes is a great way to start getting into C++, instead of your usual 3 functions, init(), dowork(), and close(), you migrate those into functions within a class - just wrap them with class MyClass{ } and you're nearly there. Then rename the init into the cl
Re: (Score:2)
Where should warm and fuzzy really come from? (Score:4, Insightful)
You can get that same warm feeling by writing good code in C, assuming only you have the skill to do it. Furthermore, when it is useful and appropriate to step outside the paradigms that C++ would force on you, but you can choose to use in C, you can. You'll understand why you did it, what you saved or cost yourself by doing it, and it won't be buried underneath some ridiculous, time-and-space wasting get/set layer, etc.
Not saying C++ is bad. Far from it. But I am saying that C is fully capable of supporting strong, highly correct programming, and that if C++ restrictions (or those of any other language) are the source of your feeling of having "done it" correctly... it's very likely there's more basic programming landscape for you to explore.
Re: (Score:3)
And you can just as well enforce e.g. a get/set function layer in C, too - just hide struct definitions from header files.
There is literally nothing that C++ forces you to do that C doesn't, with all other things being equal. Well, except for casting the return value of malloc.
Re:Bit stale (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Nice try, Steve Ballmer.
Re: (Score:2)
The narrow niche would be most graphically intensive software. Which wouldn't be that narrow.
With libraries like QT, it's also quite handy for Desktop Apps and you can easily prototype in python (via bindings PyQt or PySide).
I still go back to the problem of programmers going at things the wrong way. The problem is that there are so many ways in c++ that you discover after years that you still had better means of achieving things.
In that sense, languages that force style and other decisions upon you (like
Re: (Score:2)
You are joking, right? Graphically intensive programs use OpenGL/GLSL and don't do it in software. Only a shitty designer chooses C++ to do graphics *in software*. I'm writing a modern multi-threaded jet combat flight simulator in Java and find that Java has several huge advantages over C++: muti-threading and in-particular multi-threaded resource management is easier in Java than C++; my development time for pieces of work is much faster than when I used to use C++ for development; I have much better tool
Re: (Score:3, Interesting)
Worse, you have no fine control over cache line efficiency in Java,
Re: (Score:2)
There has been some uptake in C# usage. Even more significant is Java is now back as king-of-the-heap (at least according to TIOBE). I put this down to two factors: enterprise projects deferred in the worst part of the recession now need to be implemented, and: not only does 'Java' include Java-the-language, it also includes Groovy (good for those who like the dynamic language tightrope walk) and Java-for-Android.
While C# has some very nice language features it can never make up for the fact that fundame
Re: (Score:2)
While I agree with you on the whole that Microsoft is quite adept at killing things, and that one of their sharpest tools is in fact getting people to use their software, I think you'd have a pretty difficult time getting actual competent people to do so.
Re: (Score:2)
, or whatever, which is much shorter, less code for your to screw up and almost certainly bug free from being used/checked b
Re:I don't like boost (Score:5, Insightful)
Some of your requests will never happen, and with good reasons, I'll explain:
e) Fix the macro language so it is type safe
The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
16/32 characters are fully supported in c++11, see char16_t and char32_t. I could be wrong, but I don't think I've seen a language which has 24-bit characters. It would likely be inefficient to support anyway since I'm not aware of any architectures which 24-bit access is properly aligned.
i) Fix the darn grammar so that compilers accept UNICODE source
Many compilers already do support UTF-8 in source code. But I do agree that this should just be standardized across the board.
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
NO. You will probably disagree, but this is part of the *strength* of both C and C++. By allowing something to be undefined or implementation dependent. The standard is allowing the compiler to choose the most efficient code to emit. If the standard were more specific in these places, we'd have a "one size fits all" solution which would be optimal for some architectures and very much sub-optimal for others. Better to let the compiler writers who know the arch best to decide these things.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
When is C++ going to add reflection support?
It probably won't because it's not well suited for how things work in the language. Here's (part of) the problem. With templates and optimizations, often there can be 100's of types created during compilation which are independent but get optimized away to literally nothing when finished. Should the compiler waste time and space generating reflection information for types which simply don't exist at runtime? Should the compiler emit reflection information for each and every template instantiation of std::vector that your program uses? You can't do one set of reflection's for each template, because different specializations can have different members! It spirals out of control really fast. Personally, I would not be apposed to an opt-in reflection system. You use some special syntax, let's say:
reflect class T { };
or something like that. Which would then add extra stuff to the std::typeinfo object associated with that type. So that way you could in theory do something like this:
typeof(T).methods(); to get a list of methods for T, IF you have opted in. But I don't think that will happen.
Re: (Score:3)
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this.
Do you know why not? This seems like such a simple operation.
Re: (Score:2)
k) Add a proper exponent operator
Won't and Can't do this efficiently. Not all CPUs have an intrinsic way to do exponention. This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation. Once again, not everyone uses an Intel CPU.
q) Add a proper rotate-left and rotate-right bit shifts
See the answer to exponent operations. Simply put, not all CPUs have this. I would however welcome a standard library function for this like pow for exponents. Which the compiler could inline to a single instruction if the CPU supports it.
I agree with most of your points, but I can't really agree with your logic on these. Hardware floating point support wasn't common until the 486 days. A lot of lower end CPUs used to omit support for division. That didn't stop C/C++ from including support for those features.
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it. They were probably left out originally to
Re:I don't like boost (Score:5, Insightful)
I think the reason for omission is simply that the operators are nothing more than syntactic sugar. Anyone that needs those operations can write them quickly without putting much thought into it.
Both the GP and you are wrong about this. Hardware support for exponentiation is completely irrelevant to it being a built-in operator rather than a function call.
FORTRAN, famously, has some extremely efficient tricks for implementing exponentiation by small integer exponents (up to 7, if memory serves) that are independent of MPU support. They are handled by the compiler. Why C/C++ doesn't have this is beyond me, and writing these things efficiently for a given architecture is non-trivial and better handled by the people porting the compiler than application developers.
Re:I don't like boost (Score:5, Insightful)
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
Why? Sometimes the user wants to use types which are relative to the CPU word width, but don't want to be tied to a specific bit width. Remember, not everyone who codes in c++ uses an Intel CPU.
I think if you asked people how big a short or long is, 99% would answer it's a fixed size and of the 1% that in theory knows it's CPU-dependent 99% of them don't use it to create any intentionally different behavior on different CPUs. The 0,01% that really use this could have something like a set of typedefs in a platform configuration file, while the other 99,99% won't get bitten in the ass by flawed assumptions that a short will always be 16 bit. Nobody but C/C++ has this ambiguity in their most basic units that are used in pretty much every example, pretty much all other languages, databases etc. have found it sane to define them exactly. Sorry, but this is a horrible part of C/C++ even if you happen to like it.
Re: (Score:2)
e) Fix the macro language so it is type safe
The macro language is not part of the c++ language. As far as I know, Bjarne would have loved to get rid of it entirely, but it was kept to help maximize C compatibility.
C11 introduced Generic Selection which allows type control in macros. Too bad C++ diverged so much from C.
Re: (Score:3)
m) Add proper multiple return types
This would be nothing more than syntactic sugar. Why is using a struct such a big deal?
It's been done the C++ way: add the generic tool, and natural uses flow freely.
e.g.:
tuple foo() ... ...
{
return make_tuple(1, 2, 3);
}
int a, b;
float f;
tie(a, b, f) = foo();
And with move constructors, it's efficient too!
Re: (Score:2)
>When is C++ going to automatic garbage collection WITH the ability to tell the garbage system how many milliseconds you are allowed to use (inclusive from ZERO.)
And how exactly is that supposed to work? Garbage collection that's not allowed to run = no garbage collection, and you've just converted your program into one huge memory leak. If you want low-overhead "garbage collection" use smart pointers.
Re: (Score:2)
b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,
I'm not quite sure what you mean here. Do you mean generate compiler/platform independent code (some IR like bytecode/LLIR)? Or do you mean ntoh/hton and the like?
h) Provide PROPER 16-bit, 24-bit, and 32-bit characters
i) Fix the darn grammar so that compilers accept UNICODE source
j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters
Should both be fixed with C++11. Except 24-bit characters, which I've never heard of before.
k) Add a proper exponent operator
l) Add a proper wedge operator, along with inner and outer product operators
Seem rather special-cased here.
m) Add proper multiple return types
You can do this by returning a std::pair, a std::tuple, or a structure you build. However, I don't believe there is an easy syntactic way to split a pair/tuple into multiple local variables.
n) Fix all the times the spec says "undefined" or "implementation dependent". The point of a spec is to SPECIFY what the operations do, NOT to be ambiguous because in some idiotic universe 'char' is not exactly 8-bits.
Never going to happen. Most of those
Re:Academic (Score:5, Informative)
For example, try to create a random number from 0 to 1.
This is almost always an error. Your poor use of terminology on this matter tells me that you've probably implemented the error.
It is nearly always the case that when you think that you need a value in the range [0.0 to 1.0], that what you more precisely need is a value in the range [0.0 to ((double) RAND_MAX / (RAND_MAX + 1))]. Otherwise any sort of binning done with this value (such as selecting a random element from an array) will have non-uniform distribution.
You will thank me some day.
Re: (Score:2)
#include <random>
// uniformly-distributed integer random number generator // mersenne twister rng // uniform distribution on interval [a,b)
class RandomGenerator {
private:
std::random_device rd;
std::mt19937 gen;
std::uniform_real_distribution<double> dis;
public:
RandomGenerator():gen(rd()),dis(0,1)
double getNext() {
return dis(gen);
}
};