Bjarne Stroustrup Announces the C++ Core Guidelines 262
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.
Here is the video of the talk, and here are the slides.The guidelines themselves are here.
Wait what? (Score:5, Funny)
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: (Score:3)
If you take the drudgery out of finding stack overflows, then perhaps you'll have more time to d%%% around on //||] stackoverflow.com.
Re: (Score:2)
which address the issue of pointer ownership.
I own the pointers, they're all mine!
Re: (Score:2)
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? (Score:5, Funny)
Next step: (Score:2)
"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" becomes legal C++.
Re: (Score:2)
#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
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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? (Score:5, Insightful)
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: (Score:3)
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
What's the name of the Library? (Score:2)
CPPCoreGhost?
Re: (Score:2)
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 (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
And I wrote my own OS in C while you were busy doing that.
As always, guidelines are for beginners (Score:2)
Re:As always, guidelines are for beginners (Score:5, Insightful)
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: (Score:3)
Re:As always, guidelines are for beginners (Score:4, Informative)
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: (Score:3)
Re: (Score:3)
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:
;
... supported by certain languages, not a pattern.
strcpy(char* dest, char* src) {
while (*dest++ = *src++)
}
is an idiom
Re:As always, guidelines are for beginners (Score:4, Insightful)
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: (Score:3)
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: (Score:2)
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 sti
Re: (Score:2)
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: (Score:2)
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 n
Re: (Score:2)
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 kee
Re: (Score:2)
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 re
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
Huh?
Are you complaining that a set of coding guidelines isn't a new language standard?
Re: (Score:3)
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 (Score:3)
News at eleven (Score:3, Informative)
Imperative programmers reinvent functional programming concepts, but in a shitty way. More at eleven.
Re: (Score:2, Troll)
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.
Bjarne should not be writing that (Score:4, Insightful)
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.
What instead of an exception? (Score:3)
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: (Score:3)
Re: (Score:2)
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 cle
Re: What instead of an exception? (Score:2)
Re: (Score:2)
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: (Score:2)
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? (Score:4, Informative)
Every object that can be thrown/caught must implement the Throwable interface
Then have all exceptions extend a subclass of std::exception [stackoverflow.com]. The guidelines mention use of a subclass [github.com] 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 [github.com] is ultimately an update of a method described in a 2000 article by Andrei Alexandrescu in Dr. Dobb's [drdobbs.com].
Re: (Score:2)
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 des
Re: (Score:2)
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 th
Checked exceptions as API (Score:2)
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 plausibl
Should file not found always be a fatal error? (Score:2)
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? (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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
in
You just created a TOCTTOU race bug (Score:3)
Congratulations: You just created a time of check to time of use (TOCTTOU) race bug [wikipedia.org]. 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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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: (Score:3)
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.
Exceptions are TOCTTOU safe (Score:2)
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 [stackoverflow.com] 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." H
Allowing inconsistent objects to exist (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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: (Score:3)
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 dea
Re: (Score:3)
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
Cost of safety (Score:3)
Ada had this in 1995 (Score:4, Informative)
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: (Score:2)
Yo mama!
Re: (Score:3)
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: (Score:3)
> 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 recomm
Re: (Score:2)
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: (Score:3)
> 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: [stroustrup.com]
Re: (Score:3)
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
Re: (Score:3)
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
Re:Ada had this in 1995 (Score:5, Interesting)
"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 (Score:5, Informative)
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.
Sad, really (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
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: (Score:3)
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: (Score:2)
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.
The liberator and the wise crack. (Score:2)
"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.
It's pointers all the way down, jake ! (Score:2)
Re: (Score:3)
Re: (Score:2)
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
Re: (Score:3)
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 interest
Re: (Score:2)
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 ca
Re: (Score:2)
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: (Score:2)
Nothing really came from it, AFAIK. Alas, alas...
Re: (Score:3, Funny)
"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: (Score:2)
Re: (Score:2)
Safe but you have to pay a lot of attention to not make it accidentally unsafe, thus.. sort of safe?
Re: (Score:2)
Safe as houses, safe as fuck!
Re: (Score:2)
It will give you code so secure that it can even order some fruity cocktails with those little umbrellas!
Re: (Score:2)
If you had written it in C++ instead of BASIC it wouldn't be offtopic.
Re: (Score:2)
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
Re:Instrumenting c++ to behave like Rust (Score:5, Informative)
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: (Score:3)
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?
Re:Instrumenting c++ to behave like Rust (Score:4, Insightful)
Seasoned professionals have given us decades worth of mostly unnecessary buffer overflows.