Bjarne Stroustrup Announces the C++ Core Guidelines

alphabetsoup writes: At CppCon this year, Bjarne Stroustrup announced the C++ Core Guidelines. The guidelines are designed to help programmers write safe-by-default C++ with no run-time overhead. Compilers will statically check the code to ensure no violations. A library is available now, with a static checking tool to follow in October.

Here is the video of the talk, and here are the slides.The guidelines themselves are here.

Comments

Wait what?

[Virtucon]

If you take all the fun out of finding memory leaks and stack overflows what fun is there to C/C++? I mean I just love using AutoPtr everywhere, it's perfect!

Re:Wait what?

[tepples]

If you take the drudgery out of finding stack overflows, then perhaps you'll have more time to d%%% around on //||] stackoverflow.com.

Re:Wait what?

[Anonymous Coward]

We apologize for the newly discovered and intentional faults of std::safe::extrasafe_ptr and it has been sacked and no responsibility has been accepted. Please use std::reallysafe::extrasafewontleak_ptr in the meantime. Including the majestik møøse A Møøse once bit my sister...

Re:Wait what?

[Pseudonymous Powers]

Everything in C++ is now deprecated except the word "safe". So you should really be using safesafe::safe_safe_safe in such situations. And in all other situations. When in doubt, just keep typing "safe" until it's safe.

Re:Wait what?

[Virtucon]

which address the issue of pointer ownership.

I own the pointers, they're all mine!

Re:Wait what?

[Anonymous Coward]

std::auto_ptr is deprecated. You should be using std::unique_ptr, or std::shared_ptr which address the issue of pointer ownership.

You perfectly highlight one of the reasons why programming is not a fun hobby for me anymore.

Re:Wait what?

[david_thornley]

Languages are either dead or they change over time. Even COBOL and Fortran get periodic updates. If you program in Visual Basic 6 or Snobol or something like that, you can ignore this.

If you're programming as a hobby, you can generally ignore the changes and program in the language version you're comfortable with. If you're maintaining a professional codebase, then you should keep up with the language changes. I get paid to help keep a big C++ codebase in good shape, so I keep up with things.

Re:Wait what?

[luis_a_espinal]

std::auto_ptr is deprecated. You should be using std::unique_ptr, or std::shared_ptr which address the issue of pointer ownership.

I think he meant it with a flair of irony. I dunno, just guessing.

Re:Wait what?

[Anonymous Coward]

They are just chicken-shit scared of Swift, Rust and Sappeur. Languages which prove you do not need the insecure crapola from the C age to create secure, efficient and real-time capable software.

C and C++ are enablers of cyber warfare and a mortal enemy of the IT industry.

It was much better during the days of memory-safe Algol, but then came along the "free" stuff from Bell Labs. Free as in "free trojan horse".

Re:Wait what?

[Darinbob]

C++ is great. Where else can you reinvent bad garbage collection techniques every day? Modern languages like Java come with bad garbage collection built in!

Re:Wait what?

[Darinbob]

And reference counting has been known to be a terrible garbage collection technique for four decades. Yes, it's problematic to add good garbage collection to a language compiled to bare machine code, especially with smaller CPUs or less memory, and so it the reference counting technique keeps getting used even in modern times.

It is actually easy to manage the memory yourself (though less efficient than incremental generational scavaging techniques) but there has been a generation of programmers trained to believe that manual memory management is evil. There also seems to be this sort of mystic vision that if only we could solve the memory management problem that programming will finally become pain free and we will no longer need to learn to be disciplined. The whole goal, probably driven by management, is to allow poorly trained engineers to write software.

Re:Wait what?

[Darinbob]

If you're using a professional code base, then you're better off NOT using all the latest features just because they're new! Sure, learn about the new language features, but that doesn't mean you should embrace them. Let other people be the guinea pigs.

Re:Wait what?

[w_dragon]

Most of the stuff in C++11 isn't really new, a lot of it has been in Boost for a very long time. A lot of it is also stuff for safety that doesn't affect the binary - like the override keyword. Avoiding it because it's new is really just saying you're not willing to learn.

Re:Wait what?

[angel'o'sphere]

Reference counting is not a GC technique but a memory management technique.

And it is very valid in cases where you upfront know that it will work fine.

Re:Wait what?

[Pseudonym]

They are just chicken-shit scared of Swift, Rust and Sappeur.

The language that everyone hates is not scared of the languages that nobody uses.

Re:Wait what?

[Pseudonym]

And reference counting has been known to be a terrible garbage collection technique for four decades.

More accurately, it was a terrible garbage collection technique four decades ago, in an era when the disparity between RAM and cache wasn't as large as it is today, when multicore wasn't common, and when compilers weren't as clever as they are now. Today, it's a surprisingly competitive technique.

Modern compilers can go to a lot of trouble to avoid manipulating reference counts when it's not needed, and can use static type information to prove that some data structures are acyclic. Of course, in C++, that last point isn't even an issue, since the programmer gets to control when reference counts get manipulated.

Re:Wait what?

[Darinbob]

True, it's not really a GC technique. But... I have seen garbage collectors in some popular interpreters still doing this. Reference counting is good for things with a low reference count - like number of users of a file or window.

However sometimes reference counting can pass the buck on responsibility. Ie, if I "know up front" that I can alloc memory, call a sequence of functions, then free the memory then this should be adequate. If some in a called function retains a reference to the memory then that's an error that needs to be fixed. But because shared_ptr is so easy to use I have seen people use that technique to mask the error, as if it was better to leak the memory than to locate and fix the bug.

Re:Wait what?

[Darinbob]

Ya, but Boost is a bit strange in my view. It's heavy heavy templated code nearly impossible to debug. It violates the "keep it simple" technique I like to use. Maybe there are parts of Boost that are decent though.

Re:Wait what?

[Darinbob]

Reference counts can lead to loops which then results in memory that is not reclaimed. Its also wasteful of memory compared to just having two or three bits. Then what if you overflow your reference count? A "real" garbage collector can make good use of modern CPUs (like dirty bits on pages, etc) and are faster than reference counting and malloc/free. They actually move stuff around in memory which also improves locality of reference as well.

But they don't fit in well with most languages that have pointers, and especially in C++. Garbage collection is best in languages that don't have allocation or freeing of memory. The best C++ has is a best-effort approach that claims to find "most" garbage and it doesn't attempt to move memory around.

Multicore should make garbage collection easier, because GC is something that runs on the side of the program. No need to interleave GC steps into your program when it can run as a separate task. But language implementers seem have forgotten how to do this stuff, or never learned in the first place. The computing world today is designed around the idea that you can always throw more memory at a problem.

Re:Wait what?

[Tranzistors]

My impression is that the features that are in external libraries are more difficult to debug than those that are in the language itself (or standard libraries). So just because boost is more obscure doesn't mean that the same thing in std is.

Re:Wait what?

[Xtifr]

Huh. It's not the templates that bother me; it's the bazillions of obscure macros you're expected to use to make sure that your code works on dozens of broken compilers I don't care about, and which come with 37 different definitions that all depend on the exact release of compiler you're using and it's almost impossible to figure out which one is actually in use, and half the time, if you're using a decent, up-to-date compiler, you can't even tell if you've got all the macros you need in the right places, because your compiler is too smart to even need those macros, so your code doesn't actually work right with other compilers that are supposedly supported by the libraries you're using.

The template stuff is relatively easy if you have a decent modern compiler.

Re:Wait what?

[Kiaser Zohsay]

which address the issue of pointer ownership.

I own the pointers, they're all mine!

ALL YOUR POINTERS ARE BELONG TO US!

Re:Wait what?

[Darinbob]

Yes all that stuff too. I was the C++ "expert" at one company, meaning the one who translated the obscure gcc error messages, and who kept the runtime working. And Boost was difficult to maintain at times.

Re:Wait what?

[david_thornley]

You are better off using some of the latest features because they're better than what the language had previously. If you don't find them useful, don't use them. The C++ Standards Committee has generally been pretty good about not incorporating features unless people had introduced them as compiler extensions, so by using the latest standard features you're not generally on the bleeding edge.

What's the name of the Library?

[the_skywise]

CPPCoreGhost?

Re:What's the name of the Library?

[Godai]

It's the GSL -- Guideline Support Library. It's header-only, nothing to link against, and it's being kept small to make it easy for it to be cleared for use.

As always with C++, the truth is more nuanced

[beelsebob]

For example, one of the guidelines here is to always prefer make_shared over std::shared_ptr(new ...). That's good advice for a couple of reasons
1) it allocates your memory for the shared_ptr control block and the object contiguously
2) it means you can't separate the allocation from the creation of the shared ptr and end up with an owner who's not looking at the shared ptr in-between.

However, it also means that if you have any weak_ptrs pointing at the end of that shared_ptr, the object itself won't go away until all the weak_ptrs do too (because the control structure won't go away until they do, and they're contiguously allocated).

Re:As always with C++, the truth is more nuanced

[serviscope_minor]

Huh?

Are you complaining that a set of coding guidelines isn't a new language standard?

Re:As always with C++, the truth is more nuanced

[rippeltippel]

