C++ on Steroids: Bjarne Stroustrup Presents Guideline-Enforcing 'Profiles' For Resource and Type Safety (acm.org) 71
"It is now 45+ years since C++ was first conceived," writes 74-year-old C++ creator Bjarne Stroustrup in an article this week for Communications of the ACM. But he complains that many developers "use C++ as if it was still the previous millennium," in an article titled 21st Century C++ that promises "the key concepts on which performant, type safe, and flexible C++ software can be built: resource management, life-time management, error-handling, modularity, and generic programming...
"At the end, I present ways to ensure that code is contemporary, rather than relying on outdated, unsafe, and hard-to-maintain techniques: guidelines and profiles." To help developers focus on effective use of contemporary C++ and avoid outdated "dark corners" of the language, sets of guidelines have been developed. Here I focus on the C++ Core guidelines that I consider the most ambitious... My principal aim is a type-safe and resource-safe use of ISO standard C++. That is:
- Every object is exclusively used according to its definition
- No resource is leaked
This encompasses what people refer to as memory safety and much more. It is not a new goal for C++. Obviously, it cannot be achieved for every use of C++, but by now we have years of experience showing that it can be done for modern code, though so far enforcement has been incomplete... When thinking about C++, it is important to remember that C++ is not just a language but part of an ecosystem consisting of implementations, libraries, tools, teaching, and more.
WG21 (and others) are working on "profiles" to enforce guidelines (though they're "not yet available, except for experimental and partial versions"). But Stroustrup writes that the C++ Core Guidelines "use a strategy known as subset-of-superset." First: extend the language with a few library abstractions: use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).
Next: subset: ban the use of low-level, inefficient, and error-prone features.
What we get is "C++ on steroids": Something simple, safe, flexible, and fast; rather than an impoverished subset or something relying on massive run-time checking. Nor do we create a language with novel and/or incompatible features. The result is 100% ISO standard C++. Messy, dangerous, low-level features can still be enabled and used when needed.
Stroustrup writes that the C++ Core Guidelines focus on rules "we hope that everyone eventually could benefit from."
"At the end, I present ways to ensure that code is contemporary, rather than relying on outdated, unsafe, and hard-to-maintain techniques: guidelines and profiles." To help developers focus on effective use of contemporary C++ and avoid outdated "dark corners" of the language, sets of guidelines have been developed. Here I focus on the C++ Core guidelines that I consider the most ambitious... My principal aim is a type-safe and resource-safe use of ISO standard C++. That is:
- Every object is exclusively used according to its definition
- No resource is leaked
This encompasses what people refer to as memory safety and much more. It is not a new goal for C++. Obviously, it cannot be achieved for every use of C++, but by now we have years of experience showing that it can be done for modern code, though so far enforcement has been incomplete... When thinking about C++, it is important to remember that C++ is not just a language but part of an ecosystem consisting of implementations, libraries, tools, teaching, and more.
WG21 (and others) are working on "profiles" to enforce guidelines (though they're "not yet available, except for experimental and partial versions"). But Stroustrup writes that the C++ Core Guidelines "use a strategy known as subset-of-superset." First: extend the language with a few library abstractions: use parts of the standard library and add a tiny library to make use of the guidelines convenient and efficient (the Guidelines Support Library, GSL).
Next: subset: ban the use of low-level, inefficient, and error-prone features.
What we get is "C++ on steroids": Something simple, safe, flexible, and fast; rather than an impoverished subset or something relying on massive run-time checking. Nor do we create a language with novel and/or incompatible features. The result is 100% ISO standard C++. Messy, dangerous, low-level features can still be enabled and used when needed.
Stroustrup writes that the C++ Core Guidelines focus on rules "we hope that everyone eventually could benefit from."
- No uninitialized variables
- No range or nullptr violations
- No resource leaks
- No dangling pointers
- No type violations
- No invalidation
Bjarne Stroustrup answered questions from Slashdot readers in 2014...
Common Lisp (Score:2)
Could have started with Common Lisp, and use an implementation like SBCL for speed.
But every language needs to evolve in its own pace, getting features that Common Lisp already had decades ago. And then call them new. Oh, and not so properly implemented as in Common Lisp.
Re: (Score:2)
Not really. LISP is gc'd so it's not a replacement for C++. Nothing wrong with GC per se, but it's a quite different set of tradeoffs.
As for the features, LISP isn't so much a language as a language construction toolkit. One doesn't write in LISP, one makes a language in LISP then writes in that language. There's value in having common ground (e.g. compiler provided loops) so that mostly people use the same thing. Likewise a nontrivial amount of C++ is codifying what people do in C so it's the same every ti
Re: (Score:2)
How do you implement a language in LISP that does not look like LISP?
Re: (Score:2)
How do you implement a language in LISP that does not look like LISP?
The same way that you implement a language that does look like Common Lisp: macros, specifically reader macros.
Re: (Score:2)
In uni we used lisp (scheme actually) as a tool for learning about languages and lambda calculus and over the course of the semester implemented a pascal like language. We used macros to transform regular lisp syntax into essentially a domain specific language that looked nothing like lisp but ran under the lisp interpreter. Very powerful stuff and I've always had a soft spot in my heart for lisp-like languages because of how they can do that sort of thing.
Re: (Score:2)
Wow, sounds cool. :-(
We did Lisp, too.
But never jumped out of the Lisp box, aka the ( and ) maze.
Garbage in, garbage out. (Score:3, Interesting)
People who learn C++, or any language actually, learn from outdated and oversimplified tutorials that they find all over the Internet. You know what I'm talking about. We've all come across them. Tutorials that cover the bare fundamental. Often in incorrect way. The sort of courses you see on virtually every money-grab online teaching platform. Quantity and profit over quality.
Unless we weed out the old content (which would be very difficult to do) and direct people to learning materials featuring modern C++, we will never solve this problem.
Re:Garbage in, garbage out. (Score:4, Insightful)
There's three problems in play:
1. C, is the language everything needs to speak. C does not enforce any safety features. That is a feature, not a bug, because C is at it's core just representative of how the underlying processor works (eg the CPU knows nothing of classes, locally scoped variables, overloads, etc) but "types" exist in the CPU because the CPU excluvely talks in 8, 16, 26 or 64 bit numbers. Strings are just data that gets loaded into ram and are largely manipulated by library functions which is why a C string and a C++ string are completely different, moronic, animals. A lot of type checking means you lose a lot of speed.
2. C++ developers are "morons" in the sense that people have been making different flavors of the language since it's inception trying to depreciate out functionality (which includes Microsoft) in favor of flavor-of-the-week methodology. So instead of having a C++ that can be compiled on 8-bit and 16-bit computers, you now push them away and say "go develop in C99, C++ is only for 64-bit bigboy CPU's with GB's of RAM" That to me is a mistake. Never depreciate functionality out of your language. That is how you rot the language from within. If there comes along a new way of doing something, make that an extension of the language's standard library instead of trying to rename old function names into new ones. Nothing wrong with having a hidden prefixing mechanism to map CPP20's fprintf over top of CPP03's fprintf. You just declare in your source code files that this function is intended for CPP20 and the compiler then applies a macro if the target runtime is CPP03, or the thing it's being compiled against is CPP03. You don't remove the functionality. EVER. If it comes down to mixing CPP20 and CPP03 functions, you map one to the other, and if someone is insistent on using bleeding edge CPP23 when the compiler doesn't even know what it is, then it know's it's a "unknown CPP" and tries to map the functionality to it's version of CPP.
If you develop a fancy new way of dealing with strings, then you make that something that can be accessed as a library (see BOOST) rather than breaking decades of code by changing the compiler.
3. C and C++ must co-exist, which is why functionality that "depreciates C" functionality can not be replaced with new C++ versions nor new C versions. It must behave as intended in C in order for it to communicate with other libraries that speak C.
Every time I see people whine-bitch-moan about "old programming styles", what I'm really hearing is "old, efficient styles that got things done without needing layers of crufty frameworks and libraries duplicating functionality that already existed in C."
If you want people to use new type safety in C++, then you need to give them a reason to. That often means it comes at a performance cost.
Re: (Score:3)
Never depreciate functionality out of your language. That is how you rot the language from within.
And that is exactly why C++ is such a mess. There are too many ways to do the same thing.
If you want people to use new type safety in C++, then you need to give them a reason to.
They do have a reason to, but there are plenty of reasons why code is not updated and not always because of their own inaction.
If C++ removed all the old stuff I think could appreciate the language more (like Rust), but for me C is still the best because it's simple and it's well known how to use it in the best way possible. It's a stable tool and that's why its few flaws and pitfalls can be forgiven, although a modern
Re: Garbage in, garbage out. (Score:3)
That's exactly the web. It just might be a crime to tell someone they can't push their vision of framework just because it ignores any existing system principles.
Re: (Score:3)
> If C++ removed all the old stuff
It can't. That's one of the C++ premises: code written correctly will always compile with future versions.
Hell the reflection syntax got ugly-ish because of compatibility issues with Apple's Obj-C. This is what I like about C++: it doesn't assume it exists in a silo.
Re: (Score:2)
Sometimes the unoptimized 30 second result that can be finished in weeks is better than the
Re: (Score:2)
Precisely. This principle also favors higher-level, safer languages for most coding, where speed of development is more important than raw processing speed. These newer languages eliminate whole classes of bugs, such as referencing unallocated memory, because it's literally impossible to do so. If your application *must* have the raw speed that a lower-level language can provide, then you *should* take the additional time and effort to do it right. And in most cases, you could instead spend that additional
Re:Garbage in, garbage out. (Score:5, Informative)
That is a feature, not a bug, because C is at it's core just representative of how the underlying processor works (eg the CPU knows nothing of classes, locally scoped variables, overloads, etc)
C has locally scoped variables, and the CPU does know about them inasmuch as most CPUs have a hardware stack.
because the CPU excluvely talks in 8, 16, 26 or 64 bit numbers.
Also 128, 256 and 512 bit collections, and also 80 bit for x86, though it won't do much except FPU operations on the latter.
A lot of type checking means you lose a lot of speed.
Type checking is done at compile time and eliminated by the time CPU instructions are emitted. Try some code on godbolt (actually the dude's name, sound like something Yaweh uses for smiting) and see the asm for yourself.
C++ developers are "morons" in the sense that people have been making different flavors of the language since it's inception trying to depreciate out functionality
Very very little has been deprecated.
So instead of having a C++ that can be compiled on 8-bit and 16-bit computers, you now push them away and say "go develop in C99, C++ is only for 64-bit bigboy CPU's with GB's of RAM"
You can compile draft C++26 on to an 8 bit ATtiny85 with its 512 bytes of RAM just fine.
3. C and C++ must co-exist,
There's a WG21/WG14 liason committee, and the compiler writers are pretty dedicated to that job.
Every time I see people whine-bitch-moan about "old programming styles", what I'm really hearing is "old, efficient styles that got things done without needing layers of crufty frameworks and libraries duplicating functionality that already existed in C."
You need to get your hearing tested. Writing malloc() and free() by hand has little utility over using unique_ptr except for the ability to screw up.
That often means it comes at a performance cost.
Famously C++'s std::sort (type safe) is much faster than C's void* based qsort.
Re: (Score:2)
Ob: "C++ is to C as Lung Cancer is to Lung."
Re: (Score:2)
If you want people to use new type safety in C++, then you need to give them a reason to. That often means it comes at a performance cost.
No it does not.
That is the prime design principle of C++
And that is why it is so ambiguously viewed at.
The rest of your rant is mostly wrong, too.
Re: (Score:2)
> If you want people to use new type safety in C++, then you need to give them a reason to. That often means it comes at a performance cost.
It really doesn't in any non-HPC contexts. Google did it, their perf cost is 0.3%
source: https://security.googleblog.co... [googleblog.com]
And this is hardened STL, meaning it has enabled checks where not mandated by the spec.
> If it comes down to mixing CPP20 and CPP03 functions, you map one to the other, and if someone is insistent on using bleeding edge CPP23 when the compiler
Re:Garbage in, garbage out. (Score:5, Informative)
(Fun fact: deprecate [wiktionary.org] and depreciate [wiktionary.org] are different words.)
Re: (Score:2)
With the goal of teaching as little as possible so that an entire generation of programmers do not know how to program but only know libraries produced by others.
Object oriented programming itself has as its goal to convert programming into the equivalent of playing with Legos. The creator said it himself:
"C++ is not just a language but part of an ecosystem consisting of implementations, libraries, tools, teaching, and more."
Yes, and the intention is that programmers know the language enough to glue togeth
Then why C++ at all? (Score:5, Interesting)
"...ensure that code is contemporary, rather than relying on outdated, unsafe, and hard-to-maintain techniques: guidelines and profiles..."
Increasingly, "outdated" is the most reliable sign that code may be good and "unsafe and hard-to-maintain techniques" are what programmers want and what tie them to C/C++ in the first place. Finally, what are "guidelines and profiles" in this context anyway? The idea that these terms mean something tells us the shark has already been jumped.
The primary appeal of C++ is that it can transition at any time to pure procedural C. Here, this is asserted as being bad. Fine. Then let's abandon C++ altogether, it's a giant pile of shit that the creator now claims needs to abandon its only redeeming quality. Never forget, the only good thing about C++ is the C part.
Re: (Score:2)
The primary appeal of C++ is that it can transition at any time to pure procedural C.
This is only true for some people. I see C++ as a _better_ C. In my experience, there are very, very few real reasons to fall back to pure C. More often than not, programmers do this because they want to take a shortcut, not because it's actually the better approach.
Re: (Score:2)
Re: (Score:2)
Never forget, the only good thing about C++ is the C part.
I'd say the best thing about C++ is RAII, which AFAIK is not possible in C (obfuscating tricks with macros notwithstanding).
(Templates are a close second, but the usefulness they provide is offset by the complexity and code-bloat that they add)
Guidelines are useless (Score:2)
What C++ needs is strictly enforced usage, optionally by those profiles. This is what Rust is good at (unsafe kayword aside), don't adhere to the safe rules of the language, your code won't compile.
Is a new feature or change in C++ deemed safer, disable the old method at the same time, backwards compatibilty be damned. Only then can you prevent the "wrong" way to code. Leaving it up to a development team to decide the subset of features will end up becoming a vague mess over time.
Sure, it means loads of wor
Re: (Score:2)
I find it interesting that Rust is seen as so "safe," while in reality nobody can write a real-world application without including at least some "unsafe" code. This makes me wonder if Rust's safety is something of an illusion.
Re: (Score:2)
I think that depends on your definition of "real-world".
At hardware level it's no surprise to need unchecked access, but most software has no bearing on access to data which would need unsafe handling, so Rust can be used just as well as anything else.
I'm no fan of the language myself because I find a few flaws and missed opportunities at its core, but so far it does seem more useful than C++ for instance. I just hope it won't drown in added unnecessary features like C++ does.
Re: (Score:2)
While there are possibly use cases that need "unchecked" access, the number is vastly smaller than many would guess.
Consider installers. In the 1990s, it was assumed that installers would always need unchecked access to the OS and the hard drive, because of course, they need to...install things. But Android and iOS proved that installers, with the proper framework, can do everything they need to do, without elevated permissions.
In the same way, most drivers should be able to do what they need to do, without
Re: (Score:2)
I find it interesting that Rust is seen as so "safe," while in reality nobody can write a real-world application without including at least some "unsafe" code.
Even if the above is true (and I'm not convinced that it is), it's still a big advantage to have all the unsafe code segregated into one little area with a big red arrow pointing to it saying, effectively: "is your app crashing? Look here first!".
That's much more efficient to debug than having to consider every line in the codebase as a suspect.
Re: (Score:2)
It only takes one unsafe function, to give hackers a way in.
Re: (Score:2)
It only takes one unsafe function, to give hackers a way in.
Minor correction -- it only takes one buggy unsafe function to give hackers a way in.
Unsafe (the Rust keyword) doesn't mean the function necessarily is buggy, only that the Rust compiler can't guarantee that it will be memory-safe, and therefore it is up to the programmer to make sure that it is -- i.e. it has the same level of safety that any C or C++ function would have.
Re: (Score:2)
There is no such thing as a non-trivial function with no bugs, only functions with no _obvious_ bugs. And if you have to rely on a block of "unsafe" code, your function is by definition, non-trivial.
Re: (Score:2)
There is no such thing as a non-trivial function with no bugs, only functions with no _obvious_ bugs. And if you have to rely on a block of "unsafe" code, your function is by definition, non-trivial.
That's a pretty damning indictment of all C and C++ codebases, as they are made entirely of "unsafe" code. And yet, the world relies on them anyway.
Re: (Score:2)
There is no such thing as a non-trivial function with no bugs, in *any* language.
And this is why no computer, running any OS, is safe from hackers. The Heartbleed vulnerability ran on millions of Linux servers, in plain sight in open source code (OpenSSL), for many years, before it was detected. The Rowhammer attack is arguably not caused by any bug at all, but rather, a physical limitation inherent in the design of computer chips. Anyone who thinks they can write perfectly secure code, is arrogant.
I don't miss C++ (Score:3)
I haven't programmed C++ professionally for years. I was never really that good at it and I really don't miss pointers to pointers. Made my tiny brain ache.
Re: (Score:2)
Like you, I haven't done C++ in years. But I did use the language exclusively for almost a decade, and got quite good at it. But like you, I don't miss all the pointers. With that said, understanding pointers makes me a better C# developer today.
Re: (Score:3)
You understand that every single language has pointers. They just call them references instead, but the behavior is absolutely the same underneath the hood. All the same issues. The only thing you don't have is pointer arithmetic, which should be avoided in C++ as well unless you're in ultra high performance code.
Re: (Score:2)
Of course I understand references, but while references are implemented under the hood as pointers, they are *not* the same.
For one thing, in modern languages, the system automatically keeps track of how many references are still actively "pointing to" the referenced object, and release it automatically when the last reference is gone. C and C++ never did that.
And as for "ultra high performance code," usually, falling back to unsafe code is more of a lazy shortcut to performance, not usually a "good" approa
Re: (Score:2)
They are the same. They both hold an address that points at the object, either directly or indirectly (Java uses a double pointer to allow moving of data). If you don't get pointers, you won't get references. 99.9% of the mistakes you make with pointers are also there with references. If you don't get that, I shudder to think of what your code looks like.
Re: (Score:2)
They're only the same, in the sense that all high-level code is "the same as" low level code.
At some level, adding two numbers in C++, Java, and C# is "the same as" adding two numbers in Assembly. The difference is, the higher level languages handle addition in a more sophisticated way, such as representing a number as positive or negative, instead of just designating a specific bit as the sign bit.
This is the same way that pointers are like references. C# and Java handle references in a more sophisticated
Re:I don't miss C++ (Score:5, Informative)
I work professionally as a C developer for embedded systems and enjoy programming assembly at my spare time, but I learnt C++ for my hobby projects a few years ago, using primarily C++20.
While I feel very comfortable around pointers, I have to defend modern C++ because I don't think I've ever had to use a pointer in C++20 other than perhaps interfacing with "legacy" C APIs. C++21 meta-programming and its library is powerful enough that you can express pretty much everything you want, especially with the move construct so you can tell the compiler what to do with big data.
Templates with the concepts feature and more and more things added to constexpr now makes it easier than ever to deal with serious low-level hardcore optimizations while keeping the code reasonably high-level. IMO as someone who always obsess about those things.
Re: (Score:2)
If you wanted a modern language ... (Score:1)
Re: (Score:2)
Sometimes, when you have a lot of legacy code, migrating to a modern language isn't an option. But migrating from C to C++, usually is.
...on a not-so-modern CPU (Score:2)
Even for new code, there might not be a readily available compiler for a new language that targets an uncommon instruction set. It took a while for LLVM (and therefore Rust) to support m68k and ARMv4T, instruction sets that GCC had long supported. This affects people targeting Amiga, Genesis, and Game Boy Advance.
Re: (Score:2)
Granted. Of course, you've got to use the best tools available for your platform of choice.
C++ Is the Language of Professionals (Score:1)
Re: (Score:1)
Ding! No mod points left...
Re: (Score:2)
Figures that was posted by an AC. You probably just can't deal with Rust's Pronoun Checker, can't stand that Go collects all your garbage for you (only stopping the world occasionally), and that Java has Big Brother there to watch for any accidental infringements of a license for the base of your technology stack.
Re: C++ Is the Language of Professionals (Score:2)
*glances at Kubernetes...*
*glances at Docker...*
*glances at Prometheus...*
*looks at 99% of CNCF projects being written in Golang instead of C++*
Yeah, no. That's like saying that MS Exchange is the only professional option for an email server. The only people that espouse that view are a) people who make their living off of it, and b) people who bought into a)'s myoptic view point.
No XYZ - except when we need them (Score:2)
No uninitialized variables
No range or nullptr violations
No resource leaks
No dangling pointers
No type violations
No invalidation
Except when explicitly needed - and documented with big signs saying "there be dragons here."
Re: (Score:2)
And when they are explicitly needed, it's probably a sign that somebody is taking a dangerous shortcut for the sake of expedience. There's a reason these things are considered bad practices.
Re: (Score:2)
The middle four of those are always straight up errors in a program. I didn't read TFA to find out what "invalidation" refers to in the last one. The number of cases where "uninitialized variable" is useful is almost zero; it usually reflects complex control flow, where an initialization flag has minimal impact.
Re: (Score:1)
The middle four of those [range or nullptr violations, resource leaks, dangling pointers, and type violations] are always straight up errors in a program.
If you are deliberately writing code to be exploited, say, as part of a white-hat training course or red-team/blue-team training scenario, those "errors" may in fact be necessary.
But as far as production code outside of specific situations like training, attack, or other niche/academic scenarios, these should be considered errors and your build environment should prevent them entirely in its default configuration.
Re: (Score:2)
What do you imagine is the point of intentionally writing code to have an exploit that is impossible to write by accident?
Re: (Score:2)
What is a "type violation"? I'm seriously asking what you are referring to because I have not heard of it..
Re: (Score:2)
A type violation is typically a typecast that triggers what C and C++ call undefined behavior. For example, convert a pointer to structure type A to void* and then convert it to a pointer to some "different" type. You don't technically even have to reference the third pointer, the conversion itself is a violation (but the compiler won't necessarily see the original type, so it can't guarantee a diagnostic message saying you are doing something bad).
Arguably, violations of the One Definition Rule [wikipedia.org] are also
Ada/SPARK/Rust Deserves a look (Score:1)
Re: (Score:2)
Rust is more focused on having an inscrutable syntax.
FTFY.
D (language) (Score:2)
I've recently been programming in D, and I really like it. No header files; the compiler just grabs things from other source files as requested. And there's static code that executes at compile time, which lets you do some really cool unit testing as part of the build process.
It's a shame the language doesn't have a larger community.
Re: (Score:2)
Re: (Score:2)
So... (Score:2)
So, Rust without the compiler support?
Yeah, developers fault (Score:1)
Re: Yeah, developers fault (Score:2)
Yup. And I've noticed the same excuse comes up a lot in discussions around agile development.
"Now, some apologists at the time would have said that this is this programmers fault for using it in this way. A timeless argument that is alway wrong. My own view is that the behavior you see a tool being used for is the behavior that tool encourages."
--Gary Burnhardt, "The Death & Birth of JavaScript"
https://www.destroyallsoftware... [destroyallsoftware.com]
Where are the libraries? (Score:2)
C++'s OO Implimentation is Butt Ugly (Score:2)
Literally why Golang was created (Score:3)
C++ has too many features that have been hacked on to it over the years. You can have 4 different programmers write C++ code, and each will look like they're coding in completely different languages. Rob Pike was right. You can't fix C++.
https://commandcenter.blogspot... [blogspot.com]
'Back around September 2007, I was doing some minor but central work on an enormous Google C++ program, one you've all interacted with, and my compilations were taking about 45 minutes on our huge distributed compile cluster. An announcement came around that there was going to be a talk presented by a couple of Google employees serving on the C++ standards committee. They were going to tell us what was coming in C++0x, as it was called at the time. (It's now known as C++11).
In the span of an hour at that talk we heard about something like 35 new features that were being planned. In fact there were many more, but only 35 were described in the talk. Some of the features were minor, of course, but the ones in the talk were at least significant enough to call out. Some were very subtle and hard to understand, like rvalue references, while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals.
At this point I asked myself a question: Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features?'
--Rob Pike
Re: (Score:2)
This just sounds like sour grapes and dickishness. Especially his sign off as the reason C++ programmers don't go to go is because they're fuddy-duddies and go is too awesome. As opposed to you know, go not being a great fit for the problems C++ programmers want to solve.
while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals.
It's very easy to dismiss things as "crazy": then you never need to explain why they're a bad idea. This is especia
KitchenSink++ (Score:2)
Re: (Score:2)
Are you suggesting Stroustrup shouldn't learn anything from how the field of computer science has advanced in the last 45 years?
I mean if you like that and want to code like it's 1970, there's always C and go.