Comparing the C++ Standard and Boost

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

Comments

I don't like boost

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:I don't like boost

[Anonymous Coward]

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

[UnknownSoldier]

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 _standardize

Re:I don't like boost

[Pino Grigio]

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

[Pr0xY]

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

[Pino Grigio]

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

Re:I don't like boost

[Anonymous Coward]

a) Add a PROPER 'alias' and a PROPER 'type-def'

Define "PROPER"

b) a darn STANDARD _Binary_ API so I don't have to worry about which _compiler_ AND _platform_ was used,

Isn't possible.

c) STANDARDIZE the pragmas

You've missed the point of pragmas.

d) STANDARDIZE the error messages

Compilers differ. This might not be possible.

e) Fix the macro language so it is type safe

If you're looking for type-safety at the pre-processor stage, you're doing it wrong.

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.

Somebody think of the copy and paste coders!

g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language

The only thing that does is break code. If you don't like them, use a typedef.

h) Provide PROPER 16-bit, 24-bit, and 32-bit characters

Don't use primatives types then. Square peg, round hole.

i) Fix the darn grammar so that compilers accept UNICODE source

The language doesn't require unicode characters. HTF would changing the grammar help?

j) Fix the darn grammar so that compilers RECOGNIZE identifiers WITH Unicode characters

That's a disaster waiting to happen. It's bad enough that an I looks like an l.

k) Add a proper exponent operator

Presumably with the unicode. I don't see any significant advantage to this over exp()

l) Add a proper wedge operator, along with inner and outer product operators

Is it really worth adding new operators? Use a function.

m) Add proper multiple return types

Proper? Either you're using the wrong language, or you're doing it wrong.

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.

You're using the wrong language. char is an efficient data type, that doesn't mean ANSI. Also, what idiot wants unicode, but thinks a 16-bit char is idiotic?

p) Stop doing automatic down-casts

Does C++ even do this?

q) Add a proper rotate-left and rotate-right bit shifts

Proper, in what way?

Re:I don't like boost

[Hatta]

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:I don't like boost

[edwdig]

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 keep things simple in the early days of C. Now the standard committee seems very hesitant to make changes to the syntax of language, so they probably just look at these things as nice to have but not worth changing syntax over.

Re:I don't like boost

[Kjella]

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:I don't like boost

[dottrap]

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:I don't like boost

[flargleblarg]

bool CRC32_Init()
unsigned int crc32_buffer( const unsigned char *pData, int nLength )

Why do you use uppercase in the first function name and lowercase in the second function name?

Re:I don't like boost

[radtea]

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

[Immerman]

>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:I don't like boost

[MassacrE]

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 "undefined/implementation dependent" items are features, and compilers take advantage of them to optimize code. It does make some quirky edge cases, but makes a lot of code optimization techniques in use today possible.

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

Do you know a system that does this max time? Because it sounds ridiculously difficult, and would lead to cases where a program would have to fail because it has no memory yet is not allowed to do a full garbage sweep/reclaim.

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.

I actually don't believe this is the problem with C++ - you can write verbose, bloated code in most languages. The problem I see is that C++ was made to be as strict a superset of C as possible, and inherited an audience who want full control of things like object size, and memory allocation/deallocation behavior. Because of this, generialized code requires way more knobs to be tweaked than you expect, and templates have evolved to be a hacked-together functional programming language to determine optimal operation. In order to generate an optimal, generic library you have to make the code itself incredibly difficult to maintain.

Re:I don't like boost

[UnknownSoldier]

>> a) Add a PROPER 'alias' and a PROPER 'type-def'
>Define "PROPER"

First, there are times:
a) When you _need_ strict type safety
b) When you _don't_ need strict type safety

Second, read up on C++ mangling/demangling because if you don't understand that you won't understand my point.
http://en.wikipedia.org/wiki/Name_mangling

Agner is a guru of assembly language and has written a great document; specifically the section "The need for standardization"
http://www.agner.org/optimize/calling_conventions.pdf

Here is the usage case where we want BOTH (a) and (b):

typedef int Foo; // same as "#define Foo int" (an alt. syntax could be: 'alias Foo = int')
newtype int Bar; // We want a NEW type, one that is NOT aliases, that differs by NAME only, NOT functionality.
// There is no current way to do this C++ unless you abuse templates.

void AllowFoo( Foo foo ); // c++filt -n _Z8AllowFooi
void AllowFoo( int i ); // Oh look, this semantically equivalent as above; it is redundant/harmless in C++, since there is only 1 mangled function due to aliases not being new types

// We want the compiler to make a SEMANTIC difference between the following two functions -- they should be mangled _differently_:
void ReqBar( int i ) { ... } // We want this overloaded function so we can catch accidental calls to it OR not even provide it at all !!
void ReqBar( Bar bar ) { ... } // ILLEGAL in C++ due to lack of proper non-alias support -- it is mangled the same as: void ReqBar(int)

int i = 1;
Foo f = 2;
Bar b = Bar(3);

AllowFoo( i ); // OK typeof( i ) = typeof( int ) == int
AllowFoo( f ); // OK typeof( f ) = typeof( Foo ) == int
AllowFoo( b ); // Should be an error, but can't tell C++ this is a different type, the C/C++ typedef gives us "nothing"

ReqBar( i ); // C++ can't block this func at compile-time
ReqBar( f ); // C++ can't block this func at compile-time: typeof( f ) = typeof( Foo ) = int != typeof( Bar ) = Bar
ReqBar( b ); // typeof( b ); // typeof Bar != int

Does this make sense?

At least C++ treats SomeVoidFunc() and SomeVoidFunc(void) as being mangled the same now.

Don't even get me started on how C++ ignores the return type for the mangling! There are times when it would be _extremely_ handy to call a different function based on the return type. Sadly C++ lacks this.

>> c) STANDARDIZE the pragmas
>You've missed the point of pragmas.

And you've missed the pain and agony of having to support multiple compilers because the idiotic compiler writers were too SHORT SIGHTED to understand customers do NOT want proprietary vender lock-in having to support yet-another-compiler.

Do you understand the purpose of having a _common_ way to specify structure alignment and packing??

e.g. How you disable the compiler warning about "unused variables" in Microsoft Visual Studio, GCC/G++, Intel C/C++ Compiler, etc?

We standardized the width of train tracks for a REASON.

We standardized the traffic lights even though everyone drives different vehicles from 2 wheels, 3, wheels, 18+ wheels, etc.

As programmers we are forced to solve the same dam problem over and over in everyone's "pet syntax". When is this insanity going to stop??

>> d) STANDARDIZE the error messages
> Compilers differ. This might not be possible.

I'm not interested in political excuses. I

Re:I don't like boost

[UnknownSoldier]

Yeah, I didn't catch that until I hit submit. :-/

Sorry for the inconsistent func names. :-(

Re:I don't like boost

[UnknownSoldier]

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

This .pdf explains why this important:
http://www.agner.org/optimize/calling_conventions.pdf

Particularly: 3 Data representation

Re:I don't like boost

[tibit]

m) Add proper multiple return types

This would be nothing more than syntactic sugar. Why is using a struct such a big deal?

Because, when a function is not inlined, the ABIs for passing structures around are broken and usually force you to put the structure in memory, and only pass a pointer around. I mean, come on, on a 64 bit architecture you can pass a 64 bit structure right in a register. Most of those architectures have so many registers that passing 128 bits of a struct in two registers isn't out of question either. Yet, instead, all that you pass is a 32 or 64 bit pointer. Many compilers do not ever promote elements of a structure to registers, so even using a struct for automatic variables to make code more readable is a performance no-no. That's why making such performance-changing choices implementation defined and not standardized is a big back-assward stupid move. Yeah, it's "portable C" or "portable C++" but you can get wild performance regressions just because you use innocuous-looking abstractions.

Re:I don't like boost

[tibit]

It doesn't matter if all CPUs have it or not. Lightweight syntax hardly ever results in lightweight machine code, so it's a moot point IMHO.

Re:I don't like boost

[dimeglio]

string fuck = "y" << "o" << "u";

Is more penetrating.

Re:I don't like boost

[Anonymous Coward]

>> p) Stop doing automatic down-casts
> Does C++ even do this?

You _do_ use C++ right?

vector<int> vi;
int a = 123;
if( a ) { ... }
if( vi.size() ) { ... } // if expression evaluates a BOOL not an INT nor size_t

That's not a downcast. A downcast would be from a base class (or a pointer/reference to one) to a class derived from it. C++ does not do this automatically, and rightly so.

What you show is a cast between unrelated types. Yes, it's a particularly bad one. It was introduced for backwards compatibility to C (which didn't even have a boolean type at all back then, but used ints for that purpose).

But it's actually not the worst type of implicit cast. Implicit signed to unsigned casts can be much worse. For example

int i = foo();
if (v.size() > i-1)
  do_something();

Now imagine foo() returns 0. Then do_something() is unconditionally called, right?

Wrong. Instead converting -1 to unsigned gives a huge value, which certainly is larger than v.size() (and no, changing i's type to unsigned won't help either; it only will remove the warning some compilers give for the above code).

Again, this behaviour is inherited from C.

Re:I don't like boost

[serviscope_minor]

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:I don't like boost

[Anonymous Coward]

So, can still be an exponent *operator* so you can define a class that implements it, and for the standard types, it does the usual thing.

I mean, it's not like when M and N are matrices, M+N is trivial either. And M**i for an integer i is even less trivial, but the point of having syntax is to make code readable.

Otherwise we would all be using Lisp. (add M N), (pow M i).

Re:I don't like boost

[serviscope_minor]

Actually, they *are* part of the language:

the standard specifially allows C and C++ to do "weird shit" (ok not eh actual wording) with standard library components if it wishes. That very much includes pow and things like memcpy, etc.

Check the asm to see what's been emitted: gcc has lots of special things for standard library functions.

But yeah, I don't see why an overload for ^ and floats couldn't be included.

Re:I don't like boost

[serviscope_minor]

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.

std::tie, as in:

int a, b;

tie(a,b) = make_pair(1,2);

Works for tuple as well.

Re:I don't like boost

[Anonymous Coward]

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.

I don't believe any architecture has exponentiation as an instruction (even Intel). Multiplication is a building block of exponentiation, but that is where most architectures stop. A 3-letter library function name is easily short enough given how often you need exponentiation. In contrast, there aren't any substitutes for bitwise exclusive or (which is trivial on all architectures).

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.

Rotation is a very common operation. I'm wanting to say it is present on almost every processor architecture ever made, but there may be an exception or two. A more notable omission though is the lack of arithmetic shifts. Still these can be built from logical shifts and they aren't needed nearly as often as logical shifts. I'd place these on my list of things that really should be considered adding.

Re:I don't like boost

[Anonymous Coward]

ii) Have you ever written any blending code??
  x = a*t**4 + b*t**3 + c*t**2 + d*t**1 + e; // Fixed C++

Have you ever written code? Because this syntax becomes unreadable.

return foo**bar;

Am I multiplying foo bar times or am I multiplying foo by a dereferenced bar pointer?

Re:I don't like boost

[Anonymous Coward]

Why? So you can have a function named () instead of pi()? This strikes me as something which would just make it harder to read.

It's worse than that...if you can use Unicode, your pi function can be named '\u202eip' and will look identical. That is, until you call it, when it will look like: ;)(pi

Re:I don't like boost

[Anonymous Coward]

Because C++ is not intended as a mathematical expressions language? Such things belong in a library. Or you could allow any UNICODE operator to be an operator and support infix and postfix method invocations/operator definitions. But then you are moving into different-language country...

Re:I don't like boost

[devent]

This is specifically why it's a library function so it is obvious that it is potentially a non-trivial operation.

Riiight. Every time I mention that as a big disadvantage of op-overloading, I get just ignored or called stupid to not see how great op-overloading is.

Re:I don't like boost

[Pseudonym]

Such things belong in a library.

Of course, there's no contradiction with it both being a built-in operator and being in a library. typeof, anyone? But, of course, then the naysayers would just complain that C++ is even more bloated.

Re:I don't like boost

[martin-boundary]

Because C++ is not intended as a mathematical expressions language? Such things belong in a library.

You're being too vague. Some things mathematical belong in a library, eg the special functions or even exp and log. However, the C++ language explicitly supports the elementary mathematical operations of addition, subtraction, multiplication and division. Exponentiation is clearly a natural and very simple iteration of multiplication and therefore optimizing it falls in the purview of the C++ language. It is no different than eg optimizing a loop

int i = 0; while(i < 10) i++; // same as int i = 10;

Re:I don't like boost

[icebraining]

I don't particular care about C++, but despite NOT being an American - or, for that matter, a native English speaker -, I'm completely opposed to Unicode characters outside of comments and strings.

It's exactly because not everyone uses the same language that we should standardize on a limited subset, and ASCII is the most common and well supported of those, and also part of the de-facto International Language (English), which any decent programmer has to understand, at least minimally.

And by the way, that you can't use $ in your variables has nothing to do with Unicode support, of course.

Re:I don't like boost

[Greyfox]

I actually just had to utilize unsigned shorts the other day. I've got a file with a header every 1024 bytes and I have to modify an unsigned short in that header. The file can be several gigabytes so it kind of makes sense just to skip to the first header, write the short, and then skip forward every 1024 bytes thereafter and set the header until I reach the end of the file. The last guy seemed to think it'd be OK to read the entire goddamn thing in and write it back out again. On slow NFS. With Perl.

Re:I don't like boost

[Anonymous Coward]

c) STANDARDIZE the pragmas

That's sort of the opposite of what pragmas are for. They're for non-standard stuff. Note that C++11 has standardized some formerly-nonstandard things like alignment.

e) Fix the macro language so it is type safe

That's the point of templates.

g) Deprecate and REMOVE that stupid 'short', 'long', 'double' crap from the language

Surely you're aware of stdint? I never write "int" in my code. I always use int32_t etc, or size_t etc if it's supposed to be platform-specific.

h) Provide PROPER 16-bit, 24-bit, and 32-bit characters

16 and 32 are supported now.

k) Add a proper exponent operator

Pow(). Exponent is quite a complex operator--hundreds of cycles--and arguably shouldn't be a built-in operator. Note that it's easy to write a template so you can do things like Pow&lt 3 &gt (x) rather than x*x*x (note that pow(x,3) is far far slower than x*x*x unless the compiler is being really smart).

l) Add a proper wedge operator, along with inner and outer product operators

This request impressed me. Is there a language with such a thing? That's some obscure linear algebra stuff (not obscure if you do a lot of lin alg, but not many programmers would be aware). For common cases like matrix-vector multiplication, I don't see why overloading "*" wouldn't get the job done. For the uncommon case, like outer product, I don't see why you really want to waste a character on this particular operator.

You're probably aware, but C++'s template ability makes it possible to write really fast linear algebra routines that are inlined at compile-time. It's a horrible abuse of the template system, but at least it's possible. The only other language I know that could do this is D, and that is not yet mature.

m) Add proper multiple return types

tuple is there and works fine. Unless you meant a variant, which is in Boost I think. But variants make things really tricky because the caller must check what type is inside -- sometimes this is a good thing if it's used to force checking for errors, but I feel variants should be used very judiciously.

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.

Yeah this is painful. But keep in mind a lot of undefined behavior is there to enable optimizations.

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

Yup, too bad this is inherited from C. At least you can turn it off for your own types.

q) Add a proper rotate-left and rotate-right bit shifts

This would be a function anyway, right? So you can write it yourself. Unless you actually like D-style >>>? Note that modern compilers recognize rotate-equilavent expressions and emit the rotate op, so even though it's clunky to rotate with only shifts, it's still efficient. Also, I feel like bit manipulation is rapidly going the way of the dodo. Memory just isn't that precious any more.

Re:I don't like boost

[Anonymous Coward]

That's why there's stdint, and that's why it's recommended to use it. Use int32_t and the like for types that should be a certain size, use size_t for platform-specific, and arguably it's still ok to use int when you really want the natural integer type for the platform and it's doesn't matter how many bits.

Re:I don't like boost

[UnknownSoldier]

> That's not a downcast.
If you wish to be pedantic, yeah, technically it is an automatic-demotion. C/C++ will also silently do automatic-promotion to doubles. i.e. printf().

> Implicit signed to unsigned casts can be much worse
Agreed.

Is there a better way compilers could catch the mistake you gave? IIRC some languages (usually functional ones) have design-by-contract that (force?) allow the user to specify the valid ranges and do range-checking at compile time.

Most C/C++ compilers will warn about signed/unsigned comparisons these days, usually that is enough to catch the mistakes above.

Re:I don't like boost

[Anonymous Coward]

I know, it's like this guy doesn't understand why high-level languages were created in the first place.

"CPUs don't have it"? Come on, what is this, assembly language? I think not!

Re:I don't like boost

[Anonymous Coward]

Because C++ is not intended as a mathematical expressions language? Such things belong in a library.

I don't get it. Why support mathematical expressions at all then?

Hell, we can dump a lot of cruft just by getting rid of all those tedious order-of-precedence rules.

Re:I don't like boost

[Anonymous Coward]

People who wrote code which smoothly made the transition from 32-bit to 64-bit w/o requiring a rewrite yet was still able to take advantage of increased width don't think it was a waste. Or whose portable code can work on a desktop machine with 8-bit bytes, or on embedded DSPs with 16-bit bytes....

And when computers make the transition to 128-bit, seasoned C programmers will take that in stride, too.

For those times when you really want fixed-width types (which is actually rare), we have the types, which have been around for well over a decade now.

Re:I don't like boost

[Wootery]

People who wrote code which smoothly made the transition from 32-bit to 64-bit w/o requiring a rewrite yet was still able to take advantage of increased width don't think it was a waste. Or whose portable code can work on a desktop machine with 8-bit bytes, or on embedded DSPs with 16-bit bytes....

What exactly do you mean by take advantage?

Do you just mean that, in well-written C, an increase in bus width is only ever a good thing, and at the same time it enables efficient DSP code?

In, say, Java, moving to 64 bit will have no effect on program semantics because of the fixed-sized primitives (i.e. unlike C, it just about guarantees you won't see any new bugs from the transition), but might enable one to take advantage of a larger heap.

There's also the non-trivial matter of

People who wrote code which...

which certainly isn't all C programmers. Reflects C's unusually pro-performance design, I guess. Interestingly it looks like the D programming language has no support for C-style CPU-dependent primitives, only fixed-sized.

Re:I don't like boost

[hermitdev]

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.

This is implementation-defined in C++11, a compiler could in theory support multiple input types, see ISO 14822:2001, S2.1.1 and S2.3.

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.

This is required in C++11, see S2.11, Annex E.1 for allowed codepoint ranges, Annex E.2 for initially disallowed codepoint ranges (this is in addition to the ascii nondigit & digit rules). After the initial translation, pretty much all subsequent internal compiler work is done with UTF32.

Boost Sucks

[Anonymous Coward]

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

[AuMatar]

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

[Anonymous Coward]

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

[ArcadeMan]

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

[Anonymous Coward]

Boost has on the order of 100 libraries , each of which undergoes a peer review
CPAN allows anyone 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

[Anonymous Coward]

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

[PhrostyMcByte]

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

[StripedCow]

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

[Joce640k]

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:Boost Sucks

[RaceProUK]

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

[RaceProUK]

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

[Anonymous Coward]

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

[Pino Grigio]

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

[Anonymous Coward]

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

Re:Boost Sucks

[StripedCow]

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

Re:Boost Sucks

[Anonymous Coward]

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

[luis_a_espinal]

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

[Anonymous Coward]

There are good parts of Boost.

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

Re:Boost Sucks

[Pino Grigio]

That works well and dandy until you get incomprehensible (or hard-to-track) compilation errors

You'll get that whenever you start to do template programming, pretty much. Part of the skill set of being a good C++ developer is being able to interpret compiler output, which has improved over the years, although is still not perfect.

There are other things that we could pick as examples of over-complication.

So, don't use it. It's not compulsory. Use the bits you like. Don't use the bits you don't like.

Re:Boost Sucks

[Anonymous Coward]

R.e. other thing like it:

Sounds like :

- BSD Unix
- The java community process
- Netlib
- any other technically competant, group-consensus-oriented open source project
- etc.

to me

Re:Boost Sucks

[Anonymous Coward]

It's not a question of "learning" javascript. I assure you that most developers who use JQuery in real web applications know javascript. The point of JQuery is to manipulate the DOM and other such objects while handling browser-specific hacks for you, so you don't have to spend time trawling the internet for IE bugs or Webkit bugs or Gecko bugs. That's not "learning" JS, that's a pointless waste of time and JQuery is a much-needed layer between DOM-manipulating JS and the browser.
A real programmer doesn't reinvent the wheel so he can say he "manned" up.

Re:Boost Sucks

[Rockoon]

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 word 'well' that ignores the costs of effort.

Re:Boost Sucks

[bipbop]

But the average jQuery download per page is amortized across many downloads, making the average smaller than the file size. It's very common to link to, for example, http://code.jquery.com/jquery-1.9.1.min.js or http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js, which the client is likely to have cached already.

Re:Boost Sucks

[Grishnakh]

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:Boost Sucks

[Grishnakh]

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:Boost Sucks

[david_thornley]

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 Lisp's DEFMACRO, though.

Re:Boost Sucks

[RaceProUK]

What's stopping you?

Re:Boost Sucks

[Anonymous Coward]

Actually Concepts were meant to solve that problem. Unfortunately they didn't make it into C++11.

Re:Boost Sucks

[Grishnakh]

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

[Immerman]

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:Boost Sucks

[tibit]

For linear algebra and C++, there's nothing but eigen, IMHO. Yes, the error messages are incomprehensible, but at least it's documented, well designed, and works mostly as advertised.

Re:Boost Sucks

[Immerman]

I tend to agree. I think a lot of the problem is a combination of the fact that many Boost libraries are grafting new features onto the language, which often requires some sort of user-exposed kludge to accomplish, with the fact that the documentation is mostly written by skilled programmers intimately familiar with the even worse kludges going on behind the curtain, and who don't necessarily posses any particular skill at technical writing (an extremely challenging skill in it's own right). That's fine for the rough draft, but perhaps we need to somehow recruit more skilled technical writers into the process.

Perhaps the developers could commit to spending time one-on-one hand-holding amateur/hobbyist programmers with good technical writing skills as they learn at least the most common use-cases of the library? They could then write at least the "A gentle introduction to X" version of the documentation which would serve as the starting point for those just learning the library, and possibly also as the seed from which future comprehensive documentation could grow. Just as a merely adequate programmer can handle a lot of relatively sophisticated detail work if they start from a well-written code-base and have a little oversight and a source for good advice to keep them from getting to far off track, so too can a merely adequate writer with a little oversight expand on a well-written document far more easily and clearly than they could on their own.

Re:Boost Sucks

[tibit]

That about sums it up. It was around 15 minutes for me too. I use it so rarely that I usually have to repeat the learning each time I use it :)

Re:Boost Sucks

[serviscope_minor]

That is my main comlaint about Boost.

The documentation is hard to follow, especially getting started. They document the details thoroughly, but there's no page of examples that I could fine easier.

Re:Boost Sucks

[Anonymous Coward]

sure, except I can install 1 cpan module without dragging in every other cpan module.

Re:Boost Sucks

[shutdown -p now]

In terms of API design, Qt is more Java-like than it is idiomatic C++. It is not at all similar to Boost - yes, it does some metaprogramming, but they seem to prefer to use external tools (moc etc) rather than templates for everything beyond trivial generics.

Re:Boost Sucks

[GiganticLyingMouth]

seriously? The getting started guide is really straightforward, and even has examples embedded into it to let you know if you've set everything up correctly. I can understand someone griping about the build process, but that's hardly specific to boost. Your inability to get started with it might reflect more on you than boost....

Re:Boost Sucks

[icebraining]

That's what tools like the Google Closure Compiler do - they analyze the code and remove unused parts. Unfortunately, the code still needs to follow some strict guidelines to be well processed by the compiler, and jQuery doesn't, so the result doesn't work well. There's an open bugÂ, but not much interest in it.

That said, it might not be worth it; 10KB is still bigger than the 0KB you get from using a copy that's probably already in the user's cache, like the one in the Google CDN, so this is almost a moot point.

Re:Boost Sucks

[Greyfox]

I've been using boost regex, boost program options, boost signals2 and boost bind a lot lately and find them very comfortable to work with. I have a friend who swears by boost ASIO, though I was kind of put off by the documentation last time I looked at it. For my needs it's like using a shotgun to kill a fly anyway. Shared pointers and enable_if are now part of the standard or I'd be getting those out of boost too. Took me about a minute to find std::dynamic_pointer_cast, too.

Boost math was not sufficient for my needs, but the Eigen math library was. I was kind of surprised that boost didn't provide md5 checksums until I saw how ridiculously easy it was with openssl. No sense in reinventing that wheel I suppose.

Boost documentation still seems hit or miss, but the modules I use regularly are all very nicely documented. Boost bind is pretty nicely documented, but I'm still convinced it's some sort of sorcery.

Re:Boost Sucks

[elashish14]

I hate to be pedantic, but when someone says 'on the order of,' that generally implies that they're referring to orders of magnitude, which makes it silly to say 120,000, instead of 100,000, or 100.000 for our European friends, as well as others who use the same system.

Also, 'on the order of' makes the ~ in front of 120,000 redundant.

(Yes, I have to live with my brain every day. Someone please save me....)

Re:Boost Sucks

[KZigurs]

how ridiculously easy it was with openssl

That's the first time I've seen 'easy' and 'openssl' in the same sentence...

Re:Boost Sucks

[Greyfox]

For MD5 checksums it is. You call one function to initialize the md5 structure, read your file all at once or in a loop and call another function on the buffer you read and the MD5 structure, and then a function to load the final checksum into an unsigned character array. You output the individual elements of that array as hex digits with a width of 2 and 0 padding to the left. You then need to link your objects into an executable with -lssl and -lcrypto.

Re:Boost Sucks

[Unknown Lamer]

They need to use external tools to build the metaobjects required for their metaobject protocol to work because C++ is insufficiently expressive and does not provide a meaningful way to reconstruct type information at run time in some false quest for efficiency.

I bet they wouldn't be using C++ were they writing Qt from scratch in 2013 and not 1995.

Re:Boost Sucks

[hexagonc]

I hate to be pedantic, but when someone says 'on the order of,' that generally implies that they're referring to orders of magnitude, which makes it silly to say 120,000, instead of 100,000, or 100.000 for our European friends, as well as others who use the same system.

I don't see a problem with saying "on the order of 120,000"; it is the same as "the order of" 100,000.

Re:Boost Sucks

[elashish14]

Well, to me it's somewhat like saying 3.141592 +/- .01. The remaining digits lose significance if they're within the precision of the error bound.

Re:Boost Sucks

[serviscope_minor]

Yep, seriously.

I meant about the individual compenents, not the library as a whole (which I do use). My experiences trying to get into boost.range should not have been as hard as they were.

Re:Boost Sucks

[Anonymous Coward]

>Still small enough for your 'Net connection to barely notice though.
It is still need to be parsed and run. And then they wonder why browsers are slow and memory hungry.

Re:Boost Sucks

[RaceProUK]

>Still small enough for your 'Net connection to barely notice though. It is still need to be parsed and run. And then they wonder why browsers are slow and memory hungry.

You're right, it must be jQuery. After all, those 20MB images have nothing to do with memory usage. And I forgot every web developer is second in talent only to God (or other deity). </sarcasm>

Re:Boost Sucks

[Anonymous Coward]

then you lose the benefit of "everybody's browser already has the whole library cached because every other site uses it" that is fairly fundamental to the jQuery design, and so instead of amortizing a 100KB download over, say, 100 sites, you're instead downloading a different, "minified" 10KB for each of those 100 sites. in one of these situations the user downloads 100KB; in the other, 1000KB.

Re:Boost Sucks

[Grishnakh]

There's a slight problem with this theory, from what I've seen: There isn't a single jQuery out there, instead there's between 5-10 versions of it floating around. Not all sites bother to update to the latest version, probably thinking that since the latest version takes up much more space than earlier versions that it'll put more load on their webserver and use more bandwidth (or, the site author hasn't bothered to keep up with jQuery development and releases since they just spent a little time one day adding it to their site, and then moved on to other work and haven't bothered updating their site in a while and as long as the jQuery-related stuff works fine, they're not going to bother with it any more). So you're not amortizing a 100KB download over 100 sites, you're amortizing at least 5 different downloads of 30-100KB over, say, 100 sites, making it an average of only 20 sites using each version, and less chance of the browser cache having the version you need at the time you need it.

boost?

[mark_lybarger]

what are the odds.

if Boost were a corporation...

[Anonymous Coward]

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

[RaceProUK]

This should help

Re:if Boost were a corporation...

[Anonymous Coward]

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.

Umm, I got everything I needed to learn about Boost for free, and have used at least a dozen of the libraries extensively for getting work done. It wasn't that hard to learn, even from just the documentation most of the time. There is enough discussion and use of it elsewhere that many questions not in the docs take ten seconds to find the answer to. I don't think I even spent a day saying, "I'm going to learn this boost library," as it mostly came down to, "I need a library it does this. Oh, there is a boost library," then skim the docs, and then make a quick test program or just go with it if simple enough. And I don't think I would qualify as something more than just "a proficient c++ programmer."

need more meat in that article

[iggymanz]

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

[Bill, Shooter of Bul]

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

[pittaxx]

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

Re:need more meat in that article

[Anonymous Coward]

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?

Re:need more meat in that article

[BitZtream]

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

[Anonymous Coward]

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

[AuMatar]

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

[Impy the Impiuos Imp]

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

[Anonymous Coward]

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

[scorp1us]

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

[BigMeanBear]

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

[deKernel]

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

[gbjbaanb]

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

[s0lar]

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.

Re:C-like C++ is the way to go

[Anonymous Coward]

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

Re:C-like C++ is the way to go

[timeOday]

- simple stuff like foreach() and other iterators eliminate off-by-1 errors and boundary conditions.

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

[Pino Grigio]

Well you're both a bit out of date. This is my preferred loop iteration now:

for(auto & r : collection)
{
...
}

Re:C-like C++ is the way to go

[Anonymous Coward]

Functors are so 2009. C++0x added lambdas for this in 2010 (and boost had them for 6-7 years prior).

Re:C-like C++ is the way to go

[AuMatar]

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

[hazah]

Unless you concider the bridge they have to Python...

Re:C-like C++ is the way to go

[Zero__Kelvin]

"Then you're not making the most of it, or not doing anything sufficiently complicated to warrant use of such a library."

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

[Joce640k]

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

[blackcoot]

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

[Anonymous Coward]

If you're using malloc() instead of std::vector, std::string, etc. then you're doing it very very wrong.

If you're using std::vector for an array that is a fixed length you're doing it very very wrong.

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

If I have 100 dynamically allocated arrays of fixed length, then new[] delete[] is more memory efficient then both std::vector and std::array.

Re:C-like C++ is the way to go

[heson]

Read Stroustrup, code C++ the right way. (i.e C extended by the possibilities of c++, opposed to schoolbook object oriented language with a tendency to over complicate)

Re:C-like C++ is the way to go

[Anonymous Coward]

I use C++ as "C with data structures" - with enough typedefs, the built-in containers and iterators are much faster than writing yet another data structure in C. So much faster it's worth putting up with C++ to get the benefits.

Re:C-like C++ is the way to go

[Anonymous Coward]

Apparently you either haven't heard of Linux, or are under the delusion that it "isn't sufficiently complicated".

Just because Linus is a delusional anti-C++ fundamentalist doesn't mean Linux wouldn't benefit from using it.

Re:C-like C++ is the way to go

[CadentOrange]

If I have 100 dynamically allocated arrays of fixed length, then new[] delete[] is more memory efficient then both std::vector and std::array.

Why? You can set the size of the vector on initialisation and your vector is guaranteed to be deallocated in the event of an exception. The other benefit of vectors is that the underlying buffer gets freed when the vector goes out of scope. Can you guarantee that the code you're writing will not throw an exception (factor in 3rd party libraries too)? If not, you're going to have to catch the exception, delete your buffer then re-throw the exception. There is no reason *not* to use a vector in C++.

Re:C-like C++ is the way to go

[tyrione]

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.

We in the NeXT world have been using C with Smalltalk like classes for a long time.

Re:C-like C++ is the way to go

[Anonymous Coward]

A std::vector and std::array, need to hold memory for the array data and size of the array. If you have 100 std::vectors, that's 6400 wasted bytes of memory on redundant information.

Re:C-like C++ is the way to go

[tibit]

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

[tibit]

At that point you could drop all of the template metaprogramming mess. If that day came, I'd probably cry like a baby for 8 hours straight. I kid you not.

Re:C-like C++ is the way to go

[tibit]

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 extra memory allocation and the extra indirection. Of course Pascal's separation of declarations from the body of the code is IMHO an ugly historical leftover as well :/

Re:C-like C++ is the way to go

[serviscope_minor]

In fairness though, the Romans buile the colleseum fine using ancient technology.

It would have been much quicker, easier and cheaper with modern tech.

Re:C-like C++ is the way to go

[Immerman]

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 nightmarish iterators in my day - things like taking multiple pages of ugliness to traverse an N-dimensional sparse data structure in a domain-relevant manner without access to the larger context. I'd cringe anytime I had to update that code, and was absolutely anal about keeping those comments up to date. But those updates were exceedingly rare, and meant that other areas of much more volatile code could use a simple for loop to perform the traversal while concentrating on performing their own task in a clear and concise manner.

Re:C-like C++ is the way to go

[cbiltcliffe]

all the readability of Perl

Hey!
Perl is perfectly readable. Understanding it, on the other hand....

Re:C-like C++ is the way to go

[larry bagina]

bleh std::array<type, size>;
is identical to
type bleh[size];
(unless you're using C99 variable-length arrays)
Since size is a template parameter and resolved at compile time, the compiler keeps track of it.

c++11 Smart pointers (unique_ptr, auto_ptr (deprecated), shared_ptr) work with new[] as well.

Re:C-like C++ is the way to go

[Anonymous Coward]

In fairness though, the Romans buile the colleseum fine using ancient technology.

It would have been much quicker, easier and cheaper with modern tech.

And also wouldn't standing anymore.

Re:C-like C++ is the way to go

[shutdown -p now]

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.

The reason for this distaste is that it doesn't actually work for a great many things - pretty much anything that can't be indexed efficiently. Linked lists, for example.

Given that iterating over a container is a far more common operation than indexing it, even for arrays and the likes, it makes sense that it is seen as a distinct and more fundamental operation.

Re:C-like C++ is the way to go

[shutdown -p now]

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.

You mean, like C++11 lambdas, which all mainstream compilers have supported for over 2 years now?

std::for_each(xs.begin(), xs.end(), [&](int x) { ... });

Re:C-like C++ is the way to go

[shutdown -p now]

The tricky (and as yet uncovered) ground is when you need an array that has immutable size, but which is not known at compile-time. The closest you can get to that is unique_ptr<T[]>, but that still requires an explicit new. Hopefully they'll add make_unique to complement make_shared in the next revision.

There was also talk of std::dynarray, which would basically be a fixed-size vector-like class, with semantics deliberately constrained such that compiler could do special handling for it and implement it in the same way as C99 VLAs (i.e. allocating the buffer on the stack). But I don't know whether it is still on the table.

Re:C-like C++ is the way to go

[Anonymous Coward]

Agreed, and std::string wasn't guaranteed to have contiguous storage until C++11.

Re:C-like C++ is the way to go

[martin-boundary]

Prior to std::string, everyone wrote their own proprietary, incompatible, C++ string classes, and if you used third party libs, you'd end up with several such. So the mere fact that std::string exists has reduced bloat and complexity.

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

[AuMatar]

Still ugly as fuck. If its not built in the same style as a for, while, or do loop I'd rather see a for loop.

Re:C-like C++ is the way to go

[shutdown -p now]

If you'd rather see a for-loop, you can do:

for (int x: xs) { ... }

But that's beside the point. If you want something to look like a built-in language feature in a language with irregular syntax like C++, then you need it to actually be a built-in language feature. And there's only so much you can stuff into the language itself before it becomes unwieldy, which is precisely why we have libraries. The nice thing about lambdas is that they provide a uniform syntax for anything that can actually be implemented as a library (and, coincidentally, with lambdas, regular for and while loops could well be library functions) - think std::transform, std::lower_range, std::sort etc.

Re:C-like C++ is the way to go

[AuMatar]

Libraries should provide functions and classes that do things, not try to add new syntax to the language. Using things that way is fragile, hard to understand, and impossible to debug. That's why people don't like using Boost or the STL, and ignore most of it except the containers and smart pointers. Things like boost lambdas are language abuse, not features. People did similar things with the preprocessor in C, and it was considered bad code then. Its bad code now.

Re:C-like C++ is the way to go

[Anonymous Coward]

Libraries help... A lot of that software uses gobject, glib, or Qt, or gtk, etc, which all in a way can replace stl or boost, depending on your needs.

Re:C-like C++ is the way to go

[Anonymous Coward]

Listen to this, I've actually used std::unique_ptr to do just that, with malloc/free (oh yes...) and also with open()/close() pairs etc.

(note: just don't forget that vector.clear() does not free the space occupied by the vector, nor does vector.resize(0))

Re:C-like C++ is the way to go

[Greyfox]

Pff. Really the hardest thing about C++ is understanding whether to use pass by copy, pass by reference or past by pointer. I usually default to calling methods with const references or copy for things Java would consider primitive types, and usually return by copy. You just kind of have to take the optimizer's ability to optimize extraneous copies away on faith. This lets you avoid the memory management issues that make C so dangerous to use and take advantage of objects being destroyed when they go out of scope. Occasionally it still makes sense to use pointers -- I wrote a very small wrapper around expat that does this with a simplified XML document tree, this is a good example of a good place to use pointers. In this case I provide shared pointer typedefs. When the last one goes out of scope, the pointers are freed. No fuss, no muss.

The next level of pass-by-fu is realizing that everything is actually just passed by copy. Pointers are actually just copies of pointers. References are just copies of pointers.

Other than that, it's not the language you're learning as much as it is object oriented design. This includes common design patterns, managing object lifetimes and making sure you don't unnecessarily duplicate code in your program. The data structures and algorithms in the STL are very nice to have -- I think the robust libraries in Java are the main reason that language took off while C++ didn't. You get a lot of free shit with java that C++ in the early days didn't provide. Of course, you get a lot of free shit in the C standard library too, but most programmers don't bother to learn it, either. In two decades of professional software engineering, much of which was C, I've never seen anyone other than me call the C standard library's qsort function. I've also never seen anyone else use unlink. I've replaced a lot of system("rm...") calls over the years.

I like C++ because I have access to the entire C standard library as well as the new C++ things. I mostly try to steer clear of template metaprogramming because that will be impossible for the next guy to understand. Even if the next guy is me, six months from now. So I pull in the useful data structures and algorithms from the STL, a few useful things from boost (Threads, regex, program options, signals and bind, regularly,) break my code up into libraries of useful functionality and glue the libraries together to make working executables with the functionality I need. It seems like a fairly sensible way to program. Most of what I do is batch processing where I can have a very thin command line interface. I suspect if I had to create any more complex of a interface, I'd be a lot less happy with the situation.

Re:C-like C++ is the way to go

[Greyfox]

It's best to stay away from such generalizations. You see a lot of new coders who learn about something and then go out of their way to use that thing everywhere. Singleton is a good example of this. If you're the kind of person who sees template metaprogramming and has to use it in every goddamn piece of code whether it's warranted or not, you're probably also the kind of person who, upon learning singleton, has to make every fucking class he writes a singleton. In which case you're useless! But if it's just one more tool in your tool chest and you know when to use a bit of well-placed template code, well that doesn't make you useless, whether it's convoluted or not.

The tools don't make the craftsman. Knowing how and when to use which tools, that's what makes a craftsman.

Re:C-like C++ is the way to go

[shutdown -p now]

What do you think new syntax in a language does, if not "do things"?

Both language features and libraries are the same in that respect - they "do things"! They are building blocks for you to compose to get what you want. And whether it is language features or libraries, they're always more convenient as building blocks when they're more generic. You don't use a different kind of for-loop to iterate over array forwards or backwards, it's the same one - it's just flexible enough to handle both cases. Similarly, you don't use a different function to sum all elements of a vector or a linked list - it's the same function, and it can handle all kinds of types so long as they have iterator interface. Lambdas (C++11 ones) bring this concept even further, since now you can provide inline code for library functions to execute lazily, or conditionally, or repeatedly etc.

Even so, I will agree that Boost.Lambda is language abuse, which is precisely why C++11 lambdas were so sorely needed. But now that we have them, there's absolutely no excuse not to use STL algorithms or write your own. It's a completely different situation from the C preprocessor, because 1) it's the same language, not a completely different one, 2) it does not pollute namespaces, and 3) it does not have unintentional side effects.

As far as "fragile, hard to understand and impossible to debug" goes... I worked for three years on a project that was written in C++ and heavily used STL, including algorithms. We also wrote our own custom generic algorithms when we could, and used lambdas all over the place. It actually resulted in much shorter and clearer code, and I never had a problem understanding or debugging it. But then the concept of higher-order functions is something that I was familiar with a long time before that.

Re:C-like C++ is the way to go

[tibit]

Yup, but it's even worse: everyone even in a single company would do just that, even in C. Just look at how many kinds of strings are used in winapi. It's a nightmare.

Re:C-like C++ is the way to go

[Zero__Kelvin]

That is correct. Among the many reasons why the Linux kernel would not benefit from using C++, your ridiculous and false assertion does not constitute one of them.

Re:C-like C++ is the way to go

[Zero__Kelvin]

Your statement falsely equates C++ with "advanced technology". C++ is no more "advanced" than C, Python, Smalltalk, or any of the many other different programming languages. If you know how to write code you can implement inheritance, polymorphism, etc in any of those languages. Indeed, the first C++ compiler, AT&Ts C-front, was a C preprocessor which took code written in C++ and generated C code which was passed to the C compiler.

Re:C-like C++ is the way to go

[Zero__Kelvin]

Nobody develops even a simple C program without using libraries. If you do I/O, then you use libraries. It is a given that any C coder is going to use libraries, even if they create them all from the ground up. The point is that claiming that anyone not using c++ with STL and Boost isn't doing anything "sufficiently complicated enough", as the GP did, is just patently absurd.

Re:C-like C++ is the way to go

[Anonymous Coward]

I am waiting for Objective-C to become a language for the PC. Clang already works but it would be nice to have Cocoa for Windows too.

Re:C-like C++ is the way to go

[Anonymous Coward]

Prior to std::string, everyone wrote their own proprietary, incompatible, C++ string classes, and if you used third party libs, you'd end up with several such. So the mere fact that std::string exists has reduced bloat and complexity.

No, it didn't, because people *still* write their own proprietary, incompatible C++ string classes, because std::string simply doesn't do what you need it to nowadays. There's QString and wxString and System::String (.NET) and CString (MFC) and Glib::ustring and probably dozens of others.

Re:C-like C++ is the way to go

[constpointertoconst]

Even in C++98, it is possible to write a local function equivalent like this:

void foo() {
  struct { void operator()() {
    printf("I'm local, yo!");
  }} localFunction;

  localFunction();
}

However, the anonymous struct cannot be used as a template argument, severely limiting the usefulness of this construct.

Re:C-like C++ is the way to go

[martijn hoekstra]

Isn't that what being a programmer is all about?

Re:C-like C++ is the way to go

[tibit]

This std::function func = [](int i) { return i+4; };
looks nothing like int function(int i) { return i+4; }

There was a perfectly good function declaration syntax to reuse. That's all you'd need for local functions Pascal-style. Besides, the whole "over 2 years now blah" argument gets kind of old. There's still plenty of code out there that hasn't been ported over to newer compilers, even if that code is otherwise perfectly valid C++ that just doesn't use certain features. I have a lot of code that uses what you got in Visual Studio 2008, and I simply have no time to deal with requalifying it all under VS 2012.

Re:C-like C++ is the way to go

[tibit]

It's a local functor, not a local function. In C/C++, function definitions have certain syntax. Neither lambdas nor local functors maintain it. I'd like to hear a technical reason why the original syntax couldn't have been reused for local functions in both C and C++.

Re:C-like C++ is the way to go

[Immerman]

No, that's what being a good programmer is all about. Well, partially about - lots of other considerations as well.

Re:C-like C++ is the way to go

[shutdown -p now]

Local functions are much, much more limited in what they can do compared to lambdas. On the other hand, once you have lambdas, there's no good reason to do local functions, since lambdas fully cover that use case.

By the way, the proper way to use it is:

auto func = [](int i) { return i+4; };

(you don't want the overhead of std::function if you can avoid it)

There's still plenty of code out there that hasn't been ported over to newer compilers, even if that code is otherwise perfectly valid C++ that just doesn't use certain features. I have a lot of code that uses what you got in Visual Studio 2008, and I simply have no time to deal with requalifying it all under VS 2012.

First you're complaining that the language doesn't have a certain feature, and then you're complaining that you can't use it because you can't move it to a newer compiler (lambdas were in VS 2010 already, by the way). You can't have your cake and eat it, too. Be consistent.

Re:C-like C++ is the way to go

[hermitdev]

The Boost Lambda library is basically unusable for all but the most trivial of things. The error messages are horrendous and it several bloats your binaries unless you strip symbols, at which point debugging is a nightmare.

That said, it demonstrated the need for first-class support for lambdas in the language, so Boost Lambda did serve a useful purpose.

So where's the comparison?

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[ledow]

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

[thedonger]

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

[Anonymous Coward]

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.

Re:Bit stale

[deoxyribonucleose]

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

[smcdow]

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

[Anonymous Coward]

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

[BasilBrush]

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

[Anonymous Coward]

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

Re:Bit stale

[krlynch]

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

[TheMathemagician]

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

[Ghostworks]

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

[StripedCow]

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

[gbjbaanb]

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

[Anonymous Coward]

How do I create generic arrays? I don't, because I don't use generics when I'm not required to. Aside from contrived examples and Thou Shalt coding standards, I've never actually needed a generic. Hell, the codebase of the project I'm working on now is Enterprise-y Java, with generics everywhere, but you know what? There is never a single place in the codebase where objects have an undetermined type. Everything implements interface upon interface, but every situation that operates on generics is, in practice, only operating on one type. The codebase could be shrunk to about 80% of the current size simply by explicitly unwrapping the generics, which is pretty amazing if you think about it. It would also prevent all the pointless instanceof comparisons we do on both sides of the method call.

Re:Bit stale

[bugs2squash]

map and list etc. are great, but the error messages when you get some detail wrong are something to behold. It's as if someone wanted to make it hard to keep their jobs.

Re:Bit stale

[Anonymous Coward]

Just because you couldn't understand it doesn't mean others can't. This says more about you than the language don't you think?

Do you know multiple languages? I am a professional coder who primarily works in C#/Java and occasionally has a C/C++ or other language project. I really don't have a strong preference for any of them. They all have strengths and weaknesses.

C is brutally slow to code in. Good for embedded work or simple glue code. I could write a large project in pure C but wouldn't want to.
C++ is much faster to code with but still pretty slow. C++11 is a joy to code as the nice parts of boost are built in.
Java is nice but dated compared to C# and the purists run away with themselves far too often.
C# is probably the nicest as a language but the stack sucks.

Re:Bit stale

[Anonymous Coward]

English constructs like "I couldn't care less" (which means exactly the opposite of its literal meaning)

No, it doesn't. See explanation here. The common mangling "I could care less" *does* mean the opposite of its literal meaning, but that's because it's a stupid corruption made by people too lazy to think about what they're actually saying.

Re:Bit stale

[Anonymous Coward]

I have asked people with C++ on their resumes to explain to me what 'virtual' means and the success rate is 50%.

*FX: repeatedly whacks head against desk*

Re:Bit stale

[Anonymous Coward]

Nitpick: "I couldn't care less" means exactly what it says - you care so little that caring less is impossible.
It's when people say "I could care less" that it's utter nonsense ;)

Re:Bit stale

[Anonymous Coward]

I could not care less
It is not possible for me to care less
I do not care about this

I don't get it, means what it means to me, that "I don't care about this".

Re:Bit stale

[mark-t]

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:Bit stale

[Anonymous Coward]

I have asked people with C++ on their resumes to explain to me what 'virtual' means and the success rate is 50%.

The correct answer is: "It depends". A virtual function is something completely different from a virtual base class.

Of course that's just in the tradition of C where "static" at file scope means something different from "static" at function scope.

Re:Bit stale

[david_thornley]

I am a professional programmer, who finds C++ to be very useful in larger projects. I have some idea how these would work in C, and it isn't pretty. C is simply a much less expressive language. It's great when you can afford to pay attention to all the details, and breaks down when they get overwhelming. For example, it's far easier to get memory management right in C++. Similarly, OOP is a very powerful tool when applied properly (and it would appear that you never saw it used well).

C++ is a very good language for competent programmers and medium to large projects. It's not a good language in the hands of the incompetent, as there's very many things that can be easily abused.

You've been looking at badly written C++ if you talk about "checking overloaded operators and class declarations to see what the hell it actually does". If you have to check an overloaded operator to see what it actually does, the C++ programmer has screwed up. Checking class declarations is much like checking C functions - if you can't get a basic understanding of what's going on from the names, the program is not well written.

As far as you're concerned, if you find that some basic C code suits your needs, and you're not a professional programmer, then it probably isn't worth it for you to learn C++. When the complexity piles up, and you no longer know where to write free(), C++ is there for you.

Re:Bit stale

[Anonymous Coward]

No-one has ever used that phrase in that way, except for people trying to justify the use of "could".

Re:Bit stale

[Anonymous Coward]

Hi Linus, you are very modest saying you do not consider yourself a "proffesional" prorammer.

Re:Bit stale

[ConceptJunkie]

"I could care less" is usually used sarcastically, but, as we are seeing here, many people take it literally and then complain about it without thinking what the actual words mean.

cf. "could of" - Try diagramming a sentence with that construction. "of" is a verb?

Using "suppose" instead of "supposed", as in "I'm supposed to understand my language well enough to use it correctly."

Think about what the word means in the context... then you realize "suppose" doesn't make sense.

Re:Bit stale

[Pino Grigio]

I just did a string search in my large C++ project for template, and it's in 3 classes only. One is a generic event handling mechanism (quite powerful), one is a generic vertex template and the third is a cache friendly storage base class. Most people who are experienced C++ programmers don't use templates. They're used by library writers a lot, but talk of their over-use in production software is a bit of a fallacy.

Re:Bit stale

[Pino Grigio]

I agree with this. C# is a joy to code with, especially the system libraries. Part of its niceness, in Visual Studio at least, is the way intellisense actually works. It's very hit and miss with C++ because of the complexities of nested header files and so on.

Re:Bit stale

[Immerman]

Strong typing? In C++? Did they completely overhaul the language when I wasn't looking? C++ is statically typed, and the re-purposed "auto" keyword certainly removes a lot of the annoyances that introduces, especially where templates are concerned - I assume that's what you're referring to. C++ is however still a weakly typed language - defining characteristics of which include implicit type conversions and ad-hoc polymorphism (aka operator overloading/function overloading)

Re:Bit stale

[Grishnakh]

I have asked people with C++ on their resumes to explain to me what 'virtual' means and the success rate is 50%.

That's nothing, and actually it may very well be irrelevant to peoples' expertise with C++. In a prior job years ago, I participated in some phone interviews of contractors; we were looking for people who could do both Perl and C++ programming. I'm no C++ expert (and was even less so at the time, more like a junior programmer), but I made up some ridiculously simple questions, such as: "What is a class? Please describe a class and what it's for." The success rate on that question, for people claiming "C++ expert" on their resumes, was much less than 50%, probably less than 25%.

This doesn't show that C++ programmers don't understand C++ well. This just shows that there's a bunch of liars out there who claim to be experts in things they have zero experience or expertise in, just so they can get a job.

Of course, the last time I wrote this little anecdote on Slashdot, I had a bunch of people telling me that there's lots of perfectly good reasons a C++ expert wouldn't be able to tell me what a "class" is (just like an expert auto mechanic might not be able to tell me what a "piston" or a "steering wheel" is when grilled on it in an interview). Let's see what happens today.

Re:Bit stale

[serviscope_minor]

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.

Back in the day, before C++ was so popular, people were perfectly capable of writing the most awful C code, full of leaks and pointer violations. Truly poor programmers do not let anything so trivial as a language get in the way of creating excrable code.

Also, I really hope said gods simply smite those programmers.

Re:Bit stale

[shutdown -p now]

C++ is however still a weakly typed language - defining characteristics of which include implicit type conversions and ad-hoc polymorphism (aka operator overloading/function overloading)

Ad-hoc polymorphism is not the same thing as operator & function overloading, although the latter two can play a part in it. In any case, ad-hoc polymorphism does not enter into the picture in C++ unless and until you start writing class and function templates. Any non-template C++ code is strongly typed.

Re:Bit stale

[shutdown -p now]

FORALL X, most programmers writing in/using X don't understand X.

(this is true for languages, frameworks, libraries, and practically anything else that can be conceivably used in programming)

Re:Bit stale

[Anonymous Coward]

Damn!

I've been a frequent /. reader for the last 10 years, and this is - by far - the most Informational, spot on, and "laid back"-own thought that I REALLY AGREE WITH so I am... Damn.. Sold!

Please; if you write something more. Anything. Please let me know!

And, yes, I consider myself to be a professional programmer. /charlie@elgholm.se

Re:Bit stale

[Immerman]

Are you sure? Perhaps I need to refresh my language-property vocabulary, it has been a while since it got much use.

Implicit typecasting though most definitely conflicts with strong typing, and is buried deep in the guts of the C++ spec. For virtually all built in non-pointer types

Foo(int x);
void main(){
        bool c;
        Foo(c); // valid = weak typing
        }

And for classes (though it does default to pseudo-strong typing)
class A {}
class B{ public:
        B(const A&); // implicit A->B typecasting
        A operator A(); // implicit B->A typecasting
        };
void Bar(B); ...
A a;
Bar( a );// valid
I might have some syntactic details wrong for the B->A line, been a while since I used it, but the point is it exists. Moreover the A->B implicit typecasting is the default behavior unless you remember to specifically disallow it with "explicit" - can't tell you how many bizarre errors I've traced back to that oversight. Which is exactly the point - strong typing gives you certain guarantees when analyzing code for correctness, and C++ doesn't provide those guarantees.

Re:Bit stale

[shutdown -p now]

Are you sure? Perhaps I need to refresh my language-property vocabulary, it has been a while since it got much use.

Yes. Any sort of type polymorphism is when a given single piece of code can operate on values of different types. "Ad-hoc" specifically refers to the fact that it is not type checked in any way - i.e. the language does not restrict what things you can do with the types, but lets you do anything that sticks, with either compile-time resolution (as in C++ templates) or run-time resolution (as in duck typing as seen in most dynamic PLs). A polymorphic function in, say, ML is not ad-hoc because you can't call random functions on something that's just 'a - it won't type-check.

Implicit typecasting though most definitely conflicts with strong typing, and is buried deep in the guts of the C++ spec. For virtually all built in non-pointer types

I wouldn't call either of your examples weak typing - both are implicit widening, in that they pass a value of a subset (e.g. a subclass) where a superset is expected; remember that C++ bool is defined as just an integral type with 0 and 1 as the only two valid values. So there are no correctness issues here, and LSP is satisified.

Now the fact that it'll implicitly cast double to int, or int to char, is more damning. But that is pretty much only the case for numeric types; all pointer and reference types, as well as all aggregates, are fully sound, and won't implicitly convert unless you make them (by introducing conversion operators). And most C++ compilers will warn about implicit narrowing conversions, and all sane C++ programmers compile with warnings-as-errors.

Re:Bit stale

[Immerman]

>ad hoc
Okay, you got me questioning myself so I looked it up and every source I find disagrees with you. From http://en.wikipedia.org/wiki/Ad_hoc_polymorphism

In programming languages, ad hoc polymorphism[1] is a kind of polymorphism in which polymorphic functions can be applied to arguments of different types, because a polymorphic function can denote a number of distinct and potentially heterogeneous implementations depending on the type of argument(s) to which it is applied. It is also known as function overloading or operator overloading. The term "ad hoc" in this context is not intended to be pejorative; it refers simply to the fact that this type of polymorphism is not a fundamental feature of the type system.

So for example in the following code Foo is polymorphic, naming three unrelated pieces of code where the specific implementation invoked will depend on the invocation context. It's a concept almost completely unrelated to polymorphic class hierarchies, and in the presence of implicit type conversions the two types of polymorphism can interact in some extremely ugly ways if you're not careful.
void Foo(int i) {...}
void Foo(Apple a) {...}
void Foo(SomeBigDataStructure& s) {...}

>implicit widening

Not at all, notice that there was no inheritance in my example. let me try a less generic example to be more clear:

class Bitmap{
        Bitmap(int initial_buffer_size);
        };

void Draw(Bitmap);

elsewhere...
Draw(7); // perfectly valid - 7 will be implicitly typecast to a Bitmap

I hope it's obvious how in a more complicated scenario that could cause some really well-camouflaged bugs of a type not possible in a strongly typed language.

Re:Bit stale

[shutdown -p now]

It's really just a matter of semantic quibbling. Arguably, the identifier "Foo" in your example is polymorphic, in that it's bound to three different functions, and which one to use is chosen depending on the type of argument. But none of those functions themselves are actually polymorphic, because all types are fully defined in the body of each one.

Your example with the class is not an example of weak typing, it's an example of a user-defined implicit conversion being applied. Yes, it is not readily obvious that any single-argument constructor defines such a conversion, but that is a syntactic clarity issue, not a type system issue - if, say, the default would be explicit, and there would be a keyword like "implicit" to specify otherwise, it would be a purely syntactic change with a simple one-to-one transformation, not a semantic one.

Then again, the whole concept of "strongly typed" vs "weakly typed" is really blurry. There are some languages that are obviously one (Haskell) or the other (Rexx, Tcl) - but for most of them, it's hard to tell for sure. Is Java weakly typed because you can add an int to a string? Is SML weakly typed because + is overloaded for ints and floats? Is Python weakly typed because its "print" will accept a value of any type and do something useful with it? I find it to be a classification that's too murky to be actually useful - as opposed to, say, static vs dynamic typing, which can be precisely defined.

Re:Bit stale

[umghhh]

where aer those more experience programmers? I met few of the c++ muppets in my life and only one was not a muppet but an engineer worth being called that. The guy knew the features of the language he used, he knew subject he worked on, he knew how to communicate with mortals and he knew the value of code that is simple - and tried hard to make it as simple as possible but not more so. Now this guy is in pension now. The rest of infallible gurus and hackers pissed me off all day long till I realized that they just provide perfect opportunity for an engineer to laugh. Few of them gurus rise above the rest. Few of these few are capable enough to actually work in a team and produce code that is maintainable. The problem I see with this picture is not that there are so many ignorants but too few gurus of the good kind. They usually get burnt out.

The funny thing is - decision to use particular language or tool which is done at the beginning of a project or new product line is done by the evil gurus i.e. those that do not know how to work in big teams and organize things efficiently. So what you write is correct. C++ will allow you to do things you can do in other languages in very convoluted way only in C++ your average developer cannot or does not want to do it in not convoluted, maintainable way because that would not be glorious and we are into C++ for the glory of it - right? This is the attitude prevalent in C++ community to the point that makes me puke when I have to go to work in the morning. The theoretical gains the language gives are nothing if they are offset by malpractice and incompetence (this being social as well as in engineering and organisation). Why bother then? I think any reasonable project managers (do we still have some) should think twice if s/he has a choice to use glorious tools or tools that his/her team can handle.Theoretical benefits are exactly this i.e. theoretical unless your team can produce code that shows them to exist and that is sadly not the reality in majority of cases.

Thank god he's the one and only...

[Anonymous Coward]

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

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

[BitZtream]

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

[larry bagina]

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

I never liked the idea of C++0x11

[scorp1us]

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

[Anonymous Coward]

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

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

[Anonymous Coward]

> 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

[swilde23]

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

[Anonymous Coward]

C++17?

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

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

[scorp1us]

They are transitioning to CMake.

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

[scorp1us]

Again, more confusion created by crappy naming scheme.

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

[Anonymous Coward]

> 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

[Spiridios]

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

[praetorian20]

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

[MouseTheLuckyDog]

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

[Anonymous Coward]

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

[Noughmad]

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

[scorp1us]

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 won't benefit a significant part of the C++ user base which is already dwindling, thanks to .NET and Java.

The specific thing I was talking about Boost and Qt signals/slots. If you have any hybrid program, you're not going to be able to implement that without some kind of chimera class.

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

[21mhz]

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. You never expose definition-heavy classes as your library ABI.

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

[david_thornley]

C++0B.

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

[Anonymous Coward]

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

He's talking about the licenses, not the code.

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

[david_thornley]

Real people on real projects generally use compilers that are supported, by and large, and (unless they're sticking to some proprietary thing like MFC) stick more or less to the standards. If you've been using Visual C++ or g++, you can almost certainly upgrade to a later version with minimal effort. (The exception was the change to pre-standard C++ to standard C++ I was involved in; that was a lot of work.) If you've been sticking close to the standard, you can upgrade to a different compiler without too much work. (That was one reason for the conversion to standard C++ - any further new systems we wanted to support would be much easier, as opposed to working with the quirks of the pre-standard AIX C++ compiler and the quirks of the pre-standard compiler on our next system.)

That's where the "backwards compatible" thing comes in. If you've been using VS 2005, you can probably use VS 2012, since there's backwards compatibility. The thing about VS2012 is that it will compile a whole lot of other things also, and probably catch errors VS2005 didn't.

It's possible that a project is on a platform that is no longer really supported, and doesn't have a modern C++ compiler (and g++ will work on a large array of systems). It's possible that the project is so badly written that it's impossible to move it off one compiler's quirks. In either case, adopting new libraries is going to be a whole lot more work whether written in C++98, C++11, or whatever. It's possible that it's an embedded project, in which case it has no need for JSON. In the vast majority of cases, if there's a need for newly written libraries, it's possible to use a modern compiler.

This is my experience, after over ten years of heavy C++ experience on highly successful real-life projects (and one that went absolutely nowhere, but that wasn't C++'s fault). And, yes, some of them were over ten years old as I worked on them.

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

[swilde23]

The mess that used both was using QT for EVERYTHING and Boost for EVERYTHING. It was amazing. Have you ever considered using both QT and Boosts signal/slot mechanisms? Did you know that both Boost and QT have shared pointer classes? Have you ever thought about using both? In the same class...

It was pretty good.

But hey, it made the company a LOT of money.

waiting, waiting

[roman_mir]

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

[Anonymous Coward]

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

[iggymanz]

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?

Re:waiting, waiting

[roman_mir]

Nobody rams anything down anybody's throat, you don't have to use unicode if you don't want to and if other encodings are 'extremely popular', then where is the problem? Just use those.

String objects should be able to convert between encodings.

Re:waiting, waiting

[iggymanz]

some of the discussion of string's classes had to do with those issues. in the end not much made of it other than some utf classes

Re:waiting, waiting

[serviscope_minor]

Example: a native string object must exist in a language of 21st century, so must a list, a set and a map.

Why?

The answer is that you're full of it.

Are you aware that C++ scales from an 8 bit Atmel to the worlds largest supercomputers?

How do you propose that a language with map built in is ported to an 8 bit microcontroller where you have no free store from which to allocate and free? A clue: you can't.

And what else should C++ have built in? Linear algebra? but ones tailored for small or large sized? Sparse matrices? what format? How about bignums or rationals? Why not an XML parser? Image support?

C++ provides the tools so that you don't need a builtin map. The resulting map is really really good anyway, but means that the tools also allow one to build a quality linear algebra library that works with good syntax. And a quality image library. And a quality bignum library. The list goes on.

This is why C++ remains popular: it's not tailored to any domain. It's designed so that you can tailor it to your domain.

Re:waiting, waiting

[roman_mir]

Ah yes, telling people that they don't need something rather than giving them what they want is the way to get them to use a product, whatever that product is. Yeah, that's it, that's the way to get more people into it.

Slam me all you like

[TheSkepticalOptimist]

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

[Kjella]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Slam me all you like

[PhrostyMcByte]

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

[gbjbaanb]

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 or gSoap instead (both of which are considerably faster and less "magic"). If you want websockets, try libwebsockets 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

[thoth]

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

[blackcoot]

The day you gave up using the wrong tools for the job on a MS platform was a happy one? What a surprise.

Re:Slam me all you like

[Anonymous Coward]

I did the exact same thing and never turned back. Although for me it started with Java, then into C#. I still jump back to Java when I need to code for a platform other than Windows, but since I don't have a zealotry for *nix, I am perfectly happy to develop on Windows and just have a happy coding experience :)

The pay is great, the stress is less and the language/environment is far more pleasant to use these days.

Re:Slam me all you like

[Anonymous Coward]

(C++ > Java > C#)

Re:Slam me all you like

[PhrostyMcByte]

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 frameworks I've seen in terms of flexibility and ease of use. It is definitely not as performant as I'd like.

I've not used gSoap enough to have a qualified opinion on it, but the handful of times I've done something with it I found it remarkably terrible.

LINQ is about making things easy for the developer. It's not super efficient and shouldn't be used in places where perf matters. Its compositional nature can definitely make code easier to follow, though, and has turned out to be pretty flexible with regards to Rx, EF, and Parallel all being able to expose the exact same interface.

Re:Slam me all you like

[Pino Grigio]

Not sure I agree about LINQ. It's tremendously powerful and extremely easy to get the hang of. In my recent project it made searching, sorting, filtering and hashing of items take me no time at all. I don't much like the SQL-like queries personally so never use them. I do like extension methods however. Coupled with generics and lambdas, LINQ is a great advance for software developers.

Re:Slam me all you like

[shutdown -p now]

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.

You know you don't have to do all this, right? If you want to fetch values directly from controls, you can - TextBox.Text etc is still there.

Even if you do data binding, you don't need "a class with a variable and a get/set property for every control". Quite obviously, a single object can cover several controls, and for simple dialogs, that object can be the dialog itself - just declare the properties on it and bind to them (set DataContext to RelativeSource.Self in XAML, and you're good to go). Furthermore, you don't need a separate backing variable for a property; C# has auto-properties of the form "int Foo { get; set; }" since version 3.0 of the language - that's 5 years ago. You don't need INotifyPropertyChanged, either - you can force-refresh specific controls if you want.

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

LINQ is just syntactic sugar for sequence comprehensions combined with the optional ability to do runtime metaprogramming on it. Fundamentally, there's nothing different there from the classic map/filter/fold. What exactly is bad about it?

Re:Slam me all you like

[gbjbaanb]

it may have been real easy to write the code that did the sorting, filtering and hashing.. but what was the runtime performance like? Its difficult to search through an array in anything other than a sequential search, but LINQ makes it look like its an indexed graph query.

Re:Slam me all you like

[Pino Grigio]

Performance was acceptable for the application I was writing. Indeed it just isn't an issue. But then if you're really going for out-and-out performance, you'd probably write it in C++, not C#.

Re:Slam me all you like

[gbjbaanb]

I know, everyone says performance isn't an issue, so its ok to write it in any language, and when more performance is needed, they'll just get another server or a faster processor or whatever.

And that's why computing is the 2nd biggest contributor to global warming (after air travel). Imagine if everyone decided the efficiency of their programs was important after all.

Re:Slam me all you like

[Pino Grigio]

The biggest contributor to `global warming' is the Sun.

Writing commercial grade books is not a plus.

[MouseTheLuckyDog]

Just ask Phil Greenspun.

Academic

[pentadecagon]

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, and a library is only as useful as it's documentation.

Re:Academic

[Anonymous Coward]

Make that random number Gaussian distributed from 0 to Pi.

Re:Academic

[Anonymous Coward]

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;

Re:Academic

[Anonymous Coward]

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

[Anonymous Coward]

http://en.wikipedia.org/wiki/Truncated_normal_distribution
It's a truncated Gaussian.

Re:Academic

[Rockoon]

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:Academic

[mark-t]

For example, try to create a random number from 0 to 1

#include <random>

class RandomGenerator {
private:
std::random_device rd; // uniformly-distributed integer random number generator
std::mt19937 gen; // mersenne twister rng
std::uniform_real_distribution<double> dis; // uniform distribution on interval [a,b)
public:
RandomGenerator():gen(rd()),dis(0,1)
double getNext() {
return dis(gen);
}
};

Re:Academic

[tibit]

This should be +5 insightful.

Re:Academic

[serviscope_minor]

It's obvious that both Boost and C++ come mostly from an academic environment.

Or an environment where people care about correctness and getting things right.

Do you really want [0,1)? Do you care about the random number generator? If not, then WHY not? There have historically been a lot of very bad RNGs out there.

Take C and just about every other language: the RNG is left up to the implemention! That means that you cannot write portable code which gets a repeatable sequence out of a PRNG without ditching the language one and using your own anyway. Which is wretched for testing.

I've also seen all sorts of hideousness out of system and builtin RNGs. And just read Knuth or Num Rec to see more shameful examples.

The thing is you picked on an area which has historically been terrible, and now C++ really shines.

Re:Academic

[shutdown -p now]

Can you explain why it is wrong? And why RAND_MAX in particular is so important (given that the guy wasn't even talking about the standard C function rand() in his comment)?

On a side note, RAND_MAX+1 can overflow, so I think it should rather be RAND_MAX / ((double)RAND_MAX + 1).

Re:Academic

[Pino Grigio]

It's not wrong, it just won't give you an even distribution of random numbers. It becomes really noticeable when you visualise the random numbers by, for example, plotting them as points on a unit sphere. I think he was explaining how to calculate the bounds, not actual code. This is what I do:

float RandomUniformDeviate(float seed)
{
return seed * (1.f / (static_cast(RAND_MAX) + 1.f));
}

float Rand()
{
float seed = static_cast(rand());

return RandomUniformDeviate(seed);
}

float Rand(float m)
{
return Rand() * m;
}

float Rand(float m, float n)
{
return m + Rand() * (n - m);
}

Re:Academic

[Pino Grigio]

type, should be static_cast of course.

Re:Academic

[shutdown -p now]

It's not wrong, it just won't give you an even distribution of random numbers. It becomes really noticeable when you visualise the random numbers by, for example, plotting them as points on a unit sphere. I think he was explaining how to calculate the bounds, not actual code.

I still do not follow entirely - why wouldn't it give you an even distribution of random numbers? Is it due to representation issues with floating point numbers making the value space more dense in some parts and less in others, or something like that?

Re:Academic

[Anonymous Coward]

I presume he was after a random number in the semi-open range [0,1), as provided in numerous other languages or environments, and perfectly applicable for use in binning or selecting array elements without any bias.

Re:Academic

[Anonymous Coward]

Assuming "random number from 0 to 1" means "random number in [0,1)", which is quite reasonable to assume, I'm not sure what error you are referring to. However, I do know that the sub-expression (RAND_MAX + 1) is bad news. If RAND_MAX is the maximum representable integer for that type, which is likely, then you'll get an overflow.

Use the right tool for the job

[microbox]

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:Use the right tool for the job

[Anonymous Coward]

My first encounter with C++ was after the university - I wrote some tiny tools in it. I enjoyed greatly the then new technology. Then I moved along and did mostly QA and developer jobs for fee decades. I thought I have seen the worst of the software development practice already when I heard about this project I could take part in. All C++ and Java (Java was dropped later on). Great God. The project was big and I was shocked to realize that C++ seems to attract the most aggressive of two first of following kinds developers you may meet on any given project:

1. ignorants without the will and/or mental power to look at consequences of their incompetence but full of pride of their professionalism and full of energy to set this 'professionalism' into motion. They think they hack things and indeed they do in literal sense of the world.
2. the infallible - their skill is great they know most of the obscure techniques perfectly. They do not need QA because their code is perfect. No question - these few of those gurus that I met had really amazing mental power and skills yet they cannot do the job on their own and that is a problem because nobody understands their code or do it only with great effort.
3. the real gurus - I met only few of them. Only one so far was good enough not only to be self confident to tell ignorants in the group that it would take them many times more time to code the stuff than it would take him but also a skill to tell this to people without abusing them and on top of that to produce the code that worked (well most of the time) and was simple enough for us mortals to understand, debug and maintain

Add to this user story points crunchers and you are done. Not sure why that is such a problem in C++? Why does the language attracts all these hackers, pasta lovers and 'gurus' ? Not sure why but the result is that theoretical advantages coming from use of particular tool being a language or library is offset because of incompetent use of these libraries and language mechanisms etc.

C++ is a disaster

[Anonymous Coward]

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

Re:C++ is a disaster

[Anonymous Coward]

Let me guess, you're a Ruby on Rails developer?

Re:C++ is a disaster

[Anonymous Coward]

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

It's a standard. Think of it as a legal text, because in essence it is. For a standard, being unambiguous and exact trumps being intelligible. It is not meant to be a tutorial, nor a manual, it is meant as the ultimate reference to decide what behaviour is correct. And given that constraint, I must say the standard isn't actually doing bad. Especially given the complexity of the C++ programming language itself.

Re:C++ is a disaster

[Anonymous Coward]

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

If you have read the standard and found it unintelligible, then, yes, you should probably refrain from writing C++.

Just so that those of us who have read it and understand it don't have to deal with badly written code.

c# is (c++)++

[Anonymous Coward]

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

[WilyCoder]

Nice try, Steve Ballmer.

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

[Isaac Remuant]

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 Python or Go) will continue on the road to success and major adoption.

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

[SplashMyBandit]

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 fundamentally it is single platform (the Mono project won't/can't implement some important libraries that would make codebases truly cross-platform, as stated by Mono's own project page).

I'm always amazed how many still prorgram in C++. After developing in it for around two decades I am glad to leave it behind except for some specialist embedded work - which is becoming increasingly unnecessary; with 32-bit systems on a chip you can use real Java and Linux to develop more complex [eg. multi-threaded networked] apps in a quarter of the time.

If C++ or C# is your preferred language then that's cool. However, if you want to get complex apps out the door as quickly as you can that utilize of lots of the modern multi-core processing power available then it is very very hard to go past Java or Groovy or any of the cross-platform languages that now run on the JVM (eg. Scala). C++ is going nowhere because it adds unnecessary complexity to solving your problem (except in cases where your available memory is measured in kilobytes; which is very rare these days). Those who still program in C++ may do so to show off their programming credentials - but they are missing the point of good design: get your app out the door as fast as you can (with as few defects as possible, which is easy given the JVM instrumentation and the fantastic JVisualVM). Oh yeah, the combination of smart Sun/Oracle engineers, runtime profiled JIT, and easy use of multi-core means a properly written Java program will outperform most single-threaded C++ programs (multi-threaded programs in C++ are less common than in Java due to the pain of using the third-party C++ resource and thread management).

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

[Zero__Kelvin]

"Microsoft would be able to kill it within one day, by just letting c# freely available on every platform."

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:c# is (c++)++

[SplashMyBandit]

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 tooling (I *love* JVisualVM, that comes with the JDK); with judicious use of libraries (eg. JoGL, Input, JOAL) my simulator is already cross-platform (Mac, Linux, Windows, and soon Android) with little extra effort; the runtime performance is fantastic, I'm never CPU bound because it is easy to be multi-threaded and use all the core available (modern multi-core CPUs are so powerful the GPU is always the bottleneck on my sim no matter the age of the CPU).

But let us pretend you are not doing a high-performance 3D app (where muti-threaded Java+JoGL+OpenGL kicks C++'s ass in development time) and instead want to do plain 2D. Then you can use the Adobe-designed Java2D API built into standard Java. It has very many 'advanced' features (convolutions for filtering/effects; affine transforms; easy gradients; font manipulation; composition operations; image i/o in lots of common formats etc.). Using the usual fantastic abstracted design of Java the implementation of Java2D was swapped from software to hardware in 2008. That means *all* the graphics you do with Java2D are hardware accelerated using DirectX on Windows and OpenGL everywhere else (and you don't have to change any lines of code for your graphics program to work pretty-much-seamlessly between platforms). With Java2D you can also mix with JoGL/OpenGL 3D very easily (I use this to provide 2D transparent overlays for in my 3D simulator; it is very easy to do).

This is why Java developers are astonished people are still using C++ believing it has better speed for things like graphics. If you are doing graphics in software in C++ then not only are you not hardware accelerated like Java2D, you also have more work to do to get/maintain cross-platform, have a hard time being multi-threaded to use all the CPU cores you have, and your development time is much more frustrating (easy to have macro/template issues in C++) and takes much much longer to produce something working, tested and stable. If you are still choosing C++ over Java for graphics performance you are half-a-decade out of date (eg. bad at architectural design and bad at business; since it takes more time to develop with C++, which means the same functionality costs more money).

So if you are doing graphics in C++ believing it is speedy I suggest you take a look at Java2D and JoGL (for 3D). A good Java graphics developer can make very very fast *hardware accelerated* graphical programs in little development time.

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

[Anonymous Coward]

That's why so many commercial 3D engines are implemented in Java, not C++, right?

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

[Anonymous Coward]

No doubt it's quicker to throw something together initially in Java, but "ship it ASAP" is relevant for Small Product v1.0.
Systems are more sensitive to the interfaces between parts, the data flow, and how well components are designed for deployment, extensibility, and replacement, and I can't see what value Java added here.

I've built out application platforms for major organisations on accelerated timescales, using well-crafted platform-independent C, C++, VM and script for service layers, UIs, and other pieces according to where it makes sense and where we have developer capacity. I've also seen comparable Java-only projects which have morphed into expensive and inflexible monsters, which don't scale, and can only run on a single platform/JVM version anyway.

In my view one of the reasons for that is tools which give a false view of how to commoditise development, and what value it really adds. A technology stack like this can be built properly once, and run for a decade or more with minor maintenance. C++ is used here because we need serious low latency, high throughput, efficient IPC and remoting, and we must interface anyway with OS/Vendor APIs that are typically C++/C anyway with the corresponding Java client merely a wrapper on top.

Java that would add unnecessary complexity to a system like that.

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

[Anonymous Coward]

A good Java graphics developer can make very very fast *hardware accelerated* graphical programs in little development time.

That's because C and C++ code is doing all the real work behind the scenes.

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

[Pino Grigio]

Is this a joke? You're making a real-time flight simulator in Java instead of C++ because your actual *rendering* is hardware accelerated and threads are easier in Java? You do realise that the unit of parallism on your graphics card is the *warp* (a bunch of pixels), not the driver, don't you? It doesn't matter how many threads you throw at the problem, the driver will mutex your concurrent calls to hell and it won't be any quicker.

Worse, you have no fine control over cache line efficiency in Java, which you do in C++, so it's probable your multiple threads will give the appearance of maxing your cores, but those cores will actually be sitting waiting on a cache line most of the time. I've seen a "multi-threaded solution" running on 6 cores that was only 1.5 faster than a single core solution because of this. If you want performance, C++ gives you the tools to make your code performant. Java abstracts all of that stuff away so you have no control over it. This is why C++ isn't going to die any time soon. Developers at the bleeding performance edge need it too much.

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

[SplashMyBandit]

Thanks for your comment. I'm afraid I must have been unclear. The multi-threading is for all the non-rendering tasks. On 8-cores none of them get above 20% usage, which means there is very low jitter in the frame rate (which is the critical fact in what users notice). The rendering is all deferred and is not done of the CPU at all (aside from the commands to submit textures etc already in VRAM).

This is why C++ isn't going to die any time soon. Developers at the bleeding performance edge need it too much.

I agree with you. C++ is great for some niches. That niche is smaller and getting smaller. What I was saying is that for an application that is far more intensive than most (a multi-player combat flight simulator with realistic flight modelling etc) the extra development time of C++ is not worth it. For most applications C++ is not worth it. For some it is - but these are fewer than most people realise (especially many C++ proponents whose mental model of Java's speed is at least half a decade out of date). Java should be your first choice for implementation, only if you have niche requirements would C++ be worth it.

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

[Anonymous Coward]

Java can't be your first choice for implementation on the desktop. It is a single-vendor product with an uncertain future. It isn't supplied with the major desktop OSs and many users would pick a native over Java app if given a choice.

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

[SplashMyBandit]

Java can't be your first choice for implementation on the desktop. It is a single-vendor product with an uncertain future.

False. There are numerous implementations of Java: Oracle/Sun; OpenJDK, IBM, GNU GCJ+CLasspath; Apache Harmony (for libs); Kaffe; etc etc. You couldn't be more wrong. It is suprising you posted something that is so obviously false.

It isn't supplied with the major desktop OSs and many users would pick a native over Java app if given a choice.

Mostly false. All of the Java desktop apps I've supplied have been trouble free installs for users that looked better than their native counterparts (especially using things like the Nimbus theme and 'filthy rich client' Java2D hardware accelerated effects for nice aesthetics). My apps also perform very well since multi-threading (particularly resource management and object lifecycle in a multi-threaded environment is much easier in Java than C++) Given the fact that most native apps don't look like each other it is no suprise that users like Nimbus (and now JavaFX) interfaces (consider how different that newer versions of Microsoft Office look from their predecessors, yet users can cope with this). Your argument are a decade and a half out-of-date. It is clear you don't know much about modern Java at all and are just parroting anachronistic falsehoods. Time to see the new reality - after a long time computing is getting more hereterogenous, not less (both in terms of operating system and hardware eg. x64 vs ARM etc). The best technology to use is that designed to be platform neutral and Java is fairly unique in having that as a central design goal (not only for the language, but also for the huge number of standard libraries). Haters are always gonna whinge about Java (especially if they believe the bullshit Microsoft markering pumped out from a decade ago to keep you locked on Windows) - however, the Java devs are quietly getting on with solving problems once for all systems (rather than re-inventing for each target system) and *making money* through wisely choosing long-lived platform-neutral technology.

C is the way to go

[fyngyrz]

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 is the way to go

[Waffle Iron]

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

[Anonymous Coward]

I have a few questions. Can you give me an example of OO code you can write in C that you cannot write in "C++ - the good parts", or rather a limited subset of C++? Why do you want to roll your own OO code when C++ can do it for you? What makes C OO code more maintainable? Do you have experience with C++-style memory management, and what's your opinion of it?
I'm genuinely curious, because I have never heard someone claim that they can implement better OO code in C than in C++, and I'd like to know what I'm missing.

Re:C is the way to go

[21mhz]

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:C is the way to go

[Waffle Iron]

But the OP is talking about using C, not those other nice languages.

At any rate, I'm sure that it would have been much easier to write those bindings if GTK had chosen a more sane API with less "OO envy". The Sqlite API comes to mind as a clean, easy to use example of a C API.

Re:C is the way to go

[tibit]

The best you can do "OO" in C is shown in GObject. Thanks, I'll pass.

Re:C is the way to go

[fyngyrz]

In your dreams, son. :)

Re:C is the way to go

[Grishnakh]

You can implement classes and objects and what's more, you can actually understand how they work when you do.
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.

You can do all this in assembly language too. But it won't be very readable or maintainable, and the source code will be enormous. The whole point of a higher-level language is to make your source code shorter and simpler, so you have to do less work to get the same result (though it may not be as efficient in terms of memory or execution speed, though then again, it may be better depending on how good the compiler is and how good your HLL code is, versus how good your ASM coding is).

Sure, you can do classes and polymorphism in straight C, but it's a PITA and not nearly as simple as in C++, since those things are not built into the language. The Linux kernel is a great example of C code that uses these features, but again, it's not that simple or readable, since you have to make your own function tables and such. It may or may not be more efficient "rolling your own" in C, and in a kernel the readability trade-off is arguably worth it, but most of us aren't writing kernels, we're working on higher-level applications where performance isn't quite so critical, and knowing everything that's going on at the machine level isn't very important the way it is in a kernel or device driver.

Re:C is the way to go

[Anonymous Coward]

the most important things are
* GObject introspection
* Bindings from everything to everything, courtesy of GObject introspection

The only problem with Gnome 3 is the UI designers decided to make an abomination instead of preserving Gnome 2 with the accessibility that Sun paid for, and then designing their abomination.

Re:C is the way to go

[fyngyrz]

Can you give me an example of OO code you can write in C that you cannot write in "C++ - the good parts", or rather a limited subset of C++?

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.

Why do you want to roll your own OO code when C++ can do it for you?

Because then I know what it does and so can both modify it at the most basic level if need be, it's generally (much) lighter weight as it doesn't drag in all manner of other stuff, there's no "mystery code" or sudden jumps of megabytes in size and/or unexplained slowdowns. I write high performance code -- live signal processing, etc. Full control lets me shave here and fatten there, all very much under my direct control.

What makes C OO code more maintainable?

You wrote it. It's right there. When you make an object or a class, there's no "mystery meat." In HLL OO, ask yourself: How did your parameters get parsed or set to their defaults? When? Does it always happen, or does it happen only when it needs to? Can you even tell? What's on the stack? In what order? In what format? How is memory cleanup handled? Do you know? In C, you know. I like knowing, I like being able to change things any way I want (relates to your question) and I also like being able to set things up any way I want.

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? Sure, I've got some experience there, and it's ok at the most basic level, although I would *never* use a garbage collector without a gun to my head. That's a great way to chop random execution holes in what was a smoothly running program. I have my own memory management system that I built over years of creating heavyweight applications -- image and signal processing, paint, ai, some other stuff. There are some techniques in there that make for extremely fast memory allocate/deallocate with zero fragmentation, a development-level leak detection system and over/underrun tripwires, and so far, it's worked really well for me, far better than just random use of malloc and crew.

I have lots of things like that -- really powerful and fast (and tight!) general list management, string management, threading, etc. Been writing C for one heck of a long time. Been bitten by standard libraries, other people's code, compiler bugs, suffered through inline ASM, you name it, I've seen it. If what I saw made itself known to me as a problem, I tried really hard to fix it. The proof is in the pudding, as they say, and I've got (for instance) an Aperture clone that is about a megabyte of core code, creates its own UI dynamically, does quite a bit more than Aperture does, and in a CPU-only system (not counting GPUs, in other words), outperforms Aperture by leaps and bounds, the more cores, the better. My SDR software (actually written on top of C++, but basically not using anything from it except for UI) has more concurrent signal processing operations than anything else I'm aware of that's on the market right now, and it'll run in a fairly minimum system although again, the more cores, the better. These advantages can be attributed to good code, code I understand, and an ultra tight library of good stuff like blistering memory management that supplies a lot of what's needed without compromise.

I'm genuinely curious, because I have never heard someone claim that they can implement better OO code in C than in C++, and I'd like to know what I'm missing.

You know, there are a zillion coders out there, and a zillion coding styles. Speaking as a martial

Re:C is the way to go

[shutdown -p now]

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:C is the way to go

[shutdown -p now]

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.

Re:C is the way to go

[tibit]

Typical "hardcore" C code is written a lot like typical Pascal code, and it reads like this abomination, for example (feel free to ignore the assembly bits, they may improve the readability too much). Sure you can understand it coming from just about any other procedural programming language, but that file could be actually quite readable and with no boilerplate if it the project was done in C++ not Pascal... As part of a research on code transformations I've contemplated writing a tool to machine-port Inkscape to from Gtk+ to Qt. There was so much boilerplate code there that it was just silly. Inkscape is written in "OO" C, using C++ as syntactic sugar, and it shows. The codebase is probably 3x too big, considering what it does. As far as use of language features goes, it's really Object Pascal code written in C++ syntax. Not much to do with modern C++ at all, not even much to do with where C++ was 5-6 years ago.

Re:C is the way to go

[Anonymous Coward]

Can you give me an example of OO code you can write in C that you cannot write in "C++ - the good parts", or rather a limited subset of C++?

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.

Why do you want to roll your own OO code when C++ can do it for you?

Because then I know what it does and so can both modify it at the most basic level if need be, it's generally (much) lighter weight as it doesn't drag in all manner of other stuff, there's no "mystery code" or sudden jumps of megabytes in size and/or unexplained slowdowns. I write high performance code -- live signal processing, etc. Full control lets me shave here and fatten there, all very much under my direct control.

What makes C OO code more maintainable?

You wrote it. It's right there. When you make an object or a class, there's no "mystery meat." In HLL OO, ask yourself: How did your parameters get parsed or set to their defaults? When? Does it always happen, or does it happen only when it needs to? Can you even tell? What's on the stack? In what order? In what format? How is memory cleanup handled? Do you know? In C, you know. I like knowing, I like being able to change things any way I want (relates to your question) and I also like being able to set things up any way I want.

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? Sure, I've got some experience there, and it's ok at the most basic level, although I would *never* use a garbage collector without a gun to my head. That's a great way to chop random execution holes in what was a smoothly running program. I have my own memory management system that I built over years of creating heavyweight applications -- image and signal processing, paint, ai, some other stuff. There are some techniques in there that make for extremely fast memory allocate/deallocate with zero fragmentation, a development-level leak detection system and over/underrun tripwires, and so far, it's worked really well for me, far better than just random use of malloc and crew.

I have lots of things like that -- really powerful and fast (and tight!) general list management, string management, threading, etc. Been writing C for one heck of a long time. Been bitten by standard libraries, other people's code, compiler bugs, suffered through inline ASM, you name it, I've seen it. If what I saw made itself known to me as a problem, I tried really hard to fix it. The proof is in the pudding, as they say, and I've got (for instance) an Aperture clone that is about a megabyte of core code, creates its own UI dynamically, does quite a bit more than Aperture does, and in a CPU-only system (not counting GPUs, in other words), outperforms Aperture by leaps and bounds, the more cores, the better. My SDR software (actually written on top of C++, but basically not using anything from it except for UI) has more concurrent signal processing operations than anything else I'm aware of that's on the market right now, and it'll run in a fairly minimum system although again, the more cores, the better. These advantages can be attributed to good code, code I understand, and an ultra tight library of good stuff like blistering memory management that supplies a lot of what's needed without compromise.

I'm genuinely curious, because I have never heard someone claim that they can implement better OO code in C than in C++, and I'd like to know what I'm missing.

You know, there are a zillion coders out there, and a zillion coding st

Re:C is the way to go

[Greyfox]

I've actually done that in the past. It becomes more difficult to manage than it's worth pretty quickly. Right around the time you start needing to create subclasses. Sure, it seems like you can get away with just replacing a few pointers to functions, but you're doing a lot of book keeping for yourself which the compiler could very easily be doing for you. I actually wrote an iostreams-like implementation in C once. Worked reasonably well, too. It even handled network sockets. But there was a lot of extra crap the C++ compiler would have handled for free. It was a good way to learn to appreciate what C++ has to offer, and getting to know how things work behind the scenes is useful, but it's not a way I'd want to have to code all the time.

Re:C is the way to go

[Anonymous Coward]

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.

Actually, C does not have exceptions at all.

Re:C is the way to go

[redlemming]

Having programming C for many years, I can say that there are certainly some good things going for it, and it can be a fun language to use.

However, in many projects, with somewhat more modern languages (not necessarily just C++: Java and C# are good examples) I find that I get a substantial benefit in programming efficiency from the information hiding mechanisms and compile-time type checking. This is particularly important when working with large numbers of other people, but I find it helpful even when just rolling my own code.

The amount of "stuff" that I have to remember not to do when I'm programming in C (and can do almost anything) gets in the way of the amount of stuff I can simply modify with full confidence that it won't break anything because of the tools provided by the more modern languages (although, as Ada supported this kind of thing also, its probably not right to think of it as a "modern" language feature). This is particularly useful when I have to come back to code after a long time of not looking at it.

Mostly I avoid the more complex language features of C++, because that let's me reduce the amount of stuff other people have to know to be able to read my code. It would be nice to be able to simply turn off a lot of the language features that I don't expect to use, perhaps with some sort of "customizable" compiler.

Re:C is the way to go

[Anonymous Coward]

Ah, the classic iostream reimplementation, or their bigger cousin filters & sinks. Everybody writes their own several times. Then they think they become wise when they decide to just use the available interfaces in C++.

The problem is they shouldn't have been trying to abstract it to begin with. How many people's stream implementations support non-blocking I/O semantics. I don't mean callbacks, which are horrendous. I just mean handling EAGAIN properly, and writing parsers (word, line, etc decoding) which are restartable?

The basic Unix pipe/socket primitive is pretty much the perfect abstraction, in terms of encompassing the most amount of usage scenarios with the least amount of baggage. And it's language agnostic.

The problem w/ C++ is that people get carried away w/ technical abstractions. But technical abstractions are overrated. Mostly you want functional abstractions, which are much higher level, and for which language syntax does very little to help. As long as you black-box the implementation, and make the blackbox as simple to use as possible (few or zero dependencies, semantic focused APIs, etc), then you're golden.

And that's why I prefer C when writing reuseable building blocks. I then use Lua, Perl, etc for the application code, which brings everything together.

Re:C is the way to go

[Anonymous Coward]

>Count me in favor.

You just haven't used it enough.

Re:C is the way to go

[fyngyrz]

Would you say that it is important for most programmers to know what goes on at the bare metal even if they don't have those requirements?

For c programmers, I would. For other languages that aren't by their very nature so close to the metal anyway, not so much. In c, you can leverage that knowledge easily, if you have it, across everything you write. In Python, for instance, you mostly can't unless you're writing Python-to-Other or Other-to-Python code, which most people don't do.

c, in my view, occupies a unique position; it's almost assembly language. It's as close as we've been able to get, anyway, with the possible exception of forth-like languages, and it's uniformly compiled -- sometimes pretty well. ASM itself has these huge portability issues, and C obviates those, for which we are usually grateful. It abstracts only the CPU register and specific instruction set models, while leaving almost everything else up to us. It doesn't go too far, as languages that created interpreted word-code do, spending significant amounts of CPU power figuring out, again, what the program actually wants to do. You get extreme portability there -- not even a recompile -- but you lose too much power. And compiling's just not that big a deal. Or shouldn't be. And when you compile, you end up with actual machine instructions directly doing what you wanted done. In a world of really fast CPUs, this has gone from "I need it" to "holy dog, look at that thing blister!" My SDR work wouldn't even be practical outside of C unless I went right for ASM, and that's just a bad idea, I'm afraid.

From real to-the-metal compiled code, the direct and efficient control of memory is a huge hammer that can be made useful in an almost infinite variety of ways, but you do have to understand exactly what you're doing. You still need to understand about CPUs that don't like certain types of memory boundaries, you need to understand byte/word order issues, you need to understand how stacks are actually being used, what happens when you prod I/O hardware and so forth, caching behavior(s), DMA impacts, and in the bad old days when memory wasn't guaranteed to be flat... ugh. Smegma registers.

So yes, absolutely in the case of C coders... and C++ coders. I've always leaned towards programmers who have deep assembly experience; even more so towards those that have at least moderate digital design skills and deep assembly experience. Combine that with c and you've got something special. Such people tend to be real stars in the long run.

Re:C is the way to go

[fyngyrz]

When I asked about C++-style memory allocation, I really meant more along the lines of RAII

Ah. No, I don't use this type of approach. There's a very straightforward take that is basically (and I mean basically):

if (go-get-memory())

{

try_to_do_thing_that_required_memory();

release-memory();

}

The above approach works in just about any context imaginable as long as you design your code such that it doesn't get broken out of processes along broken paths. Those precautions range from "don't divide by zero" to checking parameters before calling a math library... always good practice anyway. You can't trust users at all, and I tend to assume that hardware will give you any combination of bits in any order, so you'd better make sure you got what you thought you were getting before you attempt to process it. My circle of trust tends to end with the CPU instructions themselves.

My memory stuff can be configured to check and firewall every allocation at defined intervals, or just at termination, etc. During development, I turn it up to 11, as it were, and so can verify there are zero leaks, period. Compiling for release can take out some or all of the checks and gain back some speed. I don't use goto in my code -- ever -- because I've never encountered a situation where if() and subsequent block structure couldn't naturally control the code flow adequately. I also don't intentionally throw exceptions, same reason. If stuff can fail, it is my opinion that I should have been looking for the failure in the first place, and had a plan to deal with it in the second.

Re:C is the way to go

[fyngyrz]

Don't assume that just because something is automated, people who use it are unaware of how it works.

Ok, fair enough. But I can also tell you, quite authoritatively, that you can't assume they are aware of how it works. I've done a great deal of hiring for coding positions, and the number of people who had *any* idea what I was showing them when I dropped a hex listing of binary from *their code* in front them has been nearly zero. Dog help them if it was someone else's code, and dog's own dedicated priest if it was code creating an implied language construct. "Lost" is a word wholly insufficient to the situation, lol.

Re:C is the way to go

[fyngyrz]

necessitating ugly goto-based cleanup path for most nontrivial functions.

Not so. Neither goto or exceptions are required. They're a matter of choice (and IMHO, bad choice.)

Re:C is the way to go

[shutdown -p now]

It's not that hard to filter those people out. In both places that I worked before that did a lot of C++, "explain what a vtable is and how it works" was one of the basic interview questions.

Admittedly, if you showed me a hex dump of the binary compiled from C (and stripped all the headers that hint at it being a binary), I doubt I'd recognize it as such. An assembly listing would be another matter. I did a lot of twiddling of C++ code to get minimal overhead back in the day, which usually involves outputting assembly and watching it closely (on several different compilers). Fun stuff when you can have time allotted for for it. That's when I've also learned to respect the modern C/C++ optimizers.

Re:C is the way to go

[shutdown -p now]

How exactly do you clean up the various resources that you have open on all the error exit paths in your function (i.e. whenever it calls any other function, and that other function returns an error code)? Do you just repeat all the cleanup calls for everything that was opened up until that moment for every such call? That will become very unwieldy very fast.

Exceptions don't enter this picture at all; you don't need the for scope guards to be useful. What I mean is that you should be able to write something like this:

FILE *f1 = fopen(...);
scope_guard { fclose(f1); }
...
if (!do_something()) {
  return ERR_FOO; // cleans up f1
}
...
FILE *f2 = fopen(...);
scope_guard { fclose(f2); }
...
if (!do_something_else()) {
  return ERR_BAR; // cleans up f1 and f2
}

Instead of the more typical:

FILE *f1 = NULL, *f2 = NULL;
f1 = fopen(...);
...
if (!do_something()) {
  result = ERR_FOO;
  goto cleanup;
}
...
f2 = fopen(...);
...
if (!do_something_else()) {
  result = ERR_BAR;
  goto cleanup;
}
...
cleanup:
if (f1) fclose(f1);
if (f2) fclose(f2);
return result;

Re:C is the way to go

[Anonymous Coward]

to avoid goto i use :

FILE *f1 = NULL;
FILE *f2 = NULL;
do
{
        f1 = fopen(...);
        if (!do_something())
                break;

      f2 = fopen(....);
      if (!do_something_else())
              break; ... ...
      fclose(f1);
      fclose(f2);
      return true;
}
if (f1) fclose(f1);
if (f2) fclose(f2);
return false;

Re:C is the way to go

[shutdown -p now]

I assume that you have forgotten while(false) at the end there?

First of all, this is still goto. Just because you used a different keyword and an implicit label for it doesn't change the semantics, and the semantics here is goto plain and simple. That aside, it will not work if you detect an error while inside another loop or a switch, since break would then apply to that loop/switch.

Where should warm and fuzzy really come from?

[fyngyrz]

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:Where should warm and fuzzy really come from?

[Anonymous Coward]

Restrictions? Last time I checked C++ was largely a superset of C.

Re:Where should warm and fuzzy really come from?

[Anonymous Coward]

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.

You just showed that you have not the slightest idea about C++. The language doesn't force you to add a set/get layer anywhere. However if you decide that a set/get layer is the way to go, you can ask the compiler to enforce it for you.

Also, if the compiler is halfway decent and the programmer is not a complete moron, a get/set layer has exactly zero runtime overhead both in space and time (unless those are virtual functions; in which case the same functionality would also have space and time overhead when coded explicitly in C -- of course if the functions are virtual where they don't need to be, it's again the programmer's fault; there's a reason why virtual is not the default in C++).

Re:Where should warm and fuzzy really come from?

[fyngyrz]

Other People's Code. Viola: enforced things for no reason other than someone is anal.

Re:Where should warm and fuzzy really come from?

[shutdown -p now]

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:Where should warm and fuzzy really come from?

[Anonymous Coward]

I don't understand. You can write C code in C++. Many times writing C-style code is the right thing to do in a C++ program. So what's the "C++ restriction"?

C++ can do a lot of stuff that C can't. It can do much stronger type checking: while you can do OO in C, you don't get the type checking (not to mention the loss of type information in C prevents the compiler from making optimizations like de-virtualization when possible). RAII, which is super necessary for large programs--shared_ptr and the like make memory management almost easy even in complex programs. And templates, for doing compile-time operations and inlining stuff that would require impossibly complex C macros, making C++ sometimes much faster than C in CPU-intensive code.

The "get/set" stuff is not necessary in C++ if you don't want to do it. It's a best practice, however, because experience shows that if you make a field a public member (rather than private with getter/setter), some day you'll wish you had a getter/setter to monitor that field instead. Not to mention, usually having a lot of getters/setters is a sign of bad design, namely, low cohesion, and maybe a C-style struct would be a better solution.

Boost is too ideological

[tutufan]

The Boost guys seem to be grinding some sort of axe with respect to the FSF. All over their site are little digs about how awful the GPL is, etc. The benefits of various licenses are open to question, of course, but their little snipes just seem unprofessional.

Also, bjam. If you have to write your own make replacement just to compile your code, you're doing it wrong. Ugh.

Re:Boost is too ideological

[Anonymous Coward]

bjam is jam (written by perforce) with some modifications. It's significantly faster than make and automatically calculates dependencies. They have 9000 header files and who knows how many .cpp files. Try building it sometime -- you'll be surprised how long it takes. With make, it would be 3-4 times slower.

Re:Boost is too ideological

[GiganticLyingMouth]

It's also possible to build boost using cmake

Re:Boost is too ideological

[Anonymous Coward]

I think they're correct.

Because boost is not GPL, it has achieved good penetration in the enterprise, and also serves as an incubator for Standard C++.

If you ever write anything properly cross platform (which means much more than just using different versions of gcc on different versions of Linux) you will typically need to create a bespoke build system and coding conventions, which is what boost have done. However it's also simple enough to compile boost yourself in whatever structure you want to import the code into. Part of the problem there is the horrendous interfaces and mass of backwards compatiblity crap baked into every compiler and toolchain - gcc is quite possibly the worst offender here.

C, **not** C-like C++ is the way to go

[ron_ivi]

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: Qt as "really nice"

[non-e-moose]

Bzzzzt. Use of Qt presumes some sort of GUI. Not all applications need a GUI. Why would a loader need Qt? For the puzzled, a loader is /lib/ld.so* and is the key bit of code which manages where your application sits in Virtual Memory, along with the statically bound dynamic libraries. For general application developers, It is something well beyond your capacity to understand, so stick with your burger-flipping.

The parts cartel

[tepples]

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'm concerned with a future where the parts cartel controls access to parts by adding organizational requirements for use of their parts that discriminate against students, amateurs, home-based businesses, and various forms of lean startup company. In some parts of the software industry, this has already happened *cough*games*cough*.

Re:The parts cartel

[hermitdev]

So, when you go to build a house, you're going to forge your own nails, screws. Grow, harvest and saw your own lumber? Drill for the petroleum needed to make PVC pipes? Mine the copper for the wiring? I don't think so.

Rolling your own, reinventing the wheel, whatever you want to call it is sometimes necessary, but usually a sign of NIH.

Re:The parts cartel

[tepples]

I'm not recommending always making all parts from scratch. What I'm talking about is a situation where the cartel would refuse to sell parts to amateurs at all and refuse to sell parts to startup companies unless most of the new company's employees have already done a multi-year internship with a company that already had a license to buy parts. What would be the best choice in such a situation?

Re: Qt as "really nice"

[scorp1us]

Bzzzt.

None of QtCore, QtSQL, Qt Network, Qt...need I continue? Only QtGUI presumes a GUI. QtCore is just datatypes, of which they have advanced storage classes and signals and slots (and event loops) and threading.

"Two, the junior programmers.....

[alain.bonnefoy]

"Two, the junior programmers (and even the senior ones you know who shouldn’t have been promoted) are less likely to make the same old mistake of writing things like for (i=0; i=length;i++) and then ask you why the code seems to sort of work some of the time, while other times it crashes inside the other function the loop is calling." Well is it really better to write an osbcur function instead of understanding why? Such shortcuts conduced to choose some languages like Java which try to do by itself everything a "junior" programmer don't want to do. And we now have thousands of applications programmed in Java whereas it's absolutely unusefull and which run 1/10th of the expect speed. For example, I want to speak about Androïd where Java is absolutely unusefull because we can't expect any portability from or to other systems and which have been choosed only because of the large number of potential programmers. What a pity! Sorry to have posted a comment a bit out of the subject. Regards, Alain