Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comparing the C++ Standard and Boost

Soulskill posted about a year and a half ago | from the shaping-an-industry dept.

Programming 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.'"

Sorry! There are no comments related to the filter you selected.

I don't like boost (0)

Anonymous Coward | about a year and a half ago | (#43182513)

Want to use boost? Header only, right? yeah, well, there are so many damn interdependencies it's a mess. And while are some gems in there (the good ones made it to c++11), there's a lot of total garbage. And they seem to go full retard with regards to doing everything in the most c++ way possible.

Re:I don't like boost (1)

Anonymous Coward | about a year and a half ago | (#43182785)

boost::asio::wew::hew::fuck::you

Re:I don't like boost (0)

Anonymous Coward | about a year and a half ago | (#43183251)

Doesn't compile. Have you meant:

using namespace boost::asio::wew::hew::fucks;
using namespace boost::asio::dang::bling::people;

boost::asio::wew::hew::fucks::fuckfactory fuck(BOOST_DEEP|BOOST_SLOW);
boost::asio::dang::bling::people::ldap_directory::entry you(BOOST_FIND_THEM_VERY_FAST_AND_EFFICIENTLY|BOOST_OR_ANYBODY);

fuck(you);

Re:I don't like boost (0, Redundant)

UnknownSoldier (67820) | about a year and a half ago | (#43183335)

You are 100% correct Boost is bloated and over-engineered.

Take a look at the CRC mess in Boost. Over a 1,000 lines of crap. Oooh, you can generate it for any CRC polynomial. Big Freakin Deal ! I want code that is fast, easy to read, easy to write.

Meanwhile us C/C++ guys follow the KISS principle.

const unsigned int CRC32_REVERSE = 0xEDB88320; // reverse = shift right
 
bool CRC32_Init()
{
    for( unsigned short byte = 0; byte < 256; byte++ )
    {
        unsigned int crc = (unsigned int) byte;
        for( char bit = 0; bit < 8; bit++ )
            if( crc & 1 ) crc = (crc >> 1) ^ CRC32_REVERSE; // reverse/reflected Form
            else crc = (crc >> 1);
        CRC32_Table[ byte ] = crc;
    }
    return ( CRC32_Table[8] == (CRC32_REVERSE >> 4)); // printf("ERROR: CRC32 Table not initialized properly!\n");
}
 
unsigned int crc32_buffer( const unsigned char *pData, int nLength )
{
    unsigned int crc = -1 ; // Optimization: crc = CRC32_INIT;
    while( nLength-- > 0 )
        crc = CRC32_Table[ (crc ^ *pData++) & 0xFF ] ^ (crc >> 8);
    return ~crc; // Optimization: crc ^= CRC32_DONE
}

Ever Since 32-bit CPUs have become commonplace there is a tendency for programmers and designers to include everything AND the kitchen sink. This is the biggest tragedy in programming.

High-Level languages suck because they are a) verbose, b) Jack of all trades Master of none.

The root problem is that C++ is over engineered. I love a _pragmatic_ approach -- the balance between C's minimalism (and lack of type safety) and C++ bloated design.

Having worked on a popular professional C++ compiler it was interesting because I didn't have to deal with the clusterfuck of the C++ grammar.

There are many problems with C++ that the designers and committee continue to ignore. There is that old C++ joke.

There are two problems with C++:
  * Its design, and
  * Its implementation

The biggest problem C++ has is that the preprocessor doesn't understand types and templates are STILL have baked. Every year C++ moves closer to LISP while missing the _simplicity_ of LISP and adding the verbosity of Cobol.

Why do you think LLVM was started? Because the hundred-lines-long C++ error message spew is of the "If you can't dazzle them with your brilliance, baffle them with your bullshit" mentality.

a) Add a PROPER 'alias' and a PROPER 'type-def'
b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,
c) STANDARDIZE the pragmas
d) STANDARDIZE the error messages
e) Fix the macro language so it is type safe
f) Fix the fricken grammar so that function prototypes (forward declarations) with the end semi-colon can be just be copied / pasted as function definitions.
g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language
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
k) Add a proper exponent operator
l) Add a proper wedge operator, along with inner and outer product operators
m) Add proper multiple return types
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.
o) Stop doing automatic up-casts. Give me a _standardized_ way to i) allow-no-warn, ii) allow-with-warnings, iii) dis-allow
p) Stop doing automatic down-casts
q) Add a proper rotate-left and rotate-right bit shifts

I could go but this is enough "rants" for now.

And before someone says "D" is the solution to the clusterfuck of "C++" I'll say "Yeah, WHEN the compiler is properly open sourced" AND fixes all the broken crap in C++ THEN it might have a chance of succeeding.

How long did it take C++ to get standardized threading support? Meanwhile the rest of the world need a _solution_ 10 years ago and used pthreads.

When is C++ going to add reflection support?

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.)

The problem with that C++ is not that you can't write simple code, but is that the languages makes it easy to write verbose bloated code.

For contrast 'Eigen' is a beautiful high performance vector and matrix C++ library -- just include one header and you are good to go!

I highly doubt C++ will ever get rid of its bloated "designed by committee" because that would require honesty and authenticity to acknowledge ALL of its faults by its designers.

--
"Inside every programming language is a smaller one struggling to get out."

Re:I don't like boost (2)

Pino Grigio (2232472) | about a year and a half ago | (#43183639)

Well I know you don't want this to be a code review, but being "simple", "easy to read" and writing things like unsigned int crc = -1; really don't look much better to me. Then of course you had to write it, rather than just including boost and writing something like:

boost::crc_basic crc_ccitt1( 0x1021, 0xFFFF, 0, false, false );
crc_ccitt1.process_bytes( data, data_len );

, or whatever, which is much shorter, less code for your to screw up and almost certainly bug free from being used/checked by thousands of others.

Re:I don't like boost (5, Insightful)

Pr0xY (526811) | about a year and a half ago | (#43183777)

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:I don't like boost (0, Redundant)

Pino Grigio (2232472) | about a year and a half ago | (#43183859)

Please mod Pr0xY's reply up! Seems the OP doesn't really understand what he's talking about.

Agunk Nevada (-1)

Anonymous Coward | about a year and a half ago | (#43182527)

Nice share, view back my site :)

Boost Sucks (2, Insightful)

Anonymous Coward | about a year and a half ago | (#43182529)

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 (4, Insightful)

AuMatar (183847) | about a year and a half ago | (#43182641)

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 (5, Insightful)

Anonymous Coward | about a year and a half ago | (#43183079)

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 (5, Insightful)

PhrostyMcByte (589271) | about a year and a half ago | (#43183171)

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:Boost Sucks (0)

StripedCow (776465) | about a year and a half ago | (#43183225)

Most of the stuff is still crap, though. Not from a functional point of view, but from the point of view that it is totally unreadable code. And when I say unreadable, I actually mean totally obscure.

Of course, from a user's perspective this should not matter. But the point is, the mess that is lurking behind that well documented API, occasionally pops up its ugly head whenever you make a mistake: error messages are completely incomprehensible!

That, and given the fact that meta programming in C++ (what boost tries to accomplish in many libraries) is a total hack, I think they should have designed a completely new language instead.

Re:Boost Sucks (0)

Pino Grigio (2232472) | about a year and a half ago | (#43183513)

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. 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.

Don't confuse a generally difficult learning curve for writing good C++ code with C++ being a poor language.

Re:Boost Sucks (1)

StripedCow (776465) | about a year and a half ago | (#43183661)

You didn't read the whole comment now, did you? :)

Re:Boost Sucks (1)

luis_a_espinal (1810296) | about a year and a half ago | (#43183867)

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 pick as examples of over-complication. Thus, it is not accurate to say "look, this library has no flaws" by picking up one of its most perfect artifacts.

Don't confuse a generally difficult learning curve for writing good C++ code with C++ being a poor language.

For starters, he didn't mention C++ per say, but C++ metaprogramming, which as powerful and useful as it may be, it is a templating hack. A good thing back then (I though it was the greatest enchilada ever), but now a hack compared to what we know now in terms of language design.

Similarly, a learning curve is part of the factors that that define and differentiate a poor language from a good one. Granted that the terms "poor" and "good" are typically used in a subjective fashion (certainly so in slashdot.) But the issue of its quality remains.

It is a powerful language, and, like any language, in good capable hands, it can be used to create wonders. But significant aspects of it, which at one point were thought of as pluses, have turned out to be crap. People should really stop worshipping sacred cows and accept that some things of them are just shitty.

Re:Boost Sucks (0)

Anonymous Coward | about a year and a half ago | (#43183863)

Boost fans really hate it when you point this out. If you want to use something relatively simple and primarily computer science oriented like smart pointers then Boost is great.

If you want something that is relatively complex but still computer science, like regular expressions, Boost is a little buggy and poorly documented but okay.

If you want to use something that is far from computer science, like a linear algebra library, then Boost is a buggy undocumented mess that you should run like hell from.

Re:Boost Sucks (0)

Anonymous Coward | about a year and a half ago | (#43182993)

Agree, a template mess with ass backwards documentation.

And those defending boost, it's called Leda, yes, you have to pay for it, but there's no reason boost couldn't look more like that rather than the god awful mess that it is.

"Oh, but most of the stuff doesn't need to be linked, you just include the header", yeah, I know, still, I'll take linking a million times over than trying to decipher the function signatures in boost.

Re:Boost Sucks (0)

Anonymous Coward | about a year and a half ago | (#43183897)

There are good parts of Boost.

Pretty much all of them went into TR1 or C++11, though, so...

Re:Boost Sucks (2)

ArcadeMan (2766669) | about a year and a half ago | (#43183055)

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:Boost Sucks (0, Insightful)

Anonymous Coward | about a year and a half ago | (#43183127)

Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ;)

Boo fucking hoo. The rest of us in the real world need to get shit done, and libraries like jQuery are essentially imperative for writing modern web applications intended to function across browsers. Additionally, the average jQuery download per page is way less than 80KB as not all plugins are downloaded in any sane webapp.

Re:Boost Sucks (1)

RaceProUK (1137575) | about a year and a half ago | (#43183353)

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:Boost Sucks (0)

Anonymous Coward | about a year and a half ago | (#43183623)

Then bloody man up and learn javascript, instead of copy/pasting how other people use one "one-size-fits-all"-library.

Re:Boost Sucks (1, Flamebait)

RaceProUK (1137575) | about a year and a half ago | (#43183319)

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:Boost Sucks (0)

Anonymous Coward | about a year and a half ago | (#43183393)

Ok, that's just ridiculous. It doesn't take 5 minutes to learn the basics of jQuery. It takes 15. I had to get some chips first.

Re:Boost Sucks (4, Insightful)

Joce640k (829181) | about a year and a half ago | (#43183301)

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.

boost? (1)

mark_lybarger (199098) | about a year and a half ago | (#43182533)

what are the odds.

Where you at dog? (-1)

Anonymous Coward | about a year and a half ago | (#43182581)

Boost mobile has never once helped me code.

if Boost were a corporation... (0)

Anonymous Coward | about a year and a half ago | (#43182591)

It would be taken over and split up. It's a not a "set of libraries", it's a "set of sets of libraries".

Proof? Show me a reasonable tutorial on Boost (enough so that a proficient C++ programmer will be able to get useful work done using a Boost library of his or her choosing) available for a reasonable price.

Re:if Boost were a corporation... (1)

RaceProUK (1137575) | about a year and a half ago | (#43183367)

This should help [lmgtfy.com]

need more meat in that article (4, Informative)

iggymanz (596061) | about a year and a half ago | (#43182607)

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:need more meat in that article (0)

Bill, Shooter of Bul (629286) | about a year and a half ago | (#43182643)

He's a dice empolyee, so yes, obviously. The goal is to make an article as techy sounding as possible, but spend as little time as possible writing it.

Re:need more meat in that article (1)

pittaxx (2003818) | about a year and a half ago | (#43182673)

Probably the guy has an arts degree, don't bully him...

Re:need more meat in that article (0)

Anonymous Coward | about a year and a half ago | (#43182963)

Actually, the author has written a number of technical books, including this one: http://www.amazon.com/All-In-One-Desk-Reference-For-Dummies/dp/0470317353/ref=sr_1_2?ie=UTF8&qid=1363362382&sr=8-2&keywords=jeff+cogswell

How many have you written?

Writing commercial grade books is not a plus. (1)

MouseTheLuckyDog (2752443) | about a year and a half ago | (#43183031)

Just ask Phil Greenspun. [greenspun.com]

Re:need more meat in that article (1)

BitZtream (692029) | about a year and a half ago | (#43183245)

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 (5, Insightful)

Anonymous Coward | about a year and a half ago | (#43182639)

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 (5, Insightful)

AuMatar (183847) | about a year and a half ago | (#43182709)

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:C-like C++ is the way to go (1)

Impy the Impiuos Imp (442658) | about a year and a half ago | (#43182739)

Now all C++ needs is the ability to treat its own source code as data, and an eval(source code-as-data) function, and it will have caught up to LISP in the 1950s.

Re:C-like C++ is the way to go (2)

deKernel (65640) | about a year and a half ago | (#43183063)

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:C-like C++ is the way to go (1)

gbjbaanb (229885) | about a year and a half ago | (#43183287)

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++ is useless for allowing you to screw up.

STL and Boost allows you to write better, cleaner code though. You don't have to roll your own list class as everyone knows the STL one works well, and they recognise it. That makes code that uses it more maintainable overall.

Re:C-like C++ is the way to go (-1)

Anonymous Coward | about a year and a half ago | (#43182747)

Life is too short NOT to use boost. paired with C++11, you get code that looks like a scripting language.

Re:C-like C++ is the way to go (5, Funny)

Anonymous Coward | about a year and a half ago | (#43182821)

all the readability of Perl with the compilation times and ease-of-debugging of heavily templated C++, woohoo!

Re:C-like C++ is the way to go (1)

scorp1us (235526) | about a year and a half ago | (#43182883)

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 iterators eliminate off-by-1 errors and boundary conditions.

- you can increase code complexity, while assuring yourself that there are no non-standard approaches going on. Things like signals/slots from tool kits help enforce standards for callbacks and such. Including thread safety.

Re:C-like C++ is the way to go (2)

BigMeanBear (102490) | about a year and a half ago | (#43182951)

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:C-like C++ is the way to go (1)

s0lar (217978) | about a year and a half ago | (#43183295)

First of all, why did you even pick up classes? Isn't the compiler's aide to implement inheritance and virtual functions to complex? Is life too short to learn the syntax? Or would you rather roll your own with function pointers?

Now, having let out some steam, any subset of C++ is a reasonable dialect in its own right. Many people who put C++ on their resume just write C-style procedural code and that is ok. Then people reach into OO things like abstract classes. Then there are standard containers. And then people start writing their own code in that style and we are off to the generic programming domain.

All these are fine tools and it is just an engineering discussion to choose the one that is the most appropriate for the task. The education (aka "C++ style") is important here as things that novice users discover or stumble over have underlining reasons, alternatives and counter parts.

Finally, my personal experience with matter is unambiguous - professionally written high level C++ code is easier to maintain, has fewer bugs and is simply less verbose and more to the point then procedural, lower level C-style code. The only gotcha here is education.

C is the way to go (5, Interesting)

fyngyrz (762201) | about a year and a half ago | (#43183763)

Finally, my personal experience with matter is unambiguous - professionally written high level C++ code is easier to maintain, has fewer bugs and is simply less verbose and more to the point then procedural, lower level C-style code.

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:C-like C++ is the way to go (0)

Anonymous Coward | about a year and a half ago | (#43183893)

First of all, why did you even pick up classes? Isn't the compiler's aide to implement inheritance and virtual functions to complex? Is life too short to learn the syntax? Or would you rather roll your own with function pointers?

Now, having let out some steam, any subset of C++ is a reasonable dialect in its own right.

Think about what you said there. Not any subset a programmer might have picked up (on a sane trajectory, leaving more complex and/or damn-this-was-easier-in-lisp bits for later -- as you imply through the rest of your comment), but any subset is a reasonable dialect? (Note: For the sake of my own sanity, I'm not going to even think of a specific counter-example.)

So where's the comparison? (0)

Anonymous Coward | about a year and a half ago | (#43182659)

The article talks a lot about the history of everything, but the "comparison" is a short section at the end that basically says "boost actually exists."

Not as advertised.

What I hate about BOOST (0)

Anonymous Coward | about a year and a half ago | (#43182679)

BOOST is a great suit of tools ..... that somehow managed to become BLOATED and I'm not talking about features.

Although many of the libraries are technically simplification of common tasks, the implementation is always ridiculously bloated. Take for example the conditional variable and mutex classes .... to do something simple, they added hundreds of lines of completely unnecessary code to them. So instead of being lite and fast, like they are supposed to, they are 3 to 4 times slower than what you can write on your own.

The other part, is the heavy reliance on macros. You have macros calling macros that call macros. And they are not bug free at all. I found 1 macro that generated over 98K of "dynamic" code (can't remember the actual name right now). Seriously, 98K+?? And worst, it had a bug .... and no way to figure out where in the 98K of crap it was crashing.

So in the end, because of the lack of performance and the HUGE increase in binary output size, our project decided against using BOOST ... and only use it as a reference.

Bit stale (0)

Anonymous Coward | about a year and a half ago | (#43182683)

Even experienced programmers with no c++ background (for whatever reason) struggle with c++. On one hand, the elegance is quickly recognized. But the other hand curses it's clumsiness when it comes to trivial tasks like string handling, or when 3 out of 5 google queries return 'use boost or this 20-line example', what other languages solve in 1 line.

Personally, i think that is partly the cause why any other language can gain popularity. And while i recognize, and value, the portability aspect, c++ is clearly not the answer to every task. Also, this very portability aspect seems to cut c++ itself in the fingers. If i'm interested in, say, embedded programming, i'd simply expect some standard libraries not to be available. But for 'daily' use on standard pc hardware and major OS'es, i'd like my language to be complete as possible, and not have to include 3 alien libraries for a 20-line program. If iso c++ finally brings that, i'd be delighted, but can't help to wonder why it feels like its 15 years late.

2 cents from a c++ noob and ex-delphi (object pascal) / c# / php programmer

Re:Bit stale (5, Insightful)

ledow (319597) | about a year and a half ago | (#43182813)

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 (0)

Anonymous Coward | about a year and a half ago | (#43183075)

You've recreated object-oriented concepts in C99, he's recreated object-oriented concepts in C99, they've recreated object-oriented concepts in C99. I just love diving into a new batch of C code and seeing which way the author thought they should recreate object-oriented programming in C99.

Say what you will, but having certain things built into the language makes it a whole lot easier. I'm excited to really get into 11 just because I feel like the strong typing can really get out of the way but still give you that warm fuzzy feeling of compiled static correctness.

Where should warm and fuzzy really come from? (3, Insightful)

fyngyrz (762201) | about a year and a half ago | (#43183883)

I'm excited to really get into 11 just because I feel like the strong typing can really get out of the way but still give you that warm fuzzy feeling of compiled static correctness.

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:Bit stale (3, Insightful)

deoxyribonucleose (993319) | about a year and a half ago | (#43183105)

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:Bit stale (2)

smcdow (114828) | about a year and a half ago | (#43183145)

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:Bit stale (1)

BasilBrush (643681) | about a year and a half ago | (#43183215)

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:Bit stale (1)

krlynch (158571) | about a year and a half ago | (#43183237)

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 temerity to blame its impenetrability to me on Lisp being a bad language.

Most of the projects I'm involved in use C++ because it excels at helping us to control the complexity of the massive applications we write and use every day. If we tried to write that code in C, we'd be rending our garments and gnashing our teeth. Use the right tool for the job. C++ isn't the right tool for every job, but neither is C or Python or any other computer language.

Re:Bit stale (1)

TheMathemagician (2515102) | about a year and a half ago | (#43183257)

Unfortunately you simply don't understand C++ and how great it is. Of course you're not alone, most C++ programmers don't understand it either which is why so much bad C++ code is written. Maybe you've just been unlucky and only seen bad code. I have asked people with C++ on their resumes to explain to me what 'virtual' means and the success rate is 50%.

Re:Bit stale (2)

Ghostworks (991012) | about a year and a half ago | (#43183453)

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-oriented version of your design would ultimately involve one uber-object, you shouldn't take an object oriented approach. If you're going to managing a lot of moving pieces in real time, you probably do want an object-oriented approach. If you want to tightly specify behavior at compile time so you know it will behave as expected at runtime, then templates are a good tool for bolting together well-tested parts to get a reliable new part. (When you're working with templated classes and methods, what you're really writing is a specification. You're not doing immediate work, but when work comes up you can put very tight bounds on how it is done. It's a different mindset than many other aspects of coding.)

Complaining about the lack of shiny new features in C/C++ is a lot like complaining that your MCU doesn't support an assembly STRCAT command, or that your Ethernet cable is bad about recognizing lost data and requesting it be re-sent. That's not their job. That's a higher-level problem for higher up in the stack. Trying to force features against type like duck logic only weakens the tool. When it rains don't ask your hammer to be an umbrella, use the hammer to build a house. Yes, that means you will often use non-C/C++ language to roll out an application. It also means that you need appreciate when those non-C/C++ languages create more trouble than going back to a rock-solid bit of C code would. Use the right tool for the job.

Re:Bit stale (1)

StripedCow (776465) | about a year and a half ago | (#43183491)

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:Bit stale (1)

gbjbaanb (229885) | about a year and a half ago | (#43183607)

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 class constructor, and the close into the class destructor... and your program stops being

init();
dowork();
close();

and becomes

MyClass a;
a.dowork();

that's it. init and close stuff are handled automatically, and within scope rules so you no longer need to worry about when to call close, as will happen in more complicated programs. Once you get this concept, the rest will come easily. Its no more difficult than grasping the concept of pointers you had to do in order to grok C.

Re:Bit stale (3, Insightful)

thedonger (1317951) | about a year and a half ago | (#43182903)

Metaphorically speaking, are you concerned about a future where everyone can assemble a house with prefabricated parts, but only the smallest minority know how to fabricate the parts? I fear as more high-level programming language jobs are created as entry level positions people become increasingly reliant on an entire layer of software they don't understand. Does that mean someone should have to know how to write a video driver to write a video game? Well, maybe. I don't know.

Re:Bit stale (1)

Anonymous Coward | about a year and a half ago | (#43183167)

Actually, not re-inventing wheels is a virtue of the better programmer. There's enough dust to bite into apart libraries already written. It's tempting to have all source 'under your own control', it's also highly unproductive and a source of bugs and portability issues.

Re:Bit stale (0)

Anonymous Coward | about a year and a half ago | (#43183221)

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html

Thank god he's the one and only... (0)

Anonymous Coward | about a year and a half ago | (#43182687)

Why are "articles" written by this guy still accepted for slashdot submissions?

Re:Thank god he's the one and only... (0)

BitZtream (692029) | about a year and a half ago | (#43183283)

Because he works there, and has for a while.

Since Taco left and DICE went full force moron on slashdot, its a bunch of self promoting wanking now as far as 'articles' submitted exclusively to slashdot. Its either someone pawning off another bullshit commentary by Timothy or crap like this. Then to top it off, they have another editor approve it for the front page as if it wasn't planned to be there from the start.

Jesus (1)

larry bagina (561269) | about a year and a half ago | (#43182717)

"... unzipped the .hpp files span 9000 files and 90MB."

I never liked the idea of C++0x11 (3, Insightful)

scorp1us (235526) | about a year and a half ago | (#43182733)

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 (0)

Anonymous Coward | about a year and a half ago | (#43182825)

Qt uses a custom build system. It's not practical as a drop in library.

Re:I never liked the idea of C++0x11 (0)

scorp1us (235526) | about a year and a half ago | (#43182899)

They are transitioning to CMake.

Re:I never liked the idea of C++0x11 (2)

MouseTheLuckyDog (2752443) | about a year and a half ago | (#43183309)

CMake is a custom build system, and a really badly documented build system on top of it.

Re:I never liked the idea of C++0x11 (2)

Noughmad (1044096) | about a year and a half ago | (#43183771)

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:I never liked the idea of C++0x11 (4, Interesting)

Anonymous Coward | about a year and a half ago | (#43182837)

> 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:I never liked the idea of C++0x11 (1)

swilde23 (874551) | about a year and a half ago | (#43182851)

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 always need. (even by C++ standards).

Re:I never liked the idea of C++0x11 (0)

Anonymous Coward | about a year and a half ago | (#43183011)

> I love QT, but I can't imagine it becoming part of the C++ standard. ... particularly as it's mostly used as a GUI library; I imagine the "giant mess that used both" that you worked on was using Qt mostly for the GUI. GUIs are out-of-scope as far as the C++ language is concerned, so while Qt has become the de-facto standard for cross-platform development (and is an incomparable improvement on the old standard of MFC), the boost / Qt question is a false dichotomy. All of boost is (potentially) in-scope for future inclusion - and that is its stated purpose. Qt - custom preprocessor and all - doesn't want to be part of C++, but to be a library built on-top of C++.

Re:I never liked the idea of C++0x11 (1)

Anonymous Coward | about a year and a half ago | (#43183437)

Qt isn't just useful for GUI development though. QWidget and its kids are great, but Qt has EXCELLENT classes for non-GUI development.

QString, QList, QThread are great. And the SIGNAL/SLOT mechanism you get with anything that is QObject-derived is tremendously useful. Boost has something similar, signals2, I think.

But you are right: Qt is not a good candidate for becoming part of C++.

Re:I never liked the idea of C++0x11 (0)

Anonymous Coward | about a year and a half ago | (#43182867)

C++17?

C++0x (working name) or C++11 (final name). Pick one.

Re:I never liked the idea of C++0x11 (1)

scorp1us (235526) | about a year and a half ago | (#43182915)

Again, more confusion created by crappy naming scheme.

Re:I never liked the idea of C++0x11 (2)

praetorian20 (1723296) | about a year and a half ago | (#43183293)

Again, more confusion created by crappy naming scheme.

Not really, you're the first person I've come across that's confused by it. But then again, that shouldn't be surprising because it's evident from reading your rant that you're just pretending to know what you're talking about. If there's one thing no one can accuse the C++ standards committee of, it is introducing changes that would break backward compatibility. So whatever new features require compiler updates, you can get your ass it's because a library only solution either wasn't possible or just so damn ugly that it was worth making a language change for it.

C++11 is great, and it really does mean you end up writing a lot less code in many cases because the language now gives you the tools to do things the correct way.

As for Boost and Qt not being compatible ... wtf are you going on about? They're both written in C++, of course they are compatible! If you have actually tried using both, and not had success, it's most likely because you didn't clearly define what parts of your projects were using which library. Qt does like for you to shun everything but its own classes, including the standard library, but it also has interface that lend itself to being used with the standard library and Boost.

Re:I never liked the idea of C++0x11 (1)

Spiridios (2406474) | about a year and a half ago | (#43183107)

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.

waiting, waiting (2)

roman_mir (125474) | about a year and a half ago | (#43182751)

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:waiting, waiting (0)

Anonymous Coward | about a year and a half ago | (#43183109)

The thing is the C++ lang needs to evolve. Some of the stuff from 98 was crazy as is and they took it to 11 with 0x11 (hehe). However things like better thread concurrency built in is something we need yesterday. Currently as is every library/vendor/OS handles it slightly differently. With lots of subtle bugs between them all. Getting it into the lang would at least give us a starting point where the vendors can hash it out.

Also do not confuse the std library and C++ itself. They go hand in hand but are not the same thing. They are libraries. Use the one appropriate for your project. In 10 years that library will probably be gone anyway. They come and go with the flavor of the month... However some of these things should probably be baked closer to the language at this point.

Re:waiting, waiting (1)

iggymanz (596061) | about a year and a half ago | (#43183479)

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?

Boost ad? (-1)

Anonymous Coward | about a year and a half ago | (#43182829)

Oh yeah, this is slashads now...

Slam me all you like (1, Informative)

TheSkepticalOptimist (898384) | about a year and a half ago | (#43182901)

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:Slam me all you like (1)

Kjella (173770) | about a year and a half ago | (#43183013)

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 (0)

Anonymous Coward | about a year and a half ago | (#43183049)

C# is great for Windows desktop GUI development.

MFC was a ridiculous platform developed by a 'B' or 'C' team of engineers at Microsoft during the mid '90s. They stopped updating it about 12 years ago. Nobody should ever use it unless they have a large legacy MFC codebase, and maybe even then it might be worth a rewrite. I don't think people in Redmond would contradict me on that.

Re:Slam me all you like (5, Funny)

Anonymous Coward | about a year and a half ago | (#43183081)

"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 (1)

microbox (704317) | about a year and a half ago | (#43183093)

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:Slam me all you like (1)

PhrostyMcByte (589271) | about a year and a half ago | (#43183249)

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:Slam me all you like (1)

gbjbaanb (229885) | about a year and a half ago | (#43183415)

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++ is that, apart from Boost, all the library support is scattered all over the web. (I kinda with the best libs would be merged into Boost sometimes). So if you use WCF, you could use WWS [microsoft.com] or gSoap [fsu.edu] instead (both of which are considerably faster and less "magic"). If you want websockets, try libwebsockets [libwebsockets.org] etc :)

LINQ is a bad thing anyway - its a classic case of making everything look like a nail, once you have a C#-shaped hammer.

So anyway, sure C# is easier to break into, everything laid out for you in an easy-to-see way. C++ is just more powerful, only you have to do a little searching to find out what is available.

Re:Slam me all you like (1)

thoth (7907) | about a year and a half ago | (#43183889)

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++.

Academic (1)

pentadecagon (1926186) | about a year and a half ago | (#43183057)

It's obvious that both Boost and C++ come mostly from an academic environment. In a sense it's very general, but this makes it sometimes hard to apply to practical problems. For example, try to create a random number from 0 to 1. Any other language has a function for that. Not so C++, here you have to create two objects before you can generate a random number. Which makes it more versatile, but also more cumbersome. Same goes for the reference documentation: mostly incomprehensible because of all the template arguments [cplusplus.com] , and a library is only as useful as it's documentation.

Re:Academic (0)

Anonymous Coward | about a year and a half ago | (#43183195)

Make that random number Gaussian distributed from 0 to Pi.

Re:Academic (0)

Anonymous Coward | about a year and a half ago | (#43183899)

Gaussian distributions don't have absolute endpoints, just a midpoint and stdDev - but anyway. Most languages have a way to do that in the standard library - either directly (Random.gaussian(mean, stddev) in Python) or with some scaling (Java: Random.nextGaussian()*stddev + mean) .

Re:Academic (1)

Anonymous Coward | about a year and a half ago | (#43183553)

You were probably referring to boost::uniform_01 (which yes, would require the base random number generator and the uniform_01 instance as well). Otherwise....

return rand() / (double) RAND_MAX;

C++ is a disaster (0, Interesting)

Anonymous Coward | about a year and a half ago | (#43183207)

Has anyone here tried reading the standard? It's unintelligible.

Has anyone here tried reading C++ code? Like the standard, a lot of it is unintelligible. To C++'s credit, this isn't a problem with the language itself, per se. It's a problem with substandard software engineers.

I write C++ professionally. I like C++ because I am adept at expressing myself in it. I can build useful things with it quicker than I could with C. But every once in a while, I'll get reminded that I don't know C++ as well as I thought I did. C++ has a myriad of pitfalls that are difficult to understand until you get first-hand experience being bitten in the ass by them. And often times, when it happens to me, I think to myself, "this is so incredibly fucking stupid."

c# is (c++)++ (0)

Anonymous Coward | about a year and a half ago | (#43183383)

- I was working with c++ for 15 years
- I breathed it for day and night
- I did it for my living
- I protected it on every forums, LOLing Java and other guys
- happily used STL, because it is rellay great

Then I had to learn and use c# every day, and I realized that c++ is
- unlearnably and unnecessarily complex, requiring expensive experts
- still, painfully error-prone
- missing a standardized toolset for everyday tasks
- except for extremely CPU-bound tasks, utterly uneffective to develop with it

So, according to the "right tool for the right job" principle, if c# would be as free as c++, and the decision between the two would be based on purely on their effectiveness:
- c++ would be pushed back to a very narrow niche, and very few expert would really require it

Sad, but c++ is a dying dinosaur.
Microsoft would be able to kill it within one day, by just letting c# freely available on every platform.

Re:c# is (c++)++ (1)

WilyCoder (736280) | about a year and a half ago | (#43183565)

Nice try, Steve Ballmer.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?