However, it also means that if you have any weak_ptrs pointing at the end of that shared_ptr, the object itself won't go away until all the weak_ptrs do too (because the control structure won't go away until they do, and they're contiguously allocated).

Shouldn't you lock the weak_ptr before using it?

Re:As always with C++, the truth is more nuanced

[david_thornley]

It also helps exception safety. A call like Foo(new Bar, new Bar) can allocate one Bar and throw on the next, creating a leak. Putting them into shared pointers in the call doesn't work, since shared_ptr(new Bar) is not a function, and so the compiler is justified in doing both allocates and then putting each pointer into a shared_ptr. make_shared() is a function, and must be executed as a unit, so that enforces the order of allocate, make_shared, allocate, make_shared. No memory leaks there.

Re: As always with C++, the truth is more nuanced

[slack_justyb]

Agreed, however some of us inherit the problems and do our best to convince the uppers to allocate time to clean things up. Let's not forget that there are a whole slew of Lennart Poettering wannabes out there that have everything to prove using some of the most horrible coding styles that could ever exist.

Re:As always with C++, the truth is more nuanced

[D.McG.]

There's a much easier way to accomplish this: use reference counted objects, rather than smart pointer templates around dumb objects.

Define IRefCount to include AddRef (or Retain) and Release methods. Make all interfaces extend IRefCount. Define CRefCount to include a FinalRelease method; which by default calls "delete this", and will be invoked when the reference count reaches zero. This method can be overridden to return objects to pools, be handled by some other deallocator, etc.

This removes the need to create two objects, and ensures all shared objects can be passed around like candy. If you really still want a smart pointer template, it's easy enough to create one that simply calls AddRef and Release on the IRefCount object on your behalf as appropriate. An important difference is that the ref count is part of the object, not the smart pointer.

Re:As always with C++, the truth is more nuanced

[david_thornley]

We're still going to need two objects, one a base object and one a pointer object. If we use raw pointers, the reference count will not be incremented and decremented properly, and we need the reference count to reliably be equal to the number of pointers extant. Therefore, the pointer needs to have its own copy constructor, copy assignment operator, and destructor, which will call the appropriate increment and decrement methods (the decrement method to include the deletion as a special case). If we keep the reference count with the object instead of with the pointer, we can keep the pointer size down without indirection.

We need to document heavily that IRefCount (or something more according to C++ naming) is to be inherited virtually, as otherwise we could have more than one reference count if we add it to multiple levels of a class hierarchy. (C++ multiple inheritance can be tricky to get right.)

So, we've got the pointer object, which will contain the pointer and have some attached functionality, and the reference count mixin. This works as long as we can easily modify the class structure, but it does require a fairly sophistication serialization/deserialization system to keep the modified and unmodified objects in sync. In addition, since it changes the memory layout of a class, it can lead to slow compiles.

With this, we also don't get weak_ptr functionality. A shared_ptr object has a shared pointer count and a weak pointer count. This makes it possible, for example, to have a circular list that can be destructed: have one link be a weak_ptr and everything else a shared_ptr. The object itself is destructed when the shared pointer count goes to zero, and the shared_ptr object when both go to zero. (A weak_ptr does nothing on its own, but can be converted to a shared_ptr if the target object is still there.)

I don't see this as being easier than shared_ptr, although it is superior for some purposes.

Re:As always with C++, the truth is more nuanced

[D.McG.]

I only brought this up as an alternative to yet-another redefinition of shared_ptr. We don't need new libraries to have shared objects.

If you're looking for the lazy approach, then yes, the smart pointer object can be used to call AddRef / Release for you. Or you could just call these methods yourself and call it a day, like we did in Objective-C for years until ARC came around. The smart pointer object in this design is optional.

I think you missed the point with the pointer object. There is no reference count mix-in regarding the pointer object. The ref count is store and managed by the base class (CRefCount) of all derived classes that implement IRefCount. The C++ multiple inheritance here is not that tricky. If one cannot handle the diamond pattern, one should not be coding in C++.

A weak reference to an IRefCount object can also be converted to a strong reference by simply calling AddRef.

Deserialization in other languages like Objective-C was done by calling retain in the same way. If it should be weak, it's not retained when deserialized.

My last project used this C++ design for all classes, and it did not impact compile times (the build of 9 dylibs and the app took 90 seconds total on an I7).

Re:As always with C++, the truth is more nuanced

[spitzak]

We're still going to need two objects, one a base object and one a pointer object. If we use raw pointers, the reference count will not be incremented and decremented properly, and we need the reference count to reliably be equal to the number of pointers extant. Therefore, the pointer needs to have its own copy constructor, copy assignment operator, and destructor, which will call the appropriate increment and decrement methods (the decrement method to include the deletion as a special case). If we keep the reference count with the object instead of with the pointer, we can keep the pointer size down without indirection.

This is no more complicated than what has to be done with shared_ptr. And you are confused, you can use raw pointers all you want, as long as you know there is a shared_ptr pointing at the object. This happens in many cases.

We need to document heavily that IRefCount (or something more according to C++ naming) is to be inherited virtually, as otherwise we could have more than one reference count if we add it to multiple levels of a class hierarchy. (C++ multiple inheritance can be tricky to get right.)

So, we've got the pointer object, which will contain the pointer and have some attached functionality, and the reference count mixin. This works as long as we can easily modify the class structure, but it does require a fairly sophistication serialization/deserialization system to keep the modified and unmodified objects in sync. In addition, since it changes the memory layout of a class, it can lead to slow compiles.

It's not a "mixin". It is a base class. This avoids your supposed problems.

With this, we also don't get weak_ptr functionality. A shared_ptr object has a shared pointer count and a weak pointer count. This makes it possible, for example, to have a circular list that can be destructed: have one link be a weak_ptr and everything else a shared_ptr. The object itself is destructed when the shared pointer count goes to zero, and the shared_ptr object when both go to zero. (A weak_ptr does nothing on its own, but can be converted to a shared_ptr if the target object is still there.)

You can implement weak_ptr in EXACTLY the same way make_shared does it. The object is destroyed but the memory is not freed until the weak_ptr count goes to zero. In fact it is fairly easy to have "an object that supports weak_ptr" be a different base class than the plain refcounted object, thus you don't pay for the weak_ptr overhead on every pointer (though you can't make a weak_ptr unless the object is derived from the correct base class).

I don't see this as being easier than shared_ptr, although it is superior for some purposes.

It is enormously easier when you have to do the equivalent of make_shared_from_this (or whatever they called it), and to avoid constructor shenanigans so that the user has to call make_shared and not construct raw objects. The implementation is about the same as shared_ptr.

Boost called this an "intrusive pointer" but they did not support weak pointers. That could be done with a few extra calls. It was a bit ugly as they tried to not define the base class (instead it called functions that the class defined to inc/dec the ref count), I think insisting that everything be based on a refcounted base class would work just fine.

Re: As always with C++, the truth is more nuanced

[Darinbob]

And I wrote my own OS in C while you were busy doing that.

Re:As always with C++, the truth is more nuanced

[david_thornley]

One difficulty with raw pointers in this case is that you have to know what's an owning raw pointer and what's a non-owning raw pointer. As far as not using an object and maintaining the reference count by hand, you're going to screw up sometime, and that's going to be a difficult error to find. In C++, I know that a unique_ptr reflects ownership, a shared_ptr reflects shared ownership, it's a good convention to say raw pointers do not own, and that shared_ptr won't mess the reference count up.

I don't know what you mean by "base class" vs. "mixin". You seem to be visualizing IRefCount like a Java or C# interface, and the best approximation to that in C++ is a mixin-type class. In C++, there really is no difference between a base class and a mixin, although a mixin is more likely to use virtual inheritance. If you're insisting that this be baked into the class, you're losing some flexibility. I can take anything and wrap it in a shared_ptr without having to either have foreseen that sometime I might want to use shared ownership or recompiling everything.

How do you intend to implement weak_ptr here? What are the alternatives? When the shared count goes to zero, you can neither delete the object nor not delete the object. You seem to be suggesting allocating the memory, using placement new, and then deleting the object when the shared count goes to zero and releasing the memory when both counts are zero. This involves accessing a member of the object after the object is destructed, which is undefined behavior since the object no longer exists. If you want to reference the counts after the object has been destructed, the counts have to be in another object, at which point you can just use shared_ptr. There's also the issue that, if the object would normally be allocated with placement new (some programs maintain a pool for a frequently allocated class, for example), you've screwed that up, so you may need to rewrite the function that handles destruction from use to use (there's no reason why one part of the program couldn't use standard allocation while another used a memory pool with placement new).

I still fail to see that this is easier than shared_ptr, particularly since shared_ptr is already part of the standard library.

This can be superior to shared_ptr in the case where you can put the reference count into the object and use a intrusive_shared_ptr pointer object. The intrusive_shared_ptr contains only an ordinary pointer (unless you put it in an inheritance hierarchy, in which you'll get a vtable pointer, but there's no point in doing that), and there's only one object to allocate and deallocate.

Re:As always with C++, the truth is more nuanced

[w_dragon]

The other downside to make_shared is that I don't think there's an equivalent to std::nothrow, so you must have exceptions enabled to use it and handle out-of-memory conditions.

Re: As always with C++, the truth is more nuanced

[D.McG.]

Interfaces in C++ are simply structs that contain only pure virtual methods. No one uses the non-technical term "mix-in".

Re:As always with C++, the truth is more nuanced

[angel'o'sphere]

Sorry, but this: In C++, there really is no difference between a base class and a mixin,
is complete nonsense.

A mixin in C++ is e.g. a template class that inherits from its template parameter(s).

A interface is a class where all methods are defined pure virtual.

There is no direct connection between both concepts.

Re:As always with C++, the truth is more nuanced

[Pseudonym]

Yet still no modules.

One of these days, Stroustrup will realise (like Stepanov did) that Simula's object model was a mistake.

Re:As always with C++, the truth is more nuanced

[serviscope_minor]

Oh yes? A "mistake".

And what would you replace it with, then?

Re:As always with C++, the truth is more nuanced

[bluefoxlucid]

Candycanes and unicorns.

Re:As always with C++, the truth is more nuanced

[Pseudonym]

A module system, and a mathematically sound object system (like O'Caml, Haskell, etc).

Re:As always with C++, the truth is more nuanced

[beelsebob]

Yes, but with the million dollars you spent on hardware to run your inefficient code, I hired 5 coders for a year, and got way further down the road with a well designed, architected and thought out system rather than a hack on top of a hack.

Re: As always with C++, the truth is more nuanced

[david_thornley]

People who spent time using Lisp use that term. Then again, I appear to be one of the three people in the world who really likes both C++ and Common Lisp.

Re:As always with C++, the truth is more nuanced

[Zero__Kelvin]

"There's a much easier way to accomplish this: use reference counted objects, rather than smart pointer templates around dumb objects. "

You should contact Bjarne and explain this incredible discovery! I have no doubt he has never heard of it, will be amazed at your brilliance, and abandon his approach immediately!

News at eleven

[Anonymous Coward]

Imperative programmers reinvent functional programming concepts, but in a shitty way. More at eleven.

Re:News at eleven

[BlackHawk-666]

When functional languages can do real world high speed low latency application development that rivals c++ for performance, then I'll consider giving up c++. Until then, we'll re-invent your shitty programming concepts in a way that is performant.

Re:Frist!

[Anonymous Coward]

"print" is deprecated. You must now use the safe_print_n function and get a safe pointer back using the SafetyFirst() method of the SafeLiteral class.

Because safe by default, amirite?

Re:Frist!

[lisaparratt]

Safer than you could possibly imagine.

Bjarne should not be writing that

[Carewolf]

He has a connecting to all the features he put into C++ and any coding guidelines should include thing that should not be used. First among those are exceptions, unfortunately Bjarne has never wanted to admit C++ exceptions were a mistake.

Re:Bjarne should not be writing that

[luis_a_espinal]

He has a connecting to all the features he put into C++ and any coding guidelines should include thing that should not be used. First among those are exceptions, unfortunately Bjarne has never wanted to admit C++ exceptions were a mistake.

That's a hard call. Exceptions have their place. The thing I cannot stomach is the catch(...) construct. I understand the technical reasons for having it. I still think that was a bad design decision that outweighs the pros. It is almost always impossible to quickly pinpoint the origin of the error (specially if you do not have a core dumb to at least analyze.)

Re:Bjarne should not be writing that

[Carewolf]

It is not just Google that bans them, it is industry best practise not to use them. While you can make exception-safe code by containing all state information in classes that can properly unwrap them, it is extremly tedious and very error-prone to do. Basically the only safe thing to do after catching an exception is quiting, which means you might as well exit, crash or catch a signal.

Re:Bjarne should not be writing that

[david_thornley]

If your code isn't exception-safe, it's probably bad in several other ways. It's not that difficult to get it right, if you have a clue, and will avoid other problems. If you think industry best practice is C++ that isn't exception-safe, I don't want to work where you do.

Re:Bjarne should not be writing that

[angel'o'sphere]

I don't realy get why people write this nonsense.

You are at an ATM, you insert your card, the card can not be read: DamagedCardException.

The card can be read and you are asked to enter the code, code is wrong: InvalidCodeException

You enter the code three times wrong: CardSwallowedException

You enter the code correctly and want to withdraw $1000, but the bank does not acknowledge: TransactionNotPossibleException.

NONE of the above exceptions will terminate the ATM software but will return with a hopefully meaningful message to the main menu.

(*Facepalm*)
For the application it should be absolutely no difference if you handle errors with error codes or with exceptions. The user should not see any difference, the program should behave exactly the same.
However: working with exceptions is 100 times easier for developers than working with error codes.
If that is not true for you then for funk sake: you should definitely not be a programmer!!!!

Re:Bjarne should not be writing that

[goose-incarnated]

I don't realy get why people write this nonsense.

You are at an ATM, you insert your card, the card can not be read: DamagedCardException.

The card can be read and you are asked to enter the code, code is wrong: InvalidCodeException

You enter the code three times wrong: CardSwallowedException

You enter the code correctly and want to withdraw $1000, but the bank does not acknowledge: TransactionNotPossibleException.

NONE of the above exceptions will terminate the ATM software but will return with a hopefully meaningful message to the main menu.

I wouldn't consider any of those to be exceptions; return DamagedCard, InvalidCode, CardSwallowed or TransactionNotPossible (+ TransactionSuccessful). This allows the caller to be a state machine that changes to different states simply by switching on the return value of the function:

while (1) {
state = readCard ();
switch (state) {
case DamagedCard: //...
case InvalidCode: //...
case CardSwallowed: //...
case TransactionNotPossible: //...
case TransactionSuccessful: //...
}

is a great deal cleaner than

try {
readCard();
// Handle successful return
} catch (DamagedCardException e ) {
// Handle exception
} catch (InvalidCodeException e ) {
// Handle exception
} catch (CardSwallowedException e ) {
// Handle exception
} catch (TransactionNotPossibleException e ) {
// Handle exception
}

By classifying non-exceptional conditions as an exceptional out of the ordinary condition you tend to handle it in an ad-hoc way, treating it as an error. All of those conditions above are *not* errors, they are part of the logic for the ATM. Running out of money in an ATM is also not an error. These things should be handled in the state-machine for the main logic so that at least formal methods can be used to verify that the logic has a well-defined flow for every state. Moving logic out of the normal program flow is asking for errors when someone changes something and it is then not apparent by checking the program logic.

I wrote ATM software for a long long time. Nothing was considered an exception - everything (including errors) was simply a signal to move to some other state which would handle the signal properly. Exceptions are most-used and well-loved by non-CS programmers, because it lets you place undocumented local jumps that bypass the documented logic-flow. Exceptions are hated by CS programmers for the same reason.

Re:Bjarne should not be writing that

[angel'o'sphere]

No, it is not cleaner.
Especially as all the catches you make are at the wrong place.
You only have to do one catch at one place each.

However my example was perhaps to simple, as putting it into a state machine makes sense, too.

Re:Bjarne should not be writing that

[goose-incarnated]

No, it is not cleaner. Especially as all the catches you make are at the wrong place. You only have to do one catch at one place each.

Okay, maybe you can rewrite that try/catch structure in a way that looks cleaner to you, and show me how? I put it the way that I did because I assumed that each response/exception would be handled differently (in actual ATMs every response is handled explicitly and there are very few, usually none at all, catchall for responses/exceptions).

However my example was perhaps to simple, as putting it into a state machine makes sense, too.

In my usual line of work, predictability and consistency is more important than execution speed or development time, hence usage of a state-machine is pretty popular as it allows a formal proof of the logic independent of the actual code review. Having all the logic paths laid out in a state-machine makes using formal proof a great deal easier.

(Code reviews also get easier when no stack unwinding can ever be performed in the middle of a function and no composite datatype implicitly destroys itself and its fields... but that's a different argument :-))

Re:Bjarne should not be writing that

[angel'o'sphere]

You catch exceptions only at a place where you can do something about them.

E.g. when your ATM is idle and gets "activated" by inserting the Card, the only exception you need to catch and handle there is "CardUnreadableException" (or however we named it before).

Same for the wrong code, only when codes are entered you have to handle that.

Bottom line a single if that would handle a single error code, transforms into a single catch. The advantage is: the if has to come directly after the call (and its result is available) ... the catch can be elsewhere.

Re:Bjarne should not be writing that

[Carewolf]

If your code isn't exception-safe, it's probably bad in several other ways. It's not that difficult to get it right, if you have a clue, and will avoid other problems. If you think industry best practice is C++ that isn't exception-safe, I don't want to work where you do.

If you think it is easy, you are doing it wrong. It is as difficulty as coding thread-safe code without using mutexes and semaphores. Execution might be cut at any point in time and the state has to be consistent at that time. If you set a pointer to an array and then the length to it, you are not doing it thread-safe because an exception might come inbetween, which means something as simple as setting data needs to be controlled by state-classes that can rollback half completed state changes in case of an exception.

The easiest way to get around it, is just to use functional programming style where you have little or no state, but that also implies reducing the multiparadigme langauge of C++ to just one paradigme

Re:Bjarne should not be writing that

[Carewolf]

I don't realy get why people write this nonsense.

You are at an ATM, you insert your card, the card can not be read: DamagedCardException.

The card can be read and you are asked to enter the code, code is wrong: InvalidCodeException

You enter the code three times wrong: CardSwallowedException

You enter the code correctly and want to withdraw $1000, but the bank does not acknowledge: TransactionNotPossibleException.

NONE of the above exceptions will terminate the ATM software but will return with a hopefully meaningful message to the main menu.

(*Facepalm*)
For the application it should be absolutely no difference if you handle errors with error codes or with exceptions. The user should not see any difference, the program should behave exactly the same.
However: working with exceptions is 100 times easier for developers than working with error codes.
If that is not true for you then for funk sake: you should definitely not be a programmer!!!!

I don't think you should be a programmer. None of those cases are exceptions, they are errors, errors needs to be handled through normal code path. if you haven't figured out how to handle the potential errors you need to think your design over again, instead of throwing an exception in a half-done transaction and hoping it get magically unwrapped to something that isn't completely fucked.

Re:Bjarne should not be writing that

[angel'o'sphere]

I don't think you should be a programmer.
Same for you.
None of those cases are exceptions, they are errors,
Exceptions and errors are the same thing, only the way you handle them in your code is different. If the language supports exceptions, the preferred way is using Exceptions for errors.
If your language does not support exceptions, the only way is using error codes.
Bottom line: it is a programming idiom. No idea where you got the idea that exceptions and errors are something different. (And how would all the languages that don't support exceptions handle "exceptions" then?)

Re:Bjarne should not be writing that

[david_thornley]

That's one reason you don't use C-style arrays, but rather std::vector or other standard containers. Also, if you must use a C-style array, at least put it in a std::unique_ptr or std::shared_ptr so it gets cleaned up. That said, after the assignment to the pointer, what's going to throw?

You do need to keep exception safety in mind, you need to avoid some pitfalls, and you need to know at least a few constructs that will not throw exceptions. Assignment of primitives will not throw, and you do need to keep your swap functions from throwing. After that, it isn't that difficult. (One tip: if you ever write "delete" outside a destructor, you are probably doing it wrong.)

Things become hairier with threads, but they always do. If you get in the habit of watching what will have to be destructed, it's not that hard.

I'm not saying it's trivial, but it's not that hard to get right.

Cost of safety

[fragMasterFlash]

Its nice to see efforts to drive the complexity out of the design/implementation of safe code but this won't due much to improve the already error prone task of debugging optimized code. You don't always have the luxury of running a debug build, especially when analyzing a crash dump from a customer and templated/STL C++ constructs are often too complex for debuggers to parse properly. Hopefully these efforts reduce the number of crashes enough to justify the added complexity of debugging the crashes that still occur.

Re:Cost of safety

[mrprogrammerman]

There's better support for this scenario in the latest Visual Studio. Unfortunately it greatly increases the size of your pdbs.

Re:Effort will help

[umghhh]

You did not hear this sound? It was like whizzzz or whoooooosh or alike.

Re:Frist!

[Blaskowicz]

Safe but you have to pay a lot of attention to not make it accidentally unsafe, thus.. sort of safe?

Ada had this in 1995

[david.emery]

Ada95 added OO features including clear mechanisms (enforced by the compiler) on how to get OO design benefits without runtime performance costs or risks for dispatching.

Much of what I've seen in C++ is a response to problems in the original language design, particularly gaps or errors of omission.

Computer Science in the 21st Century seems to be full of stuff we knew about in the '80s and '90s, but forgot.

Re:Ada had this in 1995

[Virtucon]

Yo mama!

Re:Ada had this in 1995

[david_thornley]

What part of C++ OO imposes runtime performance costs? Virtual functions are one indirect access of a table that's likely to be in cache already. What are the risks in dispatching?

Modern C++ is a successful attempt to make C++ into a much better language. You could call that a response to earlier problems, but it's not just a bunch of patches.

Computer programming in the 21st Century seems to have problems with stuff we knew about in the 70s. Java's "finally"? Who thought that was a good idea?

Re:Ada had this in 1995

[UnknownSoldier]

> What part of C++ OO imposes runtime performance costs?

Uh, the fact that it is designed for the uncommon single case instead of the common multi case. You want to optimize for the throughput, not latency.

OOP (Object Orientated Programming) has terrible performance scalability since it has terrible D$ (Data Cache) usage. For high performance OOP is completely ditched in favor of DOD (Data Orientated Design). DOD is used heavily in modern game development, and HFT (High Frequency Trading.)

I would recommend starting here:

* Pitfalls of Object Oriented Programming

Even Bjarne Stroustrup was ignorant of D$ usage and how it effects performance:

* Why you should avoid Linked Lists, where someone subtitled it: Stroustrup learns how L1 Cache usage is critical for performance sensitive code.

I would also read Mike Acton's presentation:

* Typical C++ Bullshit

Re:Ada had this in 1995

[Grant_Watson]

C++ grew somewhat organically out of C. C is (IMHO) an excellent language, but its goals often differ from C++'s goals.

I won't argue with your conclusion; it's true. But a lot of what was achieved in the research and design of the '80s and '90s was achieved by burning down the software stack and starting over. (Take Smalltalk for example.) People are rediscovering those things in a context where the existing stack matters and tackling the hard work of reconciling those developments with what we already have in a coherent way.

Re:Ada had this in 1995

[david.emery]

That "piece of shit" is in most modern commercial aircraft these days, as well as the ground ATC systems. Guess maybe you shouldn't fly, then, if that's your opinion, Mr Coward.

There are legitimate criticisms that can be levied against any programming language, as well as against the Ada program. But this comment addresses none of them.

Re:Ada had this in 1995

[phantomfive]

It reminds me of this quote:

"It's quite apparent that the evolution of the C family of languages (C, C++, Java, C#) is converging on a language very like Ada, except unfortunately as a kludgepile rather than a clean design."

Re:Ada had this in 1995

[david.emery]

And that's what makes Ada95 (and subsequent versions) so interesting from a language design perspective. Ada95 built on the Ada83 language (which itself built on Pascal, as well as CLU and other research languages), adding OOP (including supporting concurrent objects in a way that I haven't seen in other "modern" programming languages in this era of multi-core processors). There are design trade-offs, and these are well-documented. If you're interested in such things, the published design team rationale documents (for both Ada83 and Ada95) should be required reading. Ada83: http://www.adahome.com/Resourc... Ada95: http://www.adahome.com/Resourc...

What Ada95 accomplished was to graft a full OO design mechanism (i.e. inheritance) , while preserving type-safety (for scalar types, as well as "objects" or classes), keeping the safety properties (e.g. impossible without unchecked conversion to dereference a null pointer), and providing nearly 100% backwards-compatibility with Ada83. (There were a few inconsistencies, but these were at the edges of the language.)

Oh, and Ada2005 adds support for pre-conditions and post-conditions that matches what Eiffel now provides for defining and enforcing contracts. And it does so while providing the SPARK subset that supports theorem-proving for proof-of-correctness (including concurrent programs), starting with "cannot generate runtime error". See https://en.wikipedia.org/wiki/... A lot of this grew out of David Luckham's work at Stanford on annotation languages such as ANNA and TSL, see http://www.springer.com/us/boo...

Re:Ada had this in 1995

[phantomfive]

Serious question......
Game programmers often use C++ (for various reasons). Since you are a game programmer who doesn't like C++,
What do you typically use to write programs?

Re:Ada had this in 1995

[UnknownSoldier]

> Game programmers often use C++ (for various reasons).

Performance is the #1 of reason, but yeah, C++ gets the right balance of power, compactness, performance, and multi-paradigm design which builds upon C's foundation.

> What do you typically use to write programs?

Just because I'm vocal, and passionate, doesn't mean I toss the baby out with the bath water.

I would be stupid to ignore the wisdom of Bjarne Stroustrup:

There are only two kinds of languages:

* the ones people complain about and
* the ones nobody uses.

To answer your question:

Pragmatic C++. (With some Javascript, since WebGL is my (current) day job)

Which is the balance of the middle ground between basic C and the modern over-engineered clusterfuck of C++. Why do you think there was an "Embedded C++" movement years ago which removed all the Templates, Exception Handling, and RTTI junk? Gee, look, Ubisoft C++ usage does the exact same thing.

To clarify, I use _only_ templates when it makes sense. Most of the time it doesn't. I use #define macro's where it makes sense. Most of the time it doesn't. I don't use Boost because it is over engineered 99% of the time. I uses classes where it makes sense. I use 3rd party libraries only when necessary. I use design patterns only when the model fits - instead of trying to shoehorn the code+data into a broken model.

I've shipped enough games where a full build was 45+ minutes. This is insanity.

Minimal C++ is the mantra. Use the expressive complexity and power of the language when it matters. Most of the time it doesn't.

I just want the insanity of C++ to stop and address the common core issues instead of adding yet-another-flavor-of-the-month concept. Retarded ideas like 2D Graphics Rendering API proposal is the epitome of everything wrong with the committee. Completely out-of-touch with reality and solutions in search of a problem.

When you _even_ have a C++ committee member admitting he writes in a sub-set of C++ himself you know the language has gotten too big. /Oblg. Murphy Computer Law: Inside every large programming language is a smaller one struggling to get out.

*ALL* programming languages suck. Most suck even more.

Want to know someone else who hates C++? Andrei Alexandrescu. *Every* C++ programmer should read until they grok Modern C++ Design: Generic Programming and Design Patterns Applied Guess where he works on now? D (All Things D (programming language) - A Conversation with Andrei Alexandrescu.)

When you even have Scott Meyers at a D Conference (DConf 2014: The Last Thing D Needs (Scott Meyers), you know the language has potential. D has its own problems but I would keep my eye on it. :-)

As bad as C++ is, for my needs it is better then the alternatives.

Re:Ada had this in 1995

[david_thornley]

Having gotten through about half of that Pitfalls slide show by now, I'm not impressed. Much of the discussion is about the "is_dirty" flag which has as much to do with OO programming as my cat's last hairball. It's worth commenting on, sure, but mixing that with the alleged evils of OO programming makes the presentation hard to follow.

Re:Ada had this in 1995

[phantomfive]

That's a nice comment.

Re:Ada had this in 1995

[UnknownSoldier]

If you "Ignore the messenger because you don't like the message" you'll miss out on a lot of great wisdom. You'll find the following links to be a lot more palatable.

Mike Acton reviewed Ogre 1.9's OrgreNode.cpp pointing out its horrible design and performance.

As a result Orge 2.x game up with a gameplan -- they put together a PDF of how OOP screwed their performance over.

Turns out, Mike Acton was right. They ended up with a 5x performance increase by ditching OOP and using DOD.

What instead of an exception?

[tepples]

Bjarne has never wanted to admit C++ exceptions were a mistake.

What should a method that fails do instead of returning an exception? Should it instead be set up to explicitly return two different types of return value, namely the object that it's supposed to return if it exceeds or an object describing the failure if it fails?

Re:What instead of an exception?

[Yosho]

I can't speak for the original poster, but as for myself, I think that conceptually exceptions are great, but the C++ implementation of them is full of holes and prone to abuse. As much as the Slashdot base loves to hate Java, I think Java got exceptions right.

Notable differences:
1) There's a distinction between checked (compile-time) and unchecked (runtime) exceptions. All C++ exceptions are unchecked.
2) A method that can throw checked exceptions must declare every checked exception it can throw, and a method that calls another method that can throw checked exceptions must explicitly catch or re-throw them. These can be verified at compile time.
3) Every object that can be thrown/caught must implement the Throwable interface, so it has a predictable interface and can be properly manipulated in an object-oriented manner.
4) try/catch blocks also have a "finally" clause that is guaranteed to be run after the try/catch blocks complete, regardless of whether either one of them runs to completion or throws an exception out of the method. This is crucial for safely cleaning up filesystem/network resources -- the C++ alternative is only allocating objects on the stack and implementing destructors that clean up their resources, but then you have the restriction of not being able to allocate on the heap, and it may not also be obvious from looking at the try/catch block what the destructors are doing or in what order they'll be called in...

I go back and forth between C++ and Java development a lot, and every time I go back to C++, I'm immediately reminded why C++ developers are so averse to using exceptions for error handling.

Re:What instead of an exception?

[serviscope_minor]

1) There's a distinction between checked (compile-time) and unchecked (runtime) exceptions. All C++ exceptions are unchecked.

I agree with that. Exceptions are entirelt typed at runtime which is not very C++ish. I don't really feel all that happy about thar in C++.

4) try/catch blocks also have a "finally" clause that is guaranteed to be run after the try/catch blocks complete, regardless of whether either one of them runs to completion or throws an exception out of the method. This is crucial for safely cleaning up filesystem/network resources -- the C++ alternative is only allocating objects on the stack and implementing destructors that clean up their resources, but then you have the restriction of not being able to allocate on the heap, and it may not also be obvious from looking at the try/catch block what the destructors are doing or in what order they'll be called in...

I don't see how that's a downside in C++. RAII and destructors mean that in C++, the finally block is completely unecessary. In both C++ ang Java you've got to have a handle for a resource somewhere accessible and that ultimately means a reference has to be somewhere on the stack if you follow the chain all the way back. Otherwise in Java it will be GC'd. Since you've got to have a reference somewhere, I don't see the problem with having the reference clean up after itself.

Re:What instead of an exception?

[0123456]

And this is why it often seems that 90% of the Java code I read is catching exceptions and doing stuff with them. Normally throwing another exception.

Re:What instead of an exception?

[tepples]

Every object that can be thrown/caught must implement the Throwable interface

Then have all exceptions extend a subclass of std::exception . The guidelines mention use of a subclass as opposed to using the built-in exceptions directly.

the C++ alternative is only allocating objects on the stack and implementing destructors that clean up their resources

Also called Resource Acquisition Is Initialization (RAII), or "automatic resource destruction" if you don't want to remind readers of the record industry (RIAA).

but then you have the restriction of not being able to allocate on the heap

You can take advantage of automatic resource destruction if you wrap your object on the heap in a smart pointer type (std::unique_ptr or std::shared_ptr as appropriate) on the stack. If that isn't appropriate in a given situation, C++11 supports a scope guard idiom using std::shared_ptr and lambda expressions. The finally factory described in the Guidelines is ultimately an update of a method described in a 2000 article by Andrei Alexandrescu in Dr. Dobb's .

Re:What instead of an exception?

[david_thornley]

C++98 did have the "throw" function specification, and in general it was found to be more trouble than it was worth, with the possible exception of "throw()", which should be replaced by "noexcept" in modern C++.

"finally" does not exist in C++, fortunately, since RAII is much better. There's no reason you can't allocate on the heap and have destructors clean everything up. That's what auto_ptr was for in C++98 and what shared_ptr and unique_ptr are for in C++11. If you need to worry about what the destructors are doing and what order they're called in, you're almost always doing it wrong. (There may be applications I am currently unfamiliar with where that matters, but that would be unfortunate.) A "finally" block has low cohesion and high coupling, whereas destructors have high cohesion and low coupling.

As far as interfaces go, they're there if you want to use them. C++ allows a lot of things Java forbids, which means Java is better for mediocre programmers than C++ is.

Smart pointers, to use RAII and the heap, are a very basic features of modern C++. If you don't understand them, you're not going to write good C++.

Re: What instead of an exception?

[slack_justyb]

I too lament the way C++ does exceptions versus how Java handles then. That said, you bring a good point. I've seen new guys in the shop coming from a Java background struggling to completely wrap their heads around RAII. Finally in Java is the typical source for the struggle.

Re:What instead of an exception?

[firewrought]

That's why checked exceptions are silly. Java assumed you want to handle exceptions close to where they happen (and bad programmers do, returning null values or zeros or whatever that cause further bugs and hide the origin of the real problem).

No, 99% of the time, if method foo() calls method bar() and method bar() can't do its job properly, then method foo() also fails to do its job properly. Just cleanup/rollback if necessary and let that exception unwind the stack where a thread-level exception handler can log it and take appropriate compensating action (restarting a job loop, showing the user an error message, exiting the process, or whatever).

C# gets it right, especially with adding using() blocks and letting you attach contextual data to the exception as you unwind. D takes it a step further and lets you add scope(exit) blocks. Rust, alas, eschews exceptions and will always be plagued by panic-prone code (you think real-world programmers are going to diligently inspect each Option/Result instead of unwrap()ing it?).

Exceptions are powerful tool for writing concise, reliable code. Too bad C++ gave them a bad name.

Re:What instead of an exception?

[lgw]

And this is why it often seems that 90% of the Java code I read is catching exceptions and doing stuff with them. Normally throwing another exception.

Ahh, Pokemon code! Gotta catch em all!

If you can actually find the program logic hiding in all the Java boilerplate, you're doing Java wrong: moar boilerplate!

Re:What instead of an exception?

[spitzak]

C++98 did have the "throw" function specification, and in general it was found to be more trouble than it was worth, with the possible exception of "throw()", which should be replaced by "noexcept" in modern C++.

Apparently it was Visual C++ that made "throw()" do what "noexcept" now does: it means you can be certain that this code will not throw an exception. This caused it to be used a lot, but the actual C++ definition of what "throw()" did was not that at all and was quite useless.

"finally" does not exist in C++, fortunately, since RAII is much better. There's no reason you can't allocate on the heap and have destructors clean everything up. That's what auto_ptr was for in C++98 and what shared_ptr and unique_ptr are for in C++11. If you need to worry about what the destructors are doing and what order they're called in, you're almost always doing it wrong. (There may be applications I am currently unfamiliar with where that matters, but that would be unfortunate.) A "finally" block has low cohesion and high coupling, whereas destructors have high cohesion and low coupling.

You are correct that RAII can do everything "finally" does, but it does sometimes require the writing of very strange classes when some kind of finally statement would work better. But to actually work well the statement can't be at the end, it should be next to the definition. Something like this would work just like a local unique_ptr (not suggesting this but imagine a more one-off instance of something that needs destruction):

          char* ptr = new char[BUFSIZE];
          finally { delete[] ptr; }

Re:What instead of an exception?

[angel'o'sphere]

All C++ exceptions are unchecked.
That is wrong.

If a function signature contains the exceptions that are thrown, the exceptions are checked exceptions.

If the function signature does not define thrown exceptions, the exceptions coming from it are unchecked, obviously.

The difference between Java and C++ is: the Exception type already defines in Java if the exception is checked or not, while in C++ every function defines if it wants to throw checked or unchecked exceptions.

Sad, really

[jandersen]

I think it is sad, looking around on the responses so far, to see, yet again, that the overwhelming response to this is to jeer at anything that is beyond people's comprehension. I guess what it boils down to is, that far too many who call themselves coders can't be bothered to sit down and work out a detailed plan before barging ahead. You get nothing but trouble from OOP if you think in terms of simple scripts, and that is particularly true of C++.

Re:Sad, really

[myrdos2]

In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......

-- Edsger W. Dijkstra

I love this quote, and I say that as a C++ programmer. It falls in with my own philosophy, which is that the more complicated something is, the less likely people will get it right. And C++ is extremely complicated. It's not the OO design that necessarily trips people up, it's the sheer amount of minutiae you need to remember and the care you must take not to do something stupid.

Re:Sad, really

[david_thornley]

My impression of earlier versions of C++ was that it was a great language to lay formal siege to a problem, but not nearly as good for less formal approaches. Modern C++ has improved the siege engines, and become a lot more mobile.

Re:Sad, really

[phantomfive]

that far too many who call themselves coders can't be bothered to sit down and work out a detailed plan before barging ahead.

That's a good description of the C++ design process, and why the "approved" way of using the language is completely different than the "approved" way of not long ago.

How many ways are there to allocate memory in C++? I'm starting to lose count.

Re:Sad, really

[phantomfive]

No, I'm just talking about on the heap. I've got these, probably missing some:

malloc (alloc, calloc, etc)
new
new[]
new (nothrow)[]
make_shared
shared_ptr(new ....)
allocate_shared
std::allocator::allocate
make_unique
make_unique(new...)

I am sure I'm missing some. I think most of those are deprecated.

Re:Sad, really

[msobkow]

A programmer should never "know" what their code is going to look like. It needs to evolve from the initial design, correct oversights and misunderstandings, and organically become what it needs to be instead of what you first thought it would be.

If you can analyze a problem so thoroughly that there is no room nor need for that evolution, you were dealing with a trivial problem in the first place and probably over-engineered your solution.

Re:Sad, really

[myrdos2]

A programmer should never "know" what their code is going to look like. It needs to evolve from the initial design, correct oversights and misunderstandings, and organically become what it needs to be instead of what you first thought it would be.

I agree, more or less. I've completely moderately-sized projects that pretty closely followed my initial design, but other times I realize the design needs to be modified or scrapped completely when I'm halfway through. Dijkstra is just saying that your code should never reach a point where you can no longer fully understand what your're doing when you modify it. It's hard to argue with that.

Re:Sad, really

[serviscope_minor]

How many ways are there to allocate memory in C++? I'm starting to lose count.

Um... three? Stack, heap and static?

Everything else is just wrappers around those.

Re:Sad, really

[phantomfive]

I clarified what I meant in a different comment.

Re:Sad, really

[angel'o'sphere]

I believe you only forgot "placement new".
Or if someone wants to nitpick, overwriting new for a class, but that comes down to finally use one of your proposals ;D

Re:Sad, really

[phantomfive]

And looking back, I messed up on some in that list, too.........make_unique(new...) should be unique_ptr(new...) and I don't think there's an "alloc," I was thinking alloca(), but that allocates on the stack not on the heap!

Re:Sad, really

[Anonymous Coward]

If you're going to list those functions that just new a particular type of object and return the result as "separate ways to allocate memory", then you're missing quite a few:
std::string
std::list
std::vector
std::set
std::map
std::deque
std::multimap
std::multiset

So confusing! Why isn't there only one way to allocate memory?

Re:Sad, really

[goose-incarnated]

How many ways are there to allocate memory in C++? I'm starting to lose count.

Um... three? Stack, heap and static?

Everything else is just wrappers around those.

C++ says nothing about stack and heap, only about lifetimes. As OP never asked about variable lifetimes and/or scope your answer is a great example of a non-sequitur.

As far as C++ memory allocation goes, some of ways to allocate an arbitrary memory block/object, regardless of lifetime, is in this post here.

Re:Sad, really

[angel'o'sphere]

I guess the question if there is an alloc depends on the underlying libraries. Usually you have alloc, malloc and calloc ...

Yeah, the naming problems, can only imagine "alloca" comes from "alloc auto" indicating that the storage class auto is on the stack.

The auto keyword got reused for something else again, didn't it? I'm not up to date with 11/14 standards.

Re:Sad, really

[serviscope_minor]

Most of what you listed are just library factory functions.

Re:Sad, really

[phantomfive]

If 'new' is now deprecated, and using a factory smart-pointer function is the recommended way, the it's fair to list it.

Re:Sad, really

[phantomfive]

Yeah, auto is what you use when it's really tough to figure out what kind of declaration should actually be used. Kind of like C# 'var'

Re:Sad, really

[angel'o'sphere]

Ah, type interference, I remember now.

Re:Sad, really

[phantomfive]

lol it's inference, but maybe interference is a better name for it lol

As always, guidelines are for beginners

[PhrostyMcByte]

Just like "don't use goto", or "don't use threads", etc., these guidelines and recommendations are really great to prevent beginners from making hard to spot errors, but all those variations and features exist for a reason and have a use.

Re:As always, guidelines are for beginners

[140Mandak262Jamuna]

Just like "don't use goto", or "don't use threads", etc., these guidelines and recommendations are really great to prevent beginners from making hard to spot errors, but all those variations and features exist for a reason and have a use.

Nobody uses GOTO anymore. With event driven programming and call back functions, it all spaghetti code strewn with COME FROM statements, effectively.

Re:As always, guidelines are for beginners

[Bengie]

I've ran into situations where not using GOTO resulted in much messier code that was harder to read. This rarely happens, but it does happen, and I always take a step back and try to find a better way than using GOTO.

Re:As always, guidelines are for beginners

[Darinbob]

I use goto. Sometimes. When you're in C then it's can be effective way to do a function clean up before exiting. Sure this can be over done but trying to avoid a goto like a religious taboo can also result in some pretty nasty code to replace it.

Re:As always, guidelines are for beginners

[Darinbob]

Should not be used, or must not be used?

And which of them are you referring to and what are the bad reasons? Because one day someone noticed the proliferation of spaghetti code and wrote a paper to encourage use of structured programming does not mean he intended to have a fundamental prohibition against one construct.

But then, programming seems to be all about superstition. It had superstition in the 60s and it still has superstition today. Someone learns a rough rule of thumb as a student and keeps sticking to that for their entire career without thinking about why that rule of thumb was created. Someone had a bad day with threads and declares jihad against them for all time. The adherents of CamelCase struggle for dominance against snake_case believers. One exit from a function shall rule them all. Eat eggs from the little end and not the big end. It all boils down to letting others do the thinking for you.

Re:As always, guidelines are for beginners

[w_dragon]

For C that's a perfectly reasonable use of goto. For C++ you should use unique_ptr or wrap your resource in your own object that you can stack allocate. RAII is a very nice pattern in C++.

Re:As always, guidelines are for beginners

[angel'o'sphere]

RAII is not a "pattern" it is an "idiom".

A pattern is independent from programming languages, idioms are thins you only can do in one/some language.

e.g. using pointers and ++ to copy a \0 terminated string like this:

      strcpy(char* dest, char* src) {
            while (*dest++ = *src++)
                    ;
      }

is an idiom ... supported by certain languages, not a pattern.

Re:As always, guidelines are for beginners

[Darinbob]

Yes, C++ has nicer ways to manage this, and I've used them.

Re:As always, guidelines are for beginners

[Darinbob]

I hate patterns. They're too much like verses from a religious text, because I've run across people who seem unable to understand your code unless it uses patterns from the official pattern Bible. Holding a conversation with them can involve being interrupted every few minutes with "oh, that's a FurblingFunctorFactory, why didn't you say so?" If you don't keep a close watch they'll go and changing existing/working code to rename classes to indicate what pattern they are.

Re:As always, guidelines are for beginners

[goose-incarnated]

For C that's a perfectly reasonable use of goto. For C++ you should use unique_ptr or wrap your resource in your own object that you can stack allocate. RAII is a very nice pattern in C++.

So unique_ptr will close open file handles and network connections?

Re:As always, guidelines are for beginners

[angel'o'sphere]

Well, for most patterns it makes no sense to have the role names in the class names. Builders and Factories might be exceptions.

The problem is simply that many developers are uncomfortable outside of their own niche. If they have not written the code or are somehow close to it, they have trouble understanding it.

On the other hand that can easy be turned around: most programmers are not able to write code that is easy to understand by other programmers.

I for my part used to document what patterns are used/which roles a class played when I still did C++ ... books about patterns where pretty new that time, luckily I already new most of them, just had no names for them.

Re:As always, guidelines are for beginners

[Garfong]

I think the classic one is error handling in C. Usually each error case has some standard unlock all the locks; free temporary objects; close files, etc. Instead of copying & pasting for every error, put it at the end of the function and do if (error) { goto error_handler; }.

Dosn't apply to C++ though since you can use exception handling. I think modern compilers will even convert the exception into a goto in many cases.

Re:As always, guidelines are for beginners

[w_dragon]

Yes, it takes a deleter function as an optional parameter, so it can be used for pretty much any resource.

Re:As always, guidelines are for beginners

[paugq]

Nobody uses GOTO anymore. With event driven programming and call back functions, it all spaghetti code strewn with COME FROM statements, effectively.

You have never read the Linux kernel source code, systemd, Samba, etc, have you? They use goto extensively and it results in easy to understand code.

The liberator and the wise crack.

[140Mandak262Jamuna]

"Within C++ is a smaller, simpler, safer language struggling to get out." -- Bjarne Stroustrup

Very true, C++ would struggle no matter how laudable the goal is.

Should file not found always be a fatal error?

[tepples]

You claim that all exceptions should be fatal. I hope this was sarcasm. If not, then for example, if a program lacks a configuration file because it is being started for the first time, what lesson ought to be taught, to whom, and why?

Re:Should file not found always be a fatal error?

[Seq]

You just need to catch the crash. Though it would be helpful if we could pass along some additional information about the crash..

Oh. Hmmm..

Re:Should file not found always be a fatal error?

[tepples]

In order to create the configuration file when the program is run for the first time, the program must first attempt and fail to read the existing configuration file.

Re:Should file not found always be a fatal error?

[mrchaotica]

The lesson that should be taught to the programmer is that the lack of a configuration file is a totally normal and expected condition which should be handled by the program's normal control flow.

Re:Should file not found always be a fatal error?

[narcc]

Somehow, we managed to handle errors decades before exceptions. Through arcane magic, we handle errors today in languages without exceptions.

There are exceptional ways to handle errors that work exceptionally well, exceptions excepted, naturally.

Re:Should file not found always be a fatal error?

[tepples]

Is the distinction between normal failures and exceptional failures true of all languages with exceptions or only of C++? If of all languages, then how should, say, a program in Python detect this "totally normal and expected condition" without catching an exception?

Re:Should file not found always be a fatal error?

[tepples]

Somehow, we managed to handle errors decades before exceptions.

Decades before exceptions, there wasn't nearly as much multitasking as there is nowadays. Fans of exceptions might claim that exceptions help thwart time of check to time of use (TOCTTOU) attacks.

Re:Should file not found always be a fatal error?

[mrchaotica]

You're trying to make me declare some sort of hard-and-fast rule to something that's really an issue of style, which I won't do. But here's a heuristic: if you expect to succeed in opening the file, you could probably go ahead and use the 'pythonic' 'ask forgiveness, not permission' pattern. But if you're trying to (for some reason) open only one of 50 files and expect the other 49 not to exist, then your loop should probably look more like

for name in filenames:
....if isfile(name):
........f = open(name)

instead of

for name in filenames:
....try:
........f = open(name)
....except IOError:
........#do nothing

Also, exceptions should be used much more sparingly in C++ than in Python because they don't work as well in the former.

Re:Should file not found always be a fatal error?

[david_thornley]

Having been handling errors for a long time before I ran into exceptions, I don't agree that having to constantly check some sort of error flag is better than using exceptions.

Re:Should file not found always be a fatal error?

[narcc]

Exceptions are one approach. The mistake is in thinking that one approach supersedes all others.

It has more than its share of problems, which need to be acknowledged if we're to move beyond them.

Re:Should file not found always be a fatal error?

[angel'o'sphere]

The lack of a configuration file is absolutely not normal.
For a desktop app it might be possible to recover and be of some use for the user.
A server application whee a configuration file is missing is by default dysfunctional, and hence should terminate with a useful error message.
It makes no sense that hundreds or thousands of users are able to connect to the server application and lose their work because a vital item is not configured properly.

All this has nothing to do with exceptions ... but they help as they usually propagate upwards and lead to thread or program termination, even if they are not properly handled.

Re:Should file not found always be a fatal error?

[david_thornley]

There are many ways to handle errors, and I'm not giving up exceptions unless and until somebody can show me they've got something better.

For events that may routinely happen, it's reasonable to write specific error-handling code. For events that almost never happen, exceptions beat checking error codes all over the place.

It's pointers all the way down, jake !

[vikingpower]

More than half of Stroustrup's talk was concerned with pointers. In 2015, we still need the kind of effort Stroustrup is calling for, simply because a fairly advanced OO language STILL uses pointers, with the risk of dangling ones, of pointers outliving the thing they point to, etc. etc. ? I dunno, people... but this is one of the main reasons I never made the switch to C++.

Re:It's pointers all the way down, jake !

[The Evil Atheist]

Unless you're dealing with hardware directly, you don't need pointers at all.

Re:It's pointers all the way down, jake !

[david_thornley]

The other thing about GC is that it solves the resource deallocation problem for memory only. It doesn't support deallocating other resources which may be more important to deallocate promptly. (People are working on C and C++ garbage collection, and there have been attempts, but none have gained much popularity. Whether this is because nobody has worked hard enough, or because it doesn't offer a solution that much better than smart pointers, or that C and C++ just won't work well with GC is an interesting question.)

Re:It's pointers all the way down, jake !

[firewrought]

The other thing about GC is that it solves the resource deallocation problem for memory only.

That's like saying that the "walking on land" (instead of swimming 10 meters below the surface with SCUBA equipment) solves the resource problem for air only... not food or heat or shelter. Hey buddy... air is your most constant, immediate resource; you need it to do the smallest of things. Solving the air problem by walking on land frees up lots mental energy to focus on those other problems.

If you really need the speed or fine-grained memory control, then sure, use C++. But it's illogical to reject GC for solving "only" 95% of resource/corruption/security problems. Every programming effort--from building a new language to coding a DBMS to designing a website to creating a line-of-business desktop application--is ultimately an attempt to reduce complexity for someone [except maybe game programming, where you're artificially creating complexity for the user!]. GC is one of the biggest wins in the history of computer science, almost up there with concepts like subroutines and version control.

Re:It's pointers all the way down, jake !

[david_thornley]

I'm not knocking garbage collection, believe me. I've happily used languages with it. I'm not pointing out how good it is because I think that obvious. However, it isn't uniformly better than C++ resource management.

GC solves what is almost always the biggest resource management problem in a very simple way, but isn't extendable. C++ and RAII solve a more general problem in a clumsier way. I'd like to see a good combination of these, but I haven't yet. Another advantage of the C++ way is that it can avoid the "finally" block that makes it harder to write clean Java code and know it correct.

Re:It's pointers all the way down, jake !

[vikingpower]

I know all this. Funny that there seems to be hardly any golden/middle road between the hardcore use of pointers and having full-fledged garbage collection. There was an effort, around the time Java took off - 1996-ish - to bring Ada 95 and Java closer together: http://www.adahome.com/Tutorials/Lovelace/hello.ada  .

Nothing really came from it, AFAIK. Alas, alas...

Re:It's pointers all the way down, jake !

[Xtifr]

Tell that to all the C libraries I link to from C++ programs.

Until someone is motivated to create C++ wrappers for every C library I might possibly want to use, I don't see any way to get away from some use of pointers. And so, until that mythical day, I think having some guidelines for pointer use in C++ is a good thing. Especially if the first one is:don't use raw pointers if there's any reasonable alternative. :)

(Of course, I could limit myself to languages where you cannot use a C library until someone creates a wrapper for it, but that seems unnecessarily restrictive.)

Re:It's pointers all the way down, jake !

[matfud]

Java 1.7 has try -with-resources which can auto close any declared AutoCloseable object on any exit from the try block. No need for finally or catch clauses.

Sort of RAII for non anything you want.

Re:It's pointers all the way down, jake !

[david_thornley]

Really? Java uses pointers all over the place. If it isn't an elementary data type, it's a pointer.

Re:It's pointers all the way down, jake !

[david_thornley]

Thank you. I don't keep up with Java, since I don't use it. (This is why I like to rant about features rather than languages. My ranting about finally is still applicable, but as you point out if I made it a rant about Java it would be obsolete by now.)

Re:It's pointers all the way down, jake !

[vikingpower]

You're wrong. Java uses references, not pointers. And Java references are garbage collected, as pointed out by more than one poster in this thread. Quite the difference.

Re:It's pointers all the way down, jake !

[The Evil Atheist]

In the context of C++, how does bringing Java into it relevant at all? Any idiot could tell I wasn't talking about all languages in general - but that I was talking about modern usage of C++.

Re:It's pointers all the way down, jake !

[The Evil Atheist]

In Java, references are pointers. Just because you call them something different doesn't mean they aren't the same. Hell, you can get a "reference" to null in Java. The only difference is that you can't do pointer arithmetic.

Garbage collection has nothing to do with whether something is a reference or a pointer. C++ has garbage collection in the form of scope based destruction of non-pointer owned objects.

Re:It's pointers all the way down, jake !

[matfud]

No problem.

Catch and finally for resources have been the bane of Java devs forever. Test for null, attempt to close, have to wrap the close call in an exception. It is not to bad when you have one non memory resource (file, network, sql, etc.) but two or more and it became a mess of nested exception handling and complex finally constructs to try to ensure everything was closed and released.

Re:It's pointers all the way down, jake !

[matfud]

So back to your point about a good combination of memory GC and RAII (memory is well handled by GC, other resources are not handled at all except as a side effect of freeing memory). Java is one language, I am familiar with, that is attempting to give you some features of both without the all out "hang yourself whilst shooting yourself in the foot when jumping out of a plane with a faulty parachute" approach of C++. (It is possible you will miss your foot, hit the rope which will get tangled in the faulty parachute and cause you to land safely with only minor broken bones. It will be fast though ;P

I'm still out on if they are good. I would say better than before.

Re:It's pointers all the way down, jake !

[david_thornley]

I was using Java as an example. In C++, I haven't seen a program of significant complexity without explicit use of pointers (raw or smart). They're useful for shared sections of memory, and are valuable in function definitions since they have a specific invalid value. Moreover, they are how dynamic memory allocation works. It seems to me that writing programs without pointers would be limiting.

Re:Ditch C++

[david_thornley]

The core language spec isn't much over 400 pages, and the library adds something less than a thousand additional pages. Ever since around 2000, when O'Reilly published "Java in a Nutshell" in four volumes, I've stopped listening to complaints about excessive library size.

There are unit testing frameworks for C++. Unfortunately, C was not straightforward to parse, and so C++ isn't either, so that hinders the development of additional tools. I expect Clang to improve that eventually, but it's a language problem that can't be fixed.

There are safe ways to pass pointers around, and there's a lot of work going on on how to do it. It reminds me of people discovering exception safety after the first C++ Standard came out.

Re:Instrumenting c++ to behave like Rust

[Tailhook]

I found Rust

I've found it best not to talk about Rust around here. The language has already accumulated a legion of haters at Slashdot. Rational discussion about Rust sans the office punklets happens at Hacker News.

It was anticipated that Rust would motivate some progress in C++ memory safety. Some have argued that if that is all that Rust accomplishes it is worthwhile. Too bad an entire language has to be invented to get some folks off the dime.

The uptake of Rust is so large though I don't think it's going to go away just because C++ adopts some degree of compile time memory safety. The language is great on it's own merits, there is none of that half century of baggage to slog through and the entire stack and all native Rust third part modules provide the same memory safety guarantees, barring 'unsafe.'

These things, combined with the never ending stream of opportunities the segfaults and overflows that C/C++ cannot avoid providing will ensure a chunk of mind-share, haters be damned.

Re:Frist!

[BlackHawk-666]

Safe as houses, safe as fuck!

Checked exceptions as API

[John Bayko]

Checked exceptions are probably better viewed as part of a the API, in the sense that if exceptions didn't exist, these would be implemented as return parameters, which you would also have to declare and either check, or pass to the calling code.

Maybe all exceptions should have been checked, but the difference (not always followed) is that checked exceptions are supposed to be for things the deployed program or user has some control over (missing file, sleep interrupted - that is, things you should plausibly expect to happen), and unchecked exceptions are for bugs or uncontrollable things (NULL, out of memory - bugs you should have fixed, or can't expect). In other words, handling checked exceptions should be as natural as checking to see if fopen returned NULL in C.

Not done as consistently as it should have been in Java though. Made them confusing, inconsistent, and irritating to a lot of people who just decided checked exceptions were wrong rather than misimplemented (similar: operator overload abuse makes many people dislike the entire idea).

Re:Frist!

[Opportunist]

It will give you code so secure that it can even order some fruity cocktails with those little umbrellas!

Re:That's obvious

[Opportunist]

Or the ever popular MessageBox with ERROR! in the caption, no text and the choice between the two buttons "yes" and "no".

Just to keep the user sweating whether he could possibly save his last 2 hours of work just by hitting the right button.

Re:Instrumenting c++ to behave like Rust

[Grant_Watson]

Half century? Are you counting from Algol?

That said, the cruftiness of C++ is one of the things that keeps me from bothering to properly learn it, however much I respect its newer developments. Another is that its place on the scale of abstraction isn't often a place that I need to go personally: C or Python usually makes more sense for me.

Where on that scale would you say Rust lies? Is its target use software that lies on the boundry between systems software and applications, e.g., web servers?

Exceptions are TOCTTOU safe

[tepples]

if a program lacks a configuration file because it is being started for the first time

That isn't an exception. That's a given.

Based on a cursory Google search, "given" appears not to be a term of art in programming. What is the C++ idiom to handle givens? I know Python's idiom is Easier to Ask Forgiveness than Permission (EAFP), which uses exceptions liberally because they're less likely to be vulnerable to time of check to time of use (TOCTTOU) attacks on a multitasking system than the alternative Look Before You Leap (LBYL) paradigm.

Exceptions were devised to handle exceptional events, not to handle your main flow of control.

"Use the settings in the configuration file except when the configuration file does not exist." How is that not "exceptional"?

Re:Frist!

[slickwillie]

If you had written it in C++ instead of BASIC it wouldn't be offtopic.

Next step:

[mobby_6kl]

"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" becomes legal C++.

Re:Next step:

[vux984]

#define buffalo x++;
#define Buffalo x--;

{

int x=0;

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo

printf(x);
}

That'll pass muster even in K&R C :p

Allowing inconsistent objects to exist

[tepples]

Nothing ensures that the config file exists, and your program is responsible for creating it.

You appear to state that the std::ios::fail() paradigm of C++, which allows an inconsistent stream object to continue to exist, is superior to the exception-on-failure paradigm of Python. Do I understand you correctly?

Re:Instrumenting c++ to behave like Rust

[Pinky's Brain]

Seasoned professionals have given us decades worth of mostly unnecessary buffer overflows.

Re:Effort will help

[david_thornley]

FWIW, Lakos' book (he wrote only one, but it's a good one) was published in 1996 with a possibly new edition in 1997. Since some of the recommendations appear quite specific, I don't know how applicable it is in 2015.

Re:Ditch C++

[david_thornley]

The dead tree versions are expensive. The PDFs are far cheaper, and less dangerous.

Re:Bleh C++

[david_thornley]

Except in weird circumstances, valid C++98 code will work in C++14, or it will fail to compile and it'll be obvious what needs to be changed. I've never had any problems upgrading C++ versions.

There is no C/C++ language. There are two languages, C and C++. Both are useful, but the common subset is suboptimal C and really bad C++. Know which language you're working in. Consider other languages for projects that don't play to the strengths of C++ (for example, Javascript will work much better embedded in web pages than C++).

There are good C++ compilers for Linux and BSD. There's no reason to restrict yourself to C, unless you're working on a particular project with particular requirements. (Don't try to submit Linux kernel patches in C++, for example.) Both g++ and clang are much better at standards conformance than Visual C++.

Re:Ditch C++

[sribe]

Myself, I am currently being impressed by the efforts of the golang community.

No generics? Not only not a set collection in the standard library, but no reasonable way to define one?

Go is a nice, tidy, compact little language. But...

You just created a TOCTTOU race bug

[tepples]

for name in filenames:
    if isfile(name):
        f = open(name)

Congratulations: You just created a time of check to time of use (TOCTTOU) race bug. Consider what happens if another process deletes the file between the call to isfile and the call to open.

exceptions should be used much more sparingly in C++ than in Python because they don't work as well in the former.

Could you explain what you mean by this? Is it that Python tends to throw (predictable) exceptions in cases where C++ has (unpredictable) undefined behavior?

Re:You just created a TOCTTOU race bug

[mrchaotica]

Congratulations: You just created a time of check to time of use (TOCTTOU) race bug. Consider what happens if another process deletes the file between the call to isfile and the call to open.

Then open() throws an exception and you're no worse off than if you had blindly called it, "expecting" the exception, in the first place. My examples were minimal in order to show the overall pattern of execution; I never claimed they were complete or that they included all the error handling they should actually have.

exceptions should be used much more sparingly in C++ than in Python because they don't work as well in the former.

Could you explain what you mean by this? Is it that Python tends to throw (predictable) exceptions in cases where C++ has (unpredictable) undefined behavior?

http://yosefk.com/c++fqa/defec...

Re:You just created a TOCTTOU race bug

[tepples]

yosefk writes:

If we use exceptions, we have to write exception-safe code - code which frees all resources when the control is transferred from the point of failure (throw) to the point where explicit error handling is done (catch). [...] To solve this, you are supposed to use RAII, meaning that all pointers have to be "smart"

I think this was written before C++11 standardized two suitable smart pointers in std::unique_ptr and std::shared_ptr. Stash resources allocated by the constructor in a smart pointer.

In 17.4, yosefk continues:

How are you going to figure out whether your program manages resources correctly or not when it's littered with smart pointers of different kinds, especially in [...] cases when "ownership" (the right & duty to dispose a resource) is passed from object to object

The replacement of the problematic std::auto_ptr with std::unique_ptr that uses C++11's new move-construction semantics and addition of std::shared_ptr solved, as yosefk mentioned with the references to Boost pointer templates that made it into TR1.

I wonder whether yosefk plans to refactor this page into "Defective Modern C++" to parallel the title of a 2014 book by Scott Meyers (ISBN 9781491903995).