With proper C++ style, you don't really do much with destructors.
Um, whenever you have a class that needs to commit something using, say, I/O before the object is destroyed, you rely on your clients to call the explicit method for that and get their proper error reporting, otherwise you do it in the destructor wrapped in an ugly catch-all block. Usage of badly designed language features makes you remember all these nasty little things...
In my current code base there's only a single line of code that is used to free all resources across all classes, and that one line is solidly reviewed and tested.
Bullshit. That line exploits static or dynamic polymorphism, and all the implementations used by it need to be reviewed and tested. By the way, every implicit code path that can be taken by a raised exception needs to be tested too.
Good C++ code looks much like good code in a garbage-colected language - your program logic isn't cluttered with bookkeeping. In fact, that to me is the worst part of well-written C code - every damn function call must be followed by an error check and branch to clean-up code on error. The needed ritual error checking is more lines of code than the actual program logic.
Yeah, that's why we use Vala these days. You don't know how liberating it is to use a real object-oriented language that is still close enough to the metal.
Also, there's no particular cost with auto_ptr, not sure what you think it does beyond call the destructor of the class it points to when it is itself destroyed.
But, but, auto_ptr sucks and is deprecated by all RAII gurus whose revenue from C++ trick books is anything worth talking about!
Well, don't let me stop you from typing C code into cpp files, but please stop calling that code C++ - it gives the language a bad reputation.
Of course I don't use plain C code in C++ files. But very often I need to supply callbacks to some C library (no, not all useful code in the world is written by C++ RAII hotshots), and I like to implement them without having to wrap everything in a catch-all block or suffer memory leaks or worse. I'll agree on calling it "Qt style code" and accept all the stigma associated with it;)
Sorry, but you're just wrong. That was a reasonable argument to make 15 years ago, but not today.
Today, as then, you still have to ensure that no destructor throws exceptions. And with excellent obfuscation properties of C++, it's not a task that a human can be relied upon to perform well. I once asked a couple of C++ fanboys to tell me what an innocuously looking 20 LOC code example would do, and they both failed.
RAII is not some workaround, it was the intent of the language from the earliest days. Good C code never exits from the middle of a function, and control always paases through clean-up code at the end of every function. This is fundamentally human-error prone.
Cool, but don't force me to use a costly smart pointer for each data member that wants to be a pointer. I can free my owned objects in a destructor myself, thank you. Also, classes like tr1::shared_ptr are designed for casting convenience in assignments and constructors (otherwise they'd suck), which makes them problematic to use in method signatures together with overloading. Discipline required again. But people rather tend to use plain pointers or references in method signatures, which defeats the purpose of shared pointers (but helps to keep the mangled symbol names to be less than a mile long, and makes reading compiler error messages less of a hair-pulling experience).
Believe me, I understand that C++ exceptions suck if you're typing C code into a.cpp file so never do that. C++ is a different mindset.
No mindset change needed for me: I use Qt and implement exception safety by use of compiler flag -fno-exceptions. Makes usage of C callbacks a breeze, too. I also use -fno-rtti to prevent even accidental usage of another C++ feature that is broken by design, and indicates a code design problem in most cases anyway.
Ah, sorry for misreading. That could work indeed. It should even be doable with the current ELF, as it has symbol tags already.
But still, redundant code emissions are a lousy solution, resulting in code image bloat and more porous cache utilization at runtime. There is also RTTI, which is either slow or broken across DSO boundaries.
Oh yes, ODR violations on templates can appear in very non-obvious circumstances, and be insanely hard to debug. Why the compilers still don't do proper checking at link time (to see that all instantiations match per ODR rules; can be as simple as hashing the original tokens and storing that in the object file to compare) is beyond my understanding.
Perhaps because, by doing that, they would essentially make any compiler options affecting code generation matter for the ABI, and this would make linkage intolerably fragile.
(I'm also working on a large C++ project now where basically everything is a smart pointer, and I'm not sure what "library-provided helpers" we're contorting ourselves "over every pointer assignment". I hesitate to bring this up because this is a research project and we're probably about as safe from exceptions as a water balloon is safe from a pin,
You highlight the issue yourself: nobody in practice attains exception safety in C++. Even if you tried, any library that you use has to be exception-safe as well, and few of them are. This includes all C code: if you use callbacks from C to C++, you have to have a try-catch block in your callback to catch anything that the C++ code might be throwing. No wonder that so many projects disable exception handling or discourage it in their coding guidelines.
RAII is a good pattern for resource management, and smart pointers have their place. But "exception safety" is a false goal.
Defining an ABI for C++ is hard, because language features were added without much consideration to what would it require at the linkage level, especially with dynamic linking. The whole idea of sticking to the C linkage model while piling up features that required generation of vaguely located code, was broken to begin with. I had some good fun investigating weak linkage problems when somebody decided to unload a dynamic module. We found around three dosen emissions of one commonly used template-instantiated function in various shared libraries and modules. God help you if some emitted definitions for a weak symbol end up incompatible for some reason.
(I happen to think that exceptions are a good idea too, but am much less... certain of that position than some of my others. I also haven't seen a language that I think gets exception safety in a substantially better way than C++ does.)
Look at any managed runtime environment with garbage collection. This is where exception handling actually works without the need for the developers to contort themselves with library-provided helpers over every pointer assignment, and ensure that no destructor can throw exceptions.
Well, variable declared at the top of the function are the least evil c-ism. The real problem is a lack of understanding of RAII, and a fear of exceptions. The last time I read Googles C++ coding standards I died a little inside.
It's not necessarily fear. C++ exceptions create far more problems than they solve. I understand the usefulness of RAII as a general pattern, but mandating it everywhere as a way to solve language design problems is ludicrous.
People just don't "get" C++ for some reason.
It may be also that some people get it well enough to know what to avoid.
The introduction of operator overloading was basically the point after which the complexity of C++ exploded. It brought in the nightmarish overload resolution rules. It was a cause for bolting exceptions onto an unmanaged runtime environment, since how do you report errors in a function that has to have just the right signature to act like an operator? This invited the overarching concept of "exception safety" which is unheard of in sanely designed languages, outside of cases where an explicitly managed system resource needs to be released.
I hope by RAII you mean the general pattern of freeing allocated resources in the destructor of the object that owns them, and not the obligation to wrap everything with smart pointers and similar gunk in order to attain "exception safety". Because the latter is entirely self-inflicted by the language design.
and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)
If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.
In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.
If you want to read assembly for your target architecture but cannot understand what it does, how is it the C compiler's problem? It does what you ask it to do.
Some additions are long overdue, but boy is the syntax ugly. I guess there are only so many neat ways to hack the parser for the already overcomplicated language.
And of course, Boost demonstrates everything that is wrong with the C++ mainstream these days, including extreme template bloat and failure to address the existence of shared libraries. For practical programming, I'd recommend C++-by-Qt and Vala.
Which was inspired by The Stranger written by Albert Camus. Apropos to the topic, Robert Smith was compelled to bowdlerize this song for later performances.
I've certainly seen this discussed among my Russian social peers, with the general mood of "Americans are letting political correctness eat away their minds". One of my contacts living in America has posted a poll. Interestingly, the Russian translation of Huckleberry Finn loses almost all the degrading verbal context: "negr" is not an offensive word, and "injun" got flattened into "Indian". In Russia, Huckleberry Finn is a very popular book for children, even though I found it considerably more "adult" compared to the adventures of Tom Sawyer. And I still think it's one of the best anti-racist books ever written.
No it's not specific to AA. I've flown SW, KLM-Delta(and delta before the merger), JetBlue, AirTran all in the last 2 years and they've all done the same thing.
This must be specific to America. On all flights I've flown across Europe, they switch the seatbelt sign off and on as appropriate to the situation. My flight with KLM Cityhopper was no different.
Perhaps there was a global average dip, but it was less than the European records show.
And then, even if we are up for a lucky solar break, this does not mean that in the few decades (or years, no one can tell) the problem will not return with a vengeance.
It's less severe a variance than the Maunder or Dalton minima. Those were natural variations, no?
Those were, but this time it's not natural as far as most scientists with expertise relevant to the problem are concerned. BTW, the Little Ice Age appears to be more of a Northern Hemisphere thing, so the Maunder minimum was not likely the largest contributor. The current warming, by contrast, is truly global.
"Oh, the Earth warmed a bit in the past century." "Yeah - what else were you expecting?"
Some warming agreeable to the geological scale of what you are trying to suggest as happening, please. The current trend is out of all proportion to that, sadly.
IPCC is complied works by half a dozen people, not all of which are scientists.
Yeah, everything that IPCC has ever produced or referenced has been personally created by these half a dozen people.
The works are cherry picked and later found to be full of errors.
Right, the latest report was found to contain something like three errors on relatively minor issues in the less comprehensively scientific chapters, all of which duly received a title of "-gate" from the sensationalist media and teh b(l)ogosphere.
Most studies out there arent about the effects of CO2 on global temperatures (some are) but most are about the potential effects if such warming occured. Or dirivative works on different subjects with GW splashed in for funding.
Unwillingness to learn about the subject, rather than reproduce popular rhetoric you agree with: check Unwillingness to use proper spelling: check
This constant claim that 5000 scientists are working in unison and all agree on the same exact data and subject is ludicrous and a lie.
Nice strawman. The scientists, of course, do not "work in unison" and agree on everything exactly. Still, the consensus on anthropogenic global warming is there, whether you like it or not.
How many perps? Well "The Met said among the 2,512 suspects caught this year, four were suspected murderers, 23 rapists and sex attackers and five wanted gunmen.". That adds up to 32 to me...
So, nobody is worried about thieves and robbers any more?
If I'd been providing Linux apps I could have just dropped into the installer the version of the library I linked against, about the only libraries you can do that with on Windows are the MSVC++ runtimes.
It's good that you are not "providing Linux apps", because library drop-ins have always been a wrong solution to the problem. Versioned sonames have been used in Linux long before Microsoft felt the need to provide a clunky solution to much the same problem with SxS, and then there are versioned ELF symbols to make the DLL hell even less of a problem. Then, "Linux" is not a target platform for installing, distributions are, and they do usually provide some regularity in API changes. And what is this "installer" you are talking about, some crappy substitution for a package manager?
Really? I thought the difference between Requires and PreReq is only in the installation order. Other dependency types, like Obsoletes, Conflicts, and so on, have their.deb equivalents. Actually, the existence of apt-rpm proves that there is no principal difference between the two packaging systems; apt works exactly the same way on top of both.
Slashdot Mirror
With proper C++ style, you don't really do much with destructors.
Um, whenever you have a class that needs to commit something using, say, I/O before the object is destroyed, you rely on your clients to call the explicit method for that and get their proper error reporting, otherwise you do it in the destructor wrapped in an ugly catch-all block. Usage of badly designed language features makes you remember all these nasty little things...
In my current code base there's only a single line of code that is used to free all resources across all classes, and that one line is solidly reviewed and tested.
Bullshit. That line exploits static or dynamic polymorphism, and all the implementations used by it need to be reviewed and tested.
By the way, every implicit code path that can be taken by a raised exception needs to be tested too.
Good C++ code looks much like good code in a garbage-colected language - your program logic isn't cluttered with bookkeeping. In fact, that to me is the worst part of well-written C code - every damn function call must be followed by an error check and branch to clean-up code on error. The needed ritual error checking is more lines of code than the actual program logic.
Yeah, that's why we use Vala these days. You don't know how liberating it is to use a real object-oriented language that is still close enough to the metal.
Also, there's no particular cost with auto_ptr, not sure what you think it does beyond call the destructor of the class it points to when it is itself destroyed.
But, but, auto_ptr sucks and is deprecated by all RAII gurus whose revenue from C++ trick books is anything worth talking about!
Well, don't let me stop you from typing C code into cpp files, but please stop calling that code C++ - it gives the language a bad reputation.
Of course I don't use plain C code in C++ files. But very often I need to supply callbacks to some C library (no, not all useful code in the world is written by C++ RAII hotshots), and I like to implement them without having to wrap everything in a catch-all block or suffer memory leaks or worse. I'll agree on calling it "Qt style code" and accept all the stigma associated with it ;)
Sorry, but you're just wrong. That was a reasonable argument to make 15 years ago, but not today.
Today, as then, you still have to ensure that no destructor throws exceptions. And with excellent obfuscation properties of C++, it's not a task that a human can be relied upon to perform well. I once asked a couple of C++ fanboys to tell me what an innocuously looking 20 LOC code example would do, and they both failed.
RAII is not some workaround, it was the intent of the language from the earliest days. Good C code never exits from the middle of a function, and control always paases through clean-up code at the end of every function. This is fundamentally human-error prone.
Cool, but don't force me to use a costly smart pointer for each data member that wants to be a pointer. I can free my owned objects in a destructor myself, thank you. Also, classes like tr1::shared_ptr are designed for casting convenience in assignments and constructors (otherwise they'd suck), which makes them problematic to use in method signatures together with overloading. Discipline required again. But people rather tend to use plain pointers or references in method signatures, which defeats the purpose of shared pointers (but helps to keep the mangled symbol names to be less than a mile long, and makes reading compiler error messages less of a hair-pulling experience).
Believe me, I understand that C++ exceptions suck if you're typing C code into a .cpp file so never do that. C++ is a different mindset.
No mindset change needed for me: I use Qt and implement exception safety by use of compiler flag -fno-exceptions. Makes usage of C callbacks a breeze, too. I also use -fno-rtti to prevent even accidental usage of another C++ feature that is broken by design, and indicates a code design problem in most cases anyway.
Ah, sorry for misreading. That could work indeed.
It should even be doable with the current ELF, as it has symbol tags already.
But still, redundant code emissions are a lousy solution, resulting in code image bloat and more porous cache utilization at runtime. There is also RTTI, which is either slow or broken across DSO boundaries.
Oh yes, ODR violations on templates can appear in very non-obvious circumstances, and be insanely hard to debug. Why the compilers still don't do proper checking at link time (to see that all instantiations match per ODR rules; can be as simple as hashing the original tokens and storing that in the object file to compare) is beyond my understanding.
Perhaps because, by doing that, they would essentially make any compiler options affecting code generation matter for the ABI, and this would make linkage intolerably fragile.
(I'm also working on a large C++ project now where basically everything is a smart pointer, and I'm not sure what "library-provided helpers" we're contorting ourselves "over every pointer assignment". I hesitate to bring this up because this is a research project and we're probably about as safe from exceptions as a water balloon is safe from a pin,
You highlight the issue yourself: nobody in practice attains exception safety in C++. Even if you tried, any library that you use has to be exception-safe as well, and few of them are. This includes all C code: if you use callbacks from C to C++, you have to have a try-catch block in your callback to catch anything that the C++ code might be throwing. No wonder that so many projects disable exception handling or discourage it in their coding guidelines.
RAII is a good pattern for resource management, and smart pointers have their place. But "exception safety" is a false goal.
Defining an ABI for C++ is hard, because language features were added without much consideration to what would it require at the linkage level, especially with dynamic linking. The whole idea of sticking to the C linkage model while piling up features that required generation of vaguely located code, was broken to begin with. I had some good fun investigating weak linkage problems when somebody decided to unload a dynamic module. We found around three dosen emissions of one commonly used template-instantiated function in various shared libraries and modules. God help you if some emitted definitions for a weak symbol end up incompatible for some reason.
(I happen to think that exceptions are a good idea too, but am much less... certain of that position than some of my others. I also haven't seen a language that I think gets exception safety in a substantially better way than C++ does.)
Look at any managed runtime environment with garbage collection. This is where exception handling actually works without the need for the developers to contort themselves with library-provided helpers over every pointer assignment, and ensure that no destructor can throw exceptions.
Well, variable declared at the top of the function are the least evil c-ism. The real problem is a lack of understanding of RAII, and a fear of exceptions. The last time I read Googles C++ coding standards I died a little inside.
It's not necessarily fear. C++ exceptions create far more problems than they solve. I understand the usefulness of RAII as a general pattern, but mandating it everywhere as a way to solve language design problems is ludicrous.
People just don't "get" C++ for some reason.
It may be also that some people get it well enough to know what to avoid.
The introduction of operator overloading was basically the point after which the complexity of C++ exploded. It brought in the nightmarish overload resolution rules. It was a cause for bolting exceptions onto an unmanaged runtime environment, since how do you report errors in a function that has to have just the right signature to act like an operator? This invited the overarching concept of "exception safety" which is unheard of in sanely designed languages, outside of cases where an explicitly managed system resource needs to be released.
RAII alone is enough to seal that deal.
I hope by RAII you mean the general pattern of freeing allocated resources in the destructor of the object that owns them, and not the obligation to wrap everything with smart pointers and similar gunk in order to attain "exception safety". Because the latter is entirely self-inflicted by the language design.
and compile with optimization on. Look at the resulting assembly. There's no branch! (I'm assuming a variant of x86 or x64 here.)
If you're on a 64-bit system with GCC you'll probably see a cmov (conditional move) instruction, which kind of makes sense. But you don't even need that instruction to be available for it to omit an actual control-flow jump. Recompile with -m32 and look at the assembly again. Much longer, but still no branch. Instead, it uses one of the setxx instructions (setg in my case) and a bit of bit twiddling.
In my opinion, today's optimizers make the generated code so far removed from what you type into your editor that saying "+ can do anything!" is a drop in the bucket.
If you want to read assembly for your target architecture but cannot understand what it does, how is it the C compiler's problem? It does what you ask it to do.
Some additions are long overdue, but boy is the syntax ugly. I guess there are only so many neat ways to hack the parser for the already overcomplicated language.
And of course, Boost demonstrates everything that is wrong with the C++ mainstream these days, including extreme template bloat and failure to address the existence of shared libraries. For practical programming, I'd recommend C++-by-Qt and Vala.
Me, I just shrugged.
Sounds like The Cure's song, "Killing an Arab".
Which was inspired by The Stranger written by Albert Camus.
Apropos to the topic, Robert Smith was compelled to bowdlerize this song for later performances.
I've certainly seen this discussed among my Russian social peers, with the general mood of "Americans are letting political correctness eat away their minds". One of my contacts living in America has posted a poll. Interestingly, the Russian translation of Huckleberry Finn loses almost all the degrading verbal context: "negr" is not an offensive word, and "injun" got flattened into "Indian". In Russia, Huckleberry Finn is a very popular book for children, even though I found it considerably more "adult" compared to the adventures of Tom Sawyer. And I still think it's one of the best anti-racist books ever written.
No it's not specific to AA. I've flown SW, KLM-Delta(and delta before the merger), JetBlue, AirTran all in the last 2 years and they've all done the same thing.
This must be specific to America. On all flights I've flown across Europe, they switch the seatbelt sign off and on as appropriate to the situation. My flight with KLM Cityhopper was no different.
+1
Moreover, shouldn't January 1 be a public holiday or something, like it is here in the lazy-ass Europe?
Perhaps there was a global average dip, but it was less than the European records show.
And then, even if we are up for a lucky solar break, this does not mean that in the few decades (or years, no one can tell) the problem will not return with a vengeance.
It's less severe a variance than the Maunder or Dalton minima. Those were natural variations, no?
Those were, but this time it's not natural as far as most scientists with expertise relevant to the problem are concerned. BTW, the Little Ice Age appears to be more of a Northern Hemisphere thing, so the Maunder minimum was not likely the largest contributor. The current warming, by contrast, is truly global.
"Oh, the Earth warmed a bit in the past century."
"Yeah - what else were you expecting?"
Some warming agreeable to the geological scale of what you are trying to suggest as happening, please.
The current trend is out of all proportion to that, sadly.
Why, this sort of informed opinion is common among... computer scientists.
IPCC is complied works by half a dozen people, not all of which are scientists.
Yeah, everything that IPCC has ever produced or referenced has been personally created by these half a dozen people.
The works are cherry picked and later found to be full of errors.
Right, the latest report was found to contain something like three errors on relatively minor issues in the less comprehensively scientific chapters, all of which duly received a title of "-gate" from the sensationalist media and teh b(l)ogosphere.
Most studies out there arent about the effects of CO2 on global temperatures (some are) but most are about the potential effects if such warming occured. Or dirivative works on different subjects with GW splashed in for funding.
Unwillingness to learn about the subject, rather than reproduce popular rhetoric you agree with: check
Unwillingness to use proper spelling: check
This constant claim that 5000 scientists are working in unison and all agree on the same exact data and subject is ludicrous and a lie.
Nice strawman. The scientists, of course, do not "work in unison" and agree on everything exactly. Still, the consensus on anthropogenic global warming is there, whether you like it or not.
How many perps? Well "The Met said among the 2,512 suspects caught this year, four were suspected murderers, 23 rapists and sex attackers and five wanted gunmen.". That adds up to 32 to me...
So, nobody is worried about thieves and robbers any more?
It also helped that the insurgents mostly belonged to a minority (Chinese) that the rest of the local population did not largely identify with.
If I'd been providing Linux apps I could have just dropped into the installer the version of the library I linked against, about the only libraries you can do that with on Windows are the MSVC++ runtimes.
It's good that you are not "providing Linux apps", because library drop-ins have always been a wrong solution to the problem. Versioned sonames have been used in Linux long before Microsoft felt the need to provide a clunky solution to much the same problem with SxS, and then there are versioned ELF symbols to make the DLL hell even less of a problem. Then, "Linux" is not a target platform for installing, distributions are, and they do usually provide some regularity in API changes. And what is this "installer" you are talking about, some crappy substitution for a package manager?
Really? I thought the difference between Requires and PreReq is only in the installation order. .deb equivalents. Actually, the existence of apt-rpm proves that there is no principal difference between the two packaging systems; apt works exactly the same way on top of both.
Other dependency types, like Obsoletes, Conflicts, and so on, have their