Top-heavy, turning hard, firing a broad-side and a gust of wind all coinciding will cause the ship to heel over and flood through the open gun ports. The Danes had not learned from the Mary Rose 80 years before.
What's all the C Plus Fuss? Bjarne Stroustrup warns of dangerous future plans for his C++
Earlier this year, Bjarne Stroustrup, creator of C++, managing director in the technology division of Morgan Stanley, and a visiting professor of computer science at Columbia University in the US, wrote a letter inviting those overseeing the evolution of the programming language to “Remember the Vasa!” Easy for a Dane to …
COMMENTS
-
-
Monday 18th June 2018 10:22 GMT Steve Crook
Actually, there's more...
The Vasa didn't start out top heavy. Marketing decided they needed new features to keep up with the cutting edge of flagship design.
They were added by reluctant developers while trying to stick within original project schedules and work with a design that wouldn't easily accommodate RFEs. Then marketing added some more. Bigger canons? Yes! More canons? Yes! Another gun deck? Damn right we will!
Familiar, no?
Which is what Stroustrup is warning against.
-
Monday 18th June 2018 10:58 GMT ibmalone
Re: Actually, there's more...
Another interesting aspect of the Vasa disaster is that they did test the ship first, and the sinking could have been avoided. Standard practice was to get a team of sailors to stand on the top deck and run from one side to the other. When they did this to the Vasa it started to rock dangerously. So obviously, the Vasa being too big to fail, the person in charge called off the test. Various people knew there was a problem, but nobody spoke up.
-
Tuesday 19th June 2018 04:35 GMT Dodgy Geezer
Re: Actually, there's more...
It's of interest to know why the Wasa was top heavy, and what happened at the investigation afterwards.
Gustavus Adolphus wanted a big tall ship for fighting, so the shipwrights designed one according to his specs. During the build the designer died, so it was finished off by another, and at that stage was found to be obviously unstable.
But because the king wanted it, no one dared say anything. The ship was completed, launched, fitted out, and capsized on the maiden voyage when she encountered her first gust of wind. The king raved, and set up an inquiry to blame the sailors, the captain - anyone but himself. Eventually they settled on blaming the dead designer, and God....
-
-
Monday 18th June 2018 12:56 GMT SVV
Re: Actually, there's more...
"Which is what Stroustrup is warning against."
Well, Stroustrup has been at the helm of this officer-run ship for rather a long time now, and whilst he may hae been worried that the vessel is endangered by its' own weight and ungainliness, the urgency of pronouncing that the thing is about to sink without trace has been largely msiing until now - previous releases have seen him mainly extolling the virtues of the often mind bogglingly complicated new features. Having to write a "Core C++" manual so that the junior shipmates can fight their way through the confusing architecture just to find the damn wheel is an indication of just how ridicukous the situation haa become.The real danger is not sinking, but that the ship sails on forever getting so full of stuff that all the crew have left without the officers noticing.
The fact that lots more features get added every 2 years means that the current complete spec is incomprehensible to everyone who's not a rabid C++ obsessive. I've been using it as a primary, then secondary language for over 20 years and it makes me feel dizzy looking at many of the new features from the last decade. The reason I've given up on it is not because the old stuff isn't still sufficient for what I need (it is) ,it's because I know what happens when people get their mitts on all the luvverly new features : they start using them. Unnecessarily. And really inapproriately and badly. And they don't document their code because "duuuh, don't you understand implicit virtual module template pointer type conversion autoboxing precedence yet you thicko?". That's when you give up and decide to quietly abandon C++ and make a living using something a bit more sane.
It's a brilliant technology for expert low level programming, but just too dangerous to let average programmers anywhere near it for any general purpose use.
-
Monday 18th June 2018 16:34 GMT GrumpenKraut
Re: Actually, there's more...
> ...when people get their mitts on all the luvverly new features : they start using them.
That's pretty much true for any language that offers a non-trivial amount of tools/techniques.
Look at some of the more horrible VBA code to see what happens with people's brains when a language from the other side of the spectrum is inflicted on them.
-
-
-
-
-
-
Monday 18th June 2018 16:26 GMT The Indomitable Gall
Re: C and C-style C++
@HmmmYes
" Layer your software - assembler/C at the metal/kernel. C++ at the system level. Dynamic scripting language a the application level. "
Where do libraries sit though?
What do you see as the role for functional programming?
And why would you want dynamic scripting for applications when self-modifying applications are a security risk?
-
Tuesday 19th June 2018 08:38 GMT HmmmYes
Re: C and C-style C++
Libraries sit at the system level.
C++ is fine for software running on top of heap/MMU. Less so in the kernel/restricted memory.
I use Erlang/OTP. For its niche - distributed state - its great. But is a niche not a general purpose language.
Im looking at using Haskell for test/verification.
AS far as dynamic scripting being a security risk ..... nuts. You secure the application/system levels.
-
Monday 18th June 2018 20:29 GMT JohnFen
Re: C and C-style C++
"Dynamic scripting language a the application level."
Please, just no. Applications implemented in dynamic scripting languages have the advantage of reduce development costs, but they come with the disadvantage of being inferior in terms of user experience and performance.
-
-
Wednesday 20th June 2018 18:01 GMT Michael Wojcik
Re: C and C-style C++
The "two languages" problem you describe is exactly what Julia is designed to overcome. Code in a modern language, with a REPL and Juyputer notebooks.
I like Julia, but I don't see Julia growing outside the HPC and data science domains. As with most programming languages, its advantages aren't compelling enough to retrain large groups of developers, much less convert existing codebases.
Jupyter (which is what I assume you're referring to) definitely has its applications - if I were doing quantitative research I'd definitely be considering using Jupyter notebooks, whether we were using Julia or Python or some other supported language. But I don't immediately see much use for it in typical system or business programming, even if that happens to be done in a language Jupyter supports.
-
-
-
Tuesday 19th June 2018 02:37 GMT JBowler
Re: C and C-style C++
Indeed, match the language to the application.
Perhaps he would have achieved more communication and less grandstanding if he had said "Algol 68".
For that matter, still less obscure than the Vasa or, indeed, the Mary Rose, "CPL", for which famously (in the right circles) BCPL was intended as the compiler-compiler and BCPL was, of course, the antecedent of B, then C, then C++.
Aseembler is only necessary for the bootstrap - surely that is the legacy of UNIX? C more appropriately encodes the only very slightly later requirements of assembler.
IMO the missing link is not a language but the ability of system level programmers to encode compute intensive tasks into C APIs which can be called from Python.
Alas, system level programmers always were the dumb ones.
-
-
-
Monday 18th June 2018 17:30 GMT HieronymusBloggs
Re: C and C-style C++
"To write new code without some form of protection from these kind of errors is verging on irresponsible now."
You mean like understanding what you're doing and taking care to do it right? It always was irresponsible to write code without that kind of protection, regardless of language.
-
Monday 18th June 2018 19:50 GMT Anonymous Coward
Re: C and C-style C++
Certainly software standards are low compared to "real" engineering disciplines like civil engineering. So yes, people do need to know what they are doing and pay attention.
But the days of being able to keep the entire state of the machine in your head as you program, which was something that you could do back in the day, have long since gone. It's not you, a 68k, 16 registers and a bit o' RAM. It's two, or four sockets each with a variable number of cores, maybe with hyperthreading, maybe with memory access crossing a QPI, god knows how many registers, maybe the whole thing is virtualized, the clock can go slow, fast, stop for days and then wake up, I mean the complexity is astounding. I don't believe that any systems programmer can place their hand on their heart and predict zero % chance of a stray memory access or timing bug in that environment.
-
Monday 18th June 2018 20:34 GMT JohnFen
Re: C and C-style C++
"Certainly software standards are low compared to "real" engineering disciplines like civil engineering."
Hell, software standards are low compared to what software standards were just a couple of decades ago.
"But the days of being able to keep the entire state of the machine in your head as you program"
A correct point, but I don't see the relevance here. You don't (and never have) had to keep the entire state of the machine in your head in order to produce high-quality code. And it's not true that computers have only become so complex in the last couple of decades -- it's true for microcomputers, but many mainframes qualified as "too complex for a human to completely grok" from even before the microprocessor existed. And high-quality code was produced by the truckload then.
-
Tuesday 19th June 2018 11:05 GMT aks
Re: C and C-style C++
"And high-quality code was produced by the truckload then."
As was low-quality code. I know. I wrote some of it. Just as often, it was the specification rather than the coding that was at fault. Anybody remember Y2K. Plenty of COBOL written in the 1970's was not expected to last that long. Most didn't but some did.
-
Thursday 21st June 2018 18:33 GMT Ian Joyner
Re: C and C-style C++
“"But the days of being able to keep the entire state of the machine in your head as you program"
A correct point, but I don't see the relevance here”
It is not just the state machine, it is the general complexity of everything. You need to keep in your head the whole complexity of libraries with many APIs. Some you might be familiar with, others not. It is a great help that compilers actually check that what you have done is correct, especially when you are having to use something obscure.
Really, where are these super programmers who can deal with this complexity in their head?
If you can get it right in your head, fine. It is correct, so the checks won’t bother you. But don’t have the checks and the bugs certainly will bother you.
-
-
-
Thursday 21st June 2018 18:17 GMT Ian Joyner
Re: C and C-style C++
If you really understand what you are doing, you want these protections. Automated checks to see the programmer is doing the right thing are beneficial. They are a help, not a hindrance. People who argue against protections - verification and security - don’t know what they are talking about.
But more than that is the issue of security. C’s model is that you can trust programmers to do the right thing. That is out of a naive age. It is now really, really, really stupid.
-
-
Tuesday 19th June 2018 07:13 GMT david 12
Re: C and C-style C++
M$ doesn't even have a C compiler. It's a commercial decision: they also don't have a FORTRAN or a PASCAL compiler.
You can use their C++ compiler to run sort-of FORTRAN, PASCAL & C (using the macro language as required, the way C++ was originally implemented), but it's not F77 any more than it's C99
-
-
Wednesday 20th June 2018 18:12 GMT Michael Wojcik
Re: C and C-style C++
Stroustrup has always been a blowhard, for me his ship sank almost 20 years ago.
I disagree with Stroustrup on a number of points. I've argued with him in public, on Usenet. I'm certainly not an unalloyed fan of C++.1
But your comment is small-minded and foolish. Stroustrup has made many excellent contributions to computing, a good portion of which have nothing to do with C++, such as his essay (written while Chair of CS at Texas A&M) deploring the resistance to programming among academic computer scientists.
The article links to his papers on the history of C++ and programming languages in general, which are a good example of Stroustrup as an academic. I'd like you to point out where in them he's being a "blowhard".
1A decent, fairly clean language, hidden under a huge mound of ugly and unintuitive syntax, grievous legacy features, unfortunate complications, and obvious failings (some of which S. mentions in the article) which have yet to be remedied; most frequently seen in fevered visions after looking at far too much extant C++ code, which is nearly always execrable.
-
-
-
Monday 18th June 2018 08:06 GMT Mike 125
Disagree....
"I’d like to see C++ supporting a guaranteed completely type-safe and resource-safe style of programming. This should not be done by restricting applicability or adding cost[...] I think it can be done and that the approach of giving programmers better (and easier to use) language facilities can get us there."
I disagree. If it could've, it would've, by now. Performance and safety will always be in conflict.
C++ has been a Vasa for years. It floats because it's in dry dock.
-
Monday 18th June 2018 08:47 GMT Wilco
Re: Disagree....
If you want type safe resource safe programming I'd suggest Java, or preferably Scala.
There are now only narrow use cases for C++: embedded systems, low level systems programming, hard resource or performance constraints that you have demonstrated that you can't meet with a more tractable language.
I spent a decade writing C++, and nearly 20 years more working in Java, Scala, C# and F#. Only very occasionally have I had to fall back to C++ to meet some non-functional requirement.
The idea of writing a large scale system with a modern distributed architecture in C++ is ludicrous. Even if you could, what would be the point? And where would you get the developers.
Not quite a dead language, but one with increasingly little point
-
Monday 18th June 2018 09:07 GMT LucreLout
Re: Disagree....
Not quite a dead language, but one with increasingly little point
An interesting view, and not one I'm qualified to disagree with particularly. I'm a C# dev - have been since it was released. I've not looked at C++ since the 90s, but upon reading the article formed the view I should possibly look again at C++ as another potential tool, so I've ordered the 2018 book as a prerelease.
-
Monday 18th June 2018 10:53 GMT JDX
Re: Disagree....
>The idea of writing a large scale system with a modern distributed architecture in C++ is ludicrous. Even if you could, what would be the point? And where would you get the developers.
What do you mean, where would you get the developers? As the dominant applications language in the recent past, there are a vast number of experienced C++ developers out there. Many of them still relatively young (30s).
-
Monday 18th June 2018 11:51 GMT Blank Reg
Re: Disagree....
Despite having used it extensively, C++ has long ago become my language of last resort. It has just become too complex. This is especially problematic for legacy projects where you can find every instance of the latest and greatest addition to the language being used.
While you can write clean, easily maintained code, it's also trivially easy to write code that will make your eyes bleed just looking at it. And once that second developer joins the project the risk of eye bleed ramps up and increases as the team and project grow.
-
-
Monday 18th June 2018 22:32 GMT Someone Else
@ JohnFen -- Re: Disagree....
"While you can write clean, easily maintained code, it's also trivially easy to write code that will make your eyes bleed just looking at it."
I literally can't think of a language that this isn't equally true for.
Stated another way, you can write FORTRAN in any language.
-
-
-
Monday 18th June 2018 17:26 GMT JLV
Re: Disagree....
>I'd suggest Java
Yeah, because GC-originated slowdowns are not a thing. Precisely the type of focus that will motivate team to use C++.
System-level, which Java is not. Java drivers, anyone? If you're using C++ for a good technical req reason, Java is _not_ the alternative.
Contrast also interop capabilities: almost anything can talk to C++. Anything can talk to Java as well... provided it's Java, or at least JVM.
Lots of crap to learn:both.
If you separate active developement from legacy corporate base maintenance, a la COBOL, I suspect that C++, for all its flaws, will age better.
Been casually looking at Rust lately. Nothing immediate to do with it, but it does seem like a potentail for a true generic system language. Their focus on memory is what really sets them apart.
-
Monday 18th June 2018 20:58 GMT Anonymous Coward
Re: Disagree....
Rust has caught my eye as well, and for the same reason. If you or I dare to open the parts of my drives containing all compilers, scripting languages, RAD tooling, basically most everything usable over the last 45 years of software development, it's an impressive stack. When doing a job, I get the general requirements, budget, time, and a list of anything already used in-house. [It's extremely likely some other person is going to support this down the road.]
I collect languages and/or libraries like lint (pun fully intended). Look in the toolbag. Does X fit this job spec? Put in the useful widget stack. Otherwise, goto next. I've got better things to do than argue around evangelism of any sort.
[The last time I was evangelical, it was the Amiga.]
-
-
-
-
-
Monday 18th June 2018 10:57 GMT Anonymous Coward
"when the JRE installer started..."
.... to multiply because most app work with just one specific release, developers don't know how to bundle it in their damned application locally, and you need to keep installed outdated and vulnerable ones.
And still, as soon you just look at a Java application, a couple of Gigabytes of RAM are gone....
-
-
Monday 18th June 2018 10:22 GMT Dan 55
Re: Disagree....
Java is the antidote to C++ in the same way as a saw is an antidote to gangrene (remember you shot yourself in the foot with C++?). It's fiddly to develop for because it probably won't let you do what you want to do, the bits it will let you do are horribly bureaucratic, and if C++ is getting a bit fat, Java is in danger of collapsing under its own weight in libraries.
-
Monday 18th June 2018 16:48 GMT Fibbles
Re: Disagree....
I thought the same. I thought he just described Java when he described a "completely type-safe and resource-safe style of programming". That's what Java *is* and it became a thing precisely as an antidote to C++.
The difference is that C++ aims to do these things with zero runtime overhead. Think RAII vs garbage collection.
-
-
Monday 18th June 2018 09:39 GMT I Am Spartacus
Re: Disagree....Because it's been done
Have a look at RUST.
Total type safety, with race conditions eliminated, safe sharing of data structures between threads, and blisteringly fast. Compiles and links to a standalone executable.
The future looks Rusty.
Mines the one with "Borrowing for beginners" in the pocket.
-
Monday 18th June 2018 13:29 GMT Anonymous Coward
Re: Disagree....Because it's been done
In a few years, Rust will honor its name... and you can't really rely on a language that changes too much among versions, striving for "perfection".
Not everybody has the pleasure to re-write applications to cope with changes.
That's the mistake Wirth made with Pascal, instead of evolving it made different incompatible languages.
And while many people like to ignore it and bash it, Pascal had many of the features languages now try to reintroduce to make them safer.
-
Monday 18th June 2018 20:38 GMT JohnFen
Re: Disagree....Because it's been done
"And while many people like to ignore it and bash it, Pascal had many of the features languages now try to reintroduce to make them safer."
True, and those features are exactly what prevented Pascal from being used for serious programming. The later revisions to Pascal (which I agree were terrible) were mostly trying to fix that problem.
A language which protects you from having to think about what you're doing is also a language that prevents you from doing quite a lot of useful stuff.
-
-
Wednesday 20th June 2018 18:18 GMT Michael Wojcik
Re: Disagree....Because it's been done
Have a look at RUST.
Rust (it's not an acronym) suffers from programmer resistance to the borrow model, a community widely noted for hostility to being questioned, and (as someone else noted below) a tendency to change without preserving backward compatibility.
It may yet outgrow those challenges, but history suggests that new programming languages have an uphill battle, and Rust hasn't done a great job so far of building momentum.
I have no dog in this fight myself - I haven't done anything significant with Rust, and I'm perfectly happy with the borrow model. (I designed a toy language with something conceptually similar years ago.) But I'd be quite surprised if Rust is one of the major languages in, say, ten years.
-
-
-
-
Monday 18th June 2018 16:13 GMT Anonymous Coward
Re: Disagree....
> Insulting those who raise valid criticisms of the language really helps engage the community.
It doesn't. And that was the point in the first place.
In this case, the community that you refer to is this constant background noise of commentards who are so far off the mark in their so-called valid criticisms they don't even realize they would've been better off keeping quiet.
Kind of like art critics. They can't paint or sing to save their lives, but they know exactly how someone else should paint or sing.
It's Better to Remain Silent and Be Thought a Fool than to Speak and Remove All Doubt.
-
-
Monday 18th June 2018 16:03 GMT Anonymous Coward
Re: Disagree....
> There's always PHP.
Actually, PHP is the dynamically typed cousin of C++. Like C++ and ObjectiveC, PHP originates from the C syntax and C standard library (and Perl stuff). PHP is very similar to C++ in so many ways, some devs hate it for some reasons or another, just like C++. Overall, PHP and C++ are multi-paradigm languages that offer more and compile to faster machine code than competitive languages. The language syntax is not always nice and its standard library has grown over decades. It speaks for itself that 95% of all consumer GUI applications on desktop/notebook are written in C++ and 85% of all websites are coded in PHP. And the reason why ObjectiveC and Java are so common on iOS and Android is, because they are forced upon those devs. C++ is a alien there, with no proper platform first party support. But is often used behind the scene to power cross platform native libraries.
-
Tuesday 19th June 2018 21:29 GMT James Jones
Re: Disagree....
Conversely, any criticism of C++ is met with accusations of incompetence (with implied superiority of the accuser).. Should I end up using C++, I will make a point of using a bare minimum of its ever-growing list of features. For now, I'm just watching the language's accretion disk--not sure whether in amazement or sadness.
-
-
-
-
-
-
Monday 18th June 2018 10:33 GMT GIRZiM
Re: A real Stroustrop joke*
real joke (*Stroustrop)
FTFY.
But, fun and jokes aside, the problem with C++, as we al know, is exemplified in The Sex Life of the Computer Programmer, wherein it is explained that:
"You make love to your girlfriend and her cousin at the same time - unfortunately they both learned their technique from their uncle and you walk home sporting an anus like the Japanese flag."
-
-
-
-
Monday 18th June 2018 08:36 GMT Anonymous Coward
Design by committee
I have always admired Stroustroup's pragmatism, and he's quite the diplomat as well.
With languages (programming and human) everyone has got at least one opinion of "what should be the norm", so the committee is a risky one.
If the committee decides to observe what is being done in practice and create a norm out of it, then things may more or less work and there should be tendency towards simplification; if on the other hand the committee is seen as a vehicle to push each member's pet projects and goals... we have an idiom for that: "design by committee".
With ISO being such a political organisation I wonder if it is the best choice for the matter at hand.
-
Monday 18th June 2018 11:40 GMT Bronek Kozicki
Re: Design by committee
if on the other hand the committee is seen as a vehicle to push each member's pet projects and goals...
It is not - because it is possible for any member of the committee to stop dead a pet project of another member if they deem it an "unworkable time hog". Sometimes that saddens me, sometimes I glad because of that. There are many proposals and also some interesting research which deserve closer attention than they receive.
However, "design by committee" does show up, in the very very long "bikeshedding" discussions where most participants agree in principle on a feature or change, but cannot agree on how it should be designed.
-
Monday 18th June 2018 08:42 GMT Anonymous Coward
I am scared of the pressure to add [...] features to address immediate needs and fashions
This.
Most languages are today designed only for immediate needs and fashion, and are also proliferating - "heck, this fashionable construct is missing, let's make a new language!" - if most of their applications don't die soon enough, it will become a maintenance nightmare.
-
Monday 18th June 2018 09:02 GMT Voland's right hand
Re: I am scared of the pressure to add [...] features to address immediate needs and fashions
Correct. Additionally, the prejudices reign supreme.
Example - when you mention Perl you get retches all around. At the moment I am doing a piece of code which needs to deal with some low level packet mangling, database access and a northbound RPC interface in both Python and Perl.
1. Every single library in Perl worked out of the box and all of them were on the system, so no CPAN abuse. PCAP, Epoll, JSON, DBI and most importantly packet manipulation. Straight sailing all the way until it worked.
2. Python. My, oh, my. It takes some guru level hoop jumps to integrate pcap into anything useful with an event loop, half of the packet mangling does not work, DBI is non-existent and there is only a very loosely policed database interface. Most importantly the off-the shelf packet manipulation does not work so you are either facing the choice of reusing scapy which is a dinosaur or you have to write your own.
So the fact that the emperor has no clothes does not prevent the emperor's followers to continue shouting loudly. Fashion and fanboiing all around.
By the way, the system this will be integrating with is written in C++, but there is no way I am writing in this. Not that I cannot, life is too short for it considering that it has an API interface and python bindings.
-
Monday 18th June 2018 10:27 GMT Anonymous Coward
Re: I am scared of the pressure to add [...] features to address immediate needs and fashions
On the other hand, I could tell an opposite story if I wanted to do some large array-bashing numerical-model stuff in Python or Perl. In Python there's NumPy and an entire culture built on top of it, in Perl there's ... what?
Note I hate Python (though I have to write it) and am secretly rather fond of Perl (which at least has variable scoping rules which don't make me want to sandpaper my fingers off): I'm not trying to support either language.
-
Tuesday 19th June 2018 03:56 GMT onefang
Re: I am scared of the pressure to add [...] features to address immediate needs and fashions
"Note I hate Python (though I have to write it) and am secretly rather fond of Perl (which at least has variable scoping rules which don't make me want to sandpaper my fingers off): I'm not trying to support either language."
I personally have an unreasonable hatred of any language beginning with the letter P, and I include Ruby as a dishonourable member of that club.
-
-
-
-
Monday 18th June 2018 08:53 GMT chuckufarley
This is...
...the kind of thing I would like to see on El Reg. I even read it twice. Once like I normally do, and then once more with the ad blocker turned off. It's a good idea to interview the people behind the projects that drive the modern world. Their work and ideas are used by a billion people every day. Getting to hear what they think is a rare thing unless you can afford to fly all over the world to conventions and meetings.
Please Sir, I want some more.
Thanks, El Reg
-
-
Monday 18th June 2018 09:35 GMT Nick Kew
Re: Whatever happened to ...
Sorry, missed your post when I referenced ADA.
I always thought that pascal-on-steroids was a missed opportunity for nice things like builtin checking of types and dimensions. All that extra complexity, yet it never occurred to anyone that the language might enforce that dividing a distance by a time gives you something that isn't your blood pressure.
-
Tuesday 19th June 2018 14:36 GMT Nick Ryan
Re: Whatever happened to ...
In my experience one of the key problems with the early iterations of Wirth's Pascal and ADA (and Modula/2) was his obsession in having to have a single pass compiler and how just this one thing tended to ruin a real-world developer's life. That and almost no supporting libraries or direct access to anything useful system-wise.
-
-
-
Monday 18th June 2018 09:31 GMT Nick Kew
Design by committee
I thought the rot in C++ started with navel-gazing over templates, about when it went from C-with-classes to designed-by-committee. But at least STL is kind-of a separate module in the language.
I think my attitude over the years has been shaped by the alternatives. When I first encountered it, the world I worked in was drooling over ADA, and I grasped C++ as a beacon of relative sanity. A decade on, JAVA was the new kid on the block with promises that looked a lot like ADA had done, but C++ had turned committee-ugly and was no longer such an attractive refuge.
-
Monday 18th June 2018 12:53 GMT Anonymous Coward
Re: Design by committee
> I thought the rot in C++ started with navel-gazing over templates, about when it went from C-with-classes to designed-by-committee. But at least STL is kind-of a separate module in the language.
It would be to your advantage if you stopped opining on matters you obviously haven't the first clue about.
To begin with, STL is not a module. It's a blueberry muffin with custard filling.
-
Monday 18th June 2018 16:54 GMT ThomH
Re: Design by committee
I disagree; templates are the best bit — the syntax could be cleaner but being able to write std::find(container.begin(), container.end(), value) and that result in the compiler being able to generate the proper code to search any iterable container is a neat alternative to more traditional approaches towards the same objective like dynamic dispatch. Specialisation (i.e. providing special cases explicitly) is the icing on the cake.
It's just a shame that (i) it's helpful for the template system to be Turing complete; but (ii) the look-at-me-I'm-clever crowd think that barely-comprehensible template hoops are a fantastic way to advocate the language.
-
-
Tuesday 19th June 2018 04:00 GMT onefang
Re: Design by committee
"Me too. I still consider templates, and the STL, to be a bit of an abomination and ignore that whole mess to the greatest degree that I can."
That I think is one of the major problems with C++, it's such a huge language that everyone uses only a sub set of it, coz that's the bit they can understand. Except everyone uses a different subset, making it hard to understand other peoples code.
-
Tuesday 19th June 2018 10:12 GMT parperback parper
Re: Design by committee
Yup. It took a wrong turn with templates, and most of the changes since have been trying to patch up the resulting mess.
And the STL is a nice idea but frequently a pain in the arse to use.
You can't debug it, due to second-class compiler and debugger support.
Minor syntax errors take dozens of lines of garbage to basically say 'template problem'.
Debuggers give you cryptic structures to navigate (because STL is a library, not a language feature, so it gives you implementation detail you really don't care about).
Oh, and the syntax of the STL produces barely readable code. eg. the standard idiom for checking if a container contains something reads as 'if, between the start and end items of the container you don't find the not found item'.
cf:
if ( std::find(vector.begin(), vector.end(), item) != vector.end() ) // Actual STL
vs
if (vector.contains(item)) // What readable code would look like
-
Tuesday 19th June 2018 17:20 GMT Fibbles
Re: Design by committee
The contains method is certainly shorter but the whole point of Standard Library algorithms is that they are generic. The free function 'std::find' will work with any container that provides iterators, even user created ones. You can even use the function on a raw array by just passing it pointers rather than iterators. The fact that it lets you specify the begin and end iterators also lets you find an item within a sub-range.
On the other hand the 'contains' method needs to be re-implemented for every new type of container. It also only lets you search the full container, there's no facility for specifying a sub range.
Then there's the return type. The 'std::find' function will return a pointer/iterator to your found element so you can immediately start using it, otherwise it'll return whatever you specified as the end of the range. By the looks of things 'contains' just returns a bool which is considerably less useful.
-
Tuesday 19th June 2018 17:26 GMT ThomH
Re: Design by committee @parperback parper
I'd read that more as "if the element was found before reaching the end" rather than inflecting it with negatives, but I agree with your point in the main part. C++ is a lot of really useful stuff and good ideas, hiding behind syntax kludges.
SFINAE is possibly an even better example. If anybody here isn't already familiar, look up std::enable_if, then calculate the ratio between the amount of time it took you to understand the purpose and utility and the amount of time it took you to be able to produce the syntax.
-
Friday 7th September 2018 13:10 GMT Anonymous Coward
Re: Design by committee
"cf:
if ( std::find(vector.begin(), vector.end(), item) != vector.end() ) // Actual STL
vs
if (vector.contains(item)) // What readable code would look like"
But then you cant do
if ( std::find(vector.begin()+2, vector.end(), item) != vector.end() ) // Actual STL
and you can always right your own template contains
if(contains(vector, item))....
-
-
-
Tuesday 19th June 2018 09:39 GMT Tom 7
Re: Design by committee
Strangely (for most) is I can see why most of C++ is like it is as for some reason or other my personal programming development has matched what went on with C++. I think the problem you have is its not designed by your committee. All languages will, if allowed to develop, will eventually encapsulate the same concepts. All languages will try and square the circle slightly differently - the square will simply be presented with a different rotation and the greek use of epicycles to calculate the orbit accurately will crop up in different places.
Learn the square, learn the circle and dont fight the epicycles - its a fucking pointless self defeating exercise that just makes you miserable.
-
Monday 18th June 2018 09:45 GMT hammarbtyp
Parallel algorithms – there is no easier way to use the power of the concurrency features of modern hardware
Not sure what he meant by that - Have they managed to shoehorn some sort of side effect free way of writing C++ or implemented a message passing scheme?
C++ is a nightmare to write Parallel Algorithms in, but then again so are most imperative languages. As soon as it scales, you will hit issues unless you are very careful.
-
-
Monday 18th June 2018 21:19 GMT Richard 12
There are several C++ map-reduce libraries
Boost, Qt etc
Essentially:
Future<type> result = map_reduce (data, mapfunctor, reducefunctor);
The Future class gives you a flag/signal/event when "done", and an accessor to get the actual result. If useful, it can also indicate progress and get cancelled.
Manylots of threads go off and do the map and reduce functors to the data, then the Future lets interested parties know.
The calling thread can start it and do something else while it's running, or block until done.
The Qt implementation is really rather nice.
-
Tuesday 19th June 2018 09:43 GMT Tom 7
Re: There are several C++ map-reduce libraries
I do like them myself.
I do not like the fact Qt seems to take up several gig and when I have to upgrade so I can compile a 500 line graphics app I seem to have to download all possible libraries. I'm sure I've see a QT library for the Manchester Baby in there!
-
-
-
-
Monday 18th June 2018 10:15 GMT CommanderGalaxian
Heaven help the newbies.
From about 1989 through the 2004 - I spent most of my time programming in either C or C++ and loving them both. Then for the last decade and a bit I've been programming SCADA sytems (which tend to have their own Pascal or C like languages).
On coming back to C++ in 2018 - all I can say is: WTF happened!?
-
-
-
-
Monday 18th June 2018 21:15 GMT Anonymous Coward
Re: Code style
Concur. That's part of the future support capability in whatever I do. It's highly likely, for one reason or another, some one else is going to try something with what I've crafted. Why should I make their life Hell? I also keep the complexity level low, not stupid but useful. APL (J now) is a favorite of mine but I'm used to using maths most everyone else doesn't know exists.
-
-
Tuesday 19th June 2018 09:47 GMT Tom 7
Re: Code style
You dont understand, The purpose of Code Style is so that no-one can ever learn the full set of quirks in your company so you will always make a mistake here or there and then the really shit managers can go off on one for several weeks explaining to everyone in the department how its your fault you couldn't solve Fermat's last theorem in 20 lines of python as he'd demanded in the project plan.
-
-
Monday 18th June 2018 10:48 GMT karlkarl
I was on the C++ spec discussion group the other day asking why std::shared_ptr<T> or std::vector<T>::iterator did not provide some additional checking whether memory gets destroyed whilst within the member function itself (i.e 'this' gets destroyed, via a smart pointer resetting or a vector clearing).
Whilst I certainly I agreed that these features will add some overhead and should not be part of the spec, I would really like to see it enabled in some sort of debug mode rather than leave that task to compiler specific vendors (to mess up).
Basically I fear that C++ is evolving the wrong way. It is becoming full of really cool advanced and fast features that I will likely never use, whereas it is still just as unsafe as it was since the invention of smart pointers in TR1 / C++0x.
I think the problem is that these guys are so smart that they don't need this additional error checking. Unfortunately the rest of us really need them (as evidence with a lot of security related bugs that keep cropping up).
-
Monday 18th June 2018 11:01 GMT Missing Semicolon
C++ has been squeezed out
If you want stuff to run quickly, or with few resources in a tiny micro, there's C.
If you have a bigger box, heap, scheduling, whatnot, you use a proper manage language like Java/Rust/Scala.
For code where the expression on a complex algorithm is the main problem, not the cyle-level efficiency, you go higher level Python/R/Go
C++ can't really be used unless you have a heap. If you do have a heap, with plenty of free space, yoiu need memory management, ruling C++ out.
-
Monday 18th June 2018 11:32 GMT karlkarl
Re: C++ has been squeezed out
C++ uses the same memory management system as Rust. RAII.
In many cases, big heavy things like Java and .NET are simply not a solution to C++ and aren't they all written in C++ anyway? ;). I don't think C++ will ever be squeezed out and I predict its lifespan will actually extend well beyond most of those mentioned languages.
Ultimately, C is king and in theory the only language we really need (it attaches our logic to the machinery) and C++ is meant to be C with additional safety and facilities. I have tried to create a safe ANSI C library (https://github.com/osen/plank) largely using MACROs. It still isn't quite up to the safety of C++.
-
-
Monday 18th June 2018 14:45 GMT Lee D
I have to say, just that simple for-loop is a prime example of why I don't like C++.
I can memorise the entire standard library of C, and every command in it, and every operator, and every syntax. Nobody can then run up a piece of code which can't be deciphered (sure, I may have to play pre-processor games, but everything will come down to obvious code).
When there are a dozen ways to iterate over a simple group of objects, and half-a-dozen different groups of objects, and obscure syntactic sugar the people use because it saves them a fraction of a second, it quickly becomes a pain to understand. Which means it's a pain to verify. Which means it's a pain to secure. Which is not what you want in something like C/C++.
The "hidden effects" of such code, where things are iterated upon, objects are instantiated, etc. behind your back is a real pain to me. It's like every simple line becoming a dozen "subroutines", overrode and silently inserted, and no obvious way to tell that's what's happening from a quick glance.
I'm sure with a good IDE, these things become mere colourations, and you can expand object creation etc. but it means too much is going on under the hood without my say-so.
That's the problem I have with C++... someone can give you the worst spaghetti code and it could easily be malicious, obtuse, or just terrible. With C, you have a chance to spot it, you can pre-process and then see each step, and you have the entire library in your head. If you want to use fancy objects, you have well-defined headers and you can easily isolate the problem.
When I read my first book on C++, I was so excited to try using it. We all know that "reading about it" and "doing it" are two very different things, but I'd never seen such a gap when learning a programming language. Everything about C++ suggests it should be wonderful, but the pitfalls and readability plummet the second you try to use it, and the other code you inherit is usually nothing more than show-off gibberish trying to use every template, library function and short-cut syntax possible.
I dearly want C-with-objects back again. C++ never was that, despite claiming so at one point.
-
Monday 18th June 2018 17:02 GMT GrumpenKraut
> I have to say, just that simple for-loop is a prime example of why I don't like C++.
Funny, I really like that idiom.
But let me offer you some help with hating C++: Let A be a std:valarray (of, say, type int). Then you can replace all elements strictly greater than 5 by 77 as follows:
A[ A > 5 ] = 77;
No, I am not kidding.
-
Monday 18th June 2018 17:39 GMT Fibbles
"Language I know is easier to understand than language I do not know."
The range based for loop is far from opaque to anybody who actually knows the language. It simply iterates the each element 'foo' in container 'bar'. It does it by using a feature of the language that has been in the standard for 20 years, namely 'iterators'. Every algorithm in the Standard Library uses iterators, they're not a difficult concept and are fundamental to understanding the Standard Library.
Your complaint seems to be that you don't understand the inner workings of the Standard Library and therefore can't 'secure' your code which is ridiculous because you shouldn't care about the implementation any more than you should care about the implementation of your compiler. At a certain point you have to trust that something does what it says on the tin.
-
Monday 18th June 2018 18:52 GMT karlkarl
I agree that C has some advantage over C++ in that it is simpler. This is quite evident by the K&R book being about 1/4 the size of Stroustrup's C++ Language book ;)
However the complexity in some cases is worth it. For example with "safe" iterators it can be set up so that if the data you are iterating through changes (i.e some berk has cleared the container hidden down the call stack), you can know about it (with an assertion).
That said. Some developers I feel over-consume C++ features (especially templates). For example, I present to everyone the GLM challenge. Who can find where the glm::mat4 glm::rotate() function is actually implemented in 1 minute?:
https://github.com/g-truc/glm/tree/master/glm
I'll give you a clue... If you are using an IDE with intellisense. Turn it off. It will probably crash ;)
Contrast this with linmath (ANSI C): https://github.com/datenwolf/linmath.h
GLM is safer but gosh is it more complex. I would hate to extend that thing.
-
Monday 18th June 2018 20:13 GMT Fibbles
/glm/gtc/matrix_transform.inl
glm - because it's in the OpenGL Math Library
gtc - because it's Template Core rather than Template eXperimental (gtx)
matrix_transform - because it's a free function for transforming a matrix object
.inl - design choice of the library, could just as easily go in the hpp file
This seems more a criticism of the GLM library and their header layouts rather than a valid criticism of templates. It's also unfair comparing its size to linmath since GLM is specifically designed to inter-operate with OpenGL and mimics GLSL as closely as possible within the limits of the language.
-
Monday 18th June 2018 21:08 GMT Anonymous Coward
Who can find the glm::rotate() function?
> For example, I present to everyone the GLM challenge. Who can find where the glm::mat4 glm::rotate() function is actually implemented in 1 minute?:
Interesting .. I've also wondered why, for such a high level language, you need to help C++ keep track of its variables using the Namespace feature. For another example, it's perfectly obvious that :: is the scope resolution operator and does different things depending on the context. It would be like creating a human language that the key words could be overloaded with ever changing meaning <sarcasm>
Human brains don't work like this, C++ a high level computer language written for computers :]
-
Monday 18th June 2018 21:33 GMT Richard 12
Re: Who can find the glm::rotate() function?
Namespaces are because it's not possible to give every class, function and constant a unique, memorable name.
It is common - nay certain - that a mid to large sized project will have multiple things that with the same name.
But if you have Eigen::matrix4x4 and GLM::matrix4x4, you can actually say which one you mean.
Nothing more.
And of course, you can just tell the compiler "in this source file I use GLM", to avoid typing the letters.
-
-
-
-
Monday 18th June 2018 16:16 GMT HmmmYes
Problem is, each language version really should be considered a different lanaguage.
Maintaining any long (>10 year) lifed C++ is a massive PITA.
Ibe seen programmers start off MFC C++ style - C++90 + the stupid MS addons.
Then some has read the Design Pattern book, so you get 'patterns' in the code base from 95is-00ish.
Then they discover the STD. All the new stuff then becomes templated.
All a massive fuckup.
You need to have strongly applied coding rules, not just syntax but on the language and libraries used.
The module needs needs to be frozen to that C++ version.
End of the day, I spend more time testing.checking stuff than I do writing new stuff. Any language that makes testing easier gets my vote.
-
-
Monday 18th June 2018 20:53 GMT Fibbles
It's not far off that really. C++ is a statically typed language so you need to provide a type in your code or explicitly tell the compiler to deduce it from the value passed.
for ( auto& x : v )
If you look at the above range based for you can see that the colon is equivalent to 'in'. The only non obvious bit to somebody who uses another language is the 'auto&'. The 'auto' just tells the compiler to deduce the type since it knows what 'v' contains and therefore knows the type of 'x'. The '&' tells the compiler that it should not make a copy of the element from the container but just use a reference back to the original object.
-
Monday 18th June 2018 21:07 GMT Lee D
I'm with the foreach guy.
The second you start using a different syntax for the same command (for), and distinguish using obscure symbols, and even HAVE things like "auto" type modifiers (which just makes me think of VB "Variants"... shudder...), then you've strayed far enough from the original command to warrant a new keyword.
That line is impenetrable to my programming mind. Can you honestly imagine seeing something like that inside, say, the Linux kernel? Or the LibreSSL library?
C++ just wants to overload absolutely everything, including its own commands, and that quickly turns into a royal mess.
And I can't imagine that the generated code is any better than just using the "obvious" foreach and a type/object that allows iteration, and an obvious array/collection of objects.
For instance, if that loop modifies x, and it's just a reference back to the object inside the collection, that could quickly turn into disaster and it might well be hard to spot.
Honestly, a programming language is like a joke, if you have to explain it, it's not working. Sure, C is hardly as readable as BASIC, but C++ is an order of magnitude more obscure than either, especially when people play with these pretty "tricks".
-
Monday 18th June 2018 21:31 GMT Fibbles
The second you start using a different syntax for the same command (for), and distinguish using obscure symbols, and even HAVE things like "auto" type modifiers (which just makes me think of VB "Variants"... shudder...), then you've strayed far enough from the original command to warrant a new keyword.
That line is impenetrable to my programming mind.
What makes it impenetrable? I really can't see how 'foreach x in y' is significantly more readable than 'for x in y'.
The auto keyword is not specific to for loops, you can use it pretty much anywhere you'd like the type deduced. It's useful because you shouldn't be redeclaring the same information over and over. If I change variable foo from int to unsigned int I don't want to have to then go through each line of code to change the type there as well.
Can you honestly imagine seeing something like that inside, say, the Linux kernel? Or the LibreSSL library?
No because they're both written in C, not C++.
For instance, if that loop modifies x, and it's just a reference back to the object inside the collection, that could quickly turn into disaster and it might well be hard to spot.
References have been a core part of the language since the year dot. Do you have the same complaint about pointers? A reference serves the same purpose as a dereferenced pointer.
Honestly, a programming language is like a joke, if you have to explain it,
You can't honestly expect to be able to use a language without learning the syntax. Even something like Python (which is marketed as close to natural language,) requires you to learn the syntax.
-
Tuesday 19th June 2018 07:22 GMT Waseem Alkurdi
(which just makes me think of VB "Variants"... shudder...)
Talking of the devil! For those who haven't endured the mental pain of understanding it:
Want a data type that stores strings and integers, yet can't use string functions nor integer functions, nor can be useful for anything? Yes sir: Variant.
Worse still is that not defining a data type for a variable "implicit declaration" gives you a fucking Variant.
-
-
-
Friday 7th September 2018 13:35 GMT Anonymous Coward
why not simply have a 'foreach'....
"why not simply have a 'foreach' ?
foreach (x in v) x++;"
Because that would require reserving another keyword, unnecessarily breaking lots of existing code , when 'for' is already reserved and easy to understand, the only new bit of syntax is the reuse of the ':' the rest is all normal C++
You could just as easily write
std::vector<int> v
for(int i : v) ....
Backwards compatibility.... for when your language is not just a fashionable toy
-
-
Monday 18th June 2018 20:53 GMT handleoclast
Bring back the good old days
Those wonderful days when Niklaus Wirth had a strong say in the design of a new language, and of new features to an existing language.
That way it is absolutely guaranteed to be unusable crap. So almost nobody but bondage and discipline fetishists will use it, and the rest of us can safely ignore it.
-
Monday 18th June 2018 23:42 GMT Ian Joyner
I Agree with Bjarne Stroustrup!!
I remember reading something a long time ago by Bjarne on the Vasa. I really recommend a trip to see it if you are in Stockholm – quite a sight.
I have been agreeing with Bjarne on this point for over 20 years, and C++ has been a top-heavy artefact for at least that time.
http://ianjoyner.name/C++.html
I'll admit to missing the most critical point (for 2018) that security is the elephant in the room for both C and C++ (and CPU/system architectures). Like most, I concentrated on correctness and verification, as well as other factors such as maintainability. Security is intricately tied to correctness, but rather than guarding a programmer against their own mistakes, it is guarding a system against the malicious intents of others. C and C++ can be too early undermined, and buffer overflows have proven to be the curse of modern computing, but blessing to the hackers.
But security is indeed the issue that should see C and C++ relegated to the past of the wild-west days of computing.
It is time for a rethink – or at least to learn the lessons from the past for good software development, even back to the 1960s, that C and C++ have wilfully ignored and spurned as 'restricting programmer freedom'. That attitude was naive, then stupid, now it should be criminal.
-
Tuesday 19th June 2018 05:03 GMT Maelstorm
Uhggg Another C++ standard?
You know, we don't really need any new features to the language. In fact, there's a few features that probably should be removed. So yes, I agree with Bjarne Stroustrup. Right tool for the job really. I view C++ as the object oriented version of C, and I use C...a lot in my coding since I code close to the bare metal. C and assembler for my work.
C: Low level system stuff such as kernels, device drivers, libraries, etc...
C++: Higher level application stuff (especially on GUI platforms) or when using objects make sense...like the Abstract Syntax Tree that's generated from a parser and is fed into the code generator for a compiler. OOP makes sense here since the nodes are all the same, the data they contain is what differentiates what type of node it is.
Here's a little thing that Linus said about C++. Enjoy.
http://harmful.cat-v.org/software/c++/linus
-
Tuesday 19th June 2018 05:42 GMT Waseem Alkurdi
Regarding the "C Plus" in the headline
<rant>
It REALLY GETS ON MY TITS when engineering students at our university (who have to take C++ as mandatory) call it "C plus" as shorthand/acronym/whateverthefuck.
REALLY ANNOYING.
</rant>
I do understand that this is to rhyme with "fuss", but it awakes my PTSD whenever I hear it.
-
-
Tuesday 19th June 2018 10:32 GMT onefang
"If they want an extended version with new features give it new name."
Hmm, C+=2, ++C, D (Oops, taken already), CPLusPLus (from BCPL, the grand daddy of C++), CRAP++, I could go on...
Though given my above declaration for hating all languages beginning with P, continuing the BCPL -> B -> C tradition and calling it P will just get right up my nose.
-
-
Tuesday 19th June 2018 10:24 GMT amanfromMars 1
No need to reinvent the wheel ... but there are always leading improvements to be made for markets*
There are no major decisions I regret, though there is hardly any feature I wouldn’t do somewhat differently if I had to do it again. .... Bjarne Stroustrup
Exercise that easy option and invent a much more formidable scripting tool leading machines towards goals delivering invincibility with increased markets share of derived product.
Anything else surely has one polishing a turd rather than displaying a diamond in the raw?
* For example ..... Not quite reinventing the wheel, but ...
-
Tuesday 19th June 2018 15:12 GMT CodeBlaster
C++ vs C
Coming from an assembly language background (6502 and 68000) back in the day, I decided that it was time to learn how to code in C/C++. This was back in the early 90s - I was a games programmer and the move from the Amiga to the PC meant that I had to learn how to code in this "new" high level language. Having bought a number of C++ books, it was an uphill struggle and I decided to just learn C, giving myself the option to learn C++ if I needed it in the future. I taught myself C in 2 weeks using an excellent disk/book set called "Master C". To prove to myself that I had learnt it, I wrote a crappy PC version of Galaga with assembly language for the graphics and everything else in C. No problem, it took me 3 days. I've never needed C++! I was involved in one other (PC) game back in the 90s and then got out the industry but I've written numerous complex apps in C and never felt the need for C++. In my opinion it is too much for a beginner or maybe I just wasn't intelligent enough to pick it up easily. I long for the heady days of assembly language coding - software seemed to work better back then...
-
Wednesday 20th June 2018 11:23 GMT Missing Semicolon
Re: C++ vs C
There are two things wrong with C++
1) Spooky hidden code. Due to the horrors that are overloaded operators
c=a+b;
Is completely incomprehensible. If a and b are instances, the actual code is presumably in the overloaded operator+ for the class of a. Then, it must create a temporary a on the stack, before using the copy constructor to make c. So, if there are side effects in the constructors, all sorts of shizzle goes on. Plus it can eat up loads of stack.
And, the whole mess was just to make sure that strings are not special objects, but you can still write
foo=bar+"more";
The world already has Perl as a write-only language. It doesn't need another one.
2) The utterly crap reference book. Everyone worships Stroustrup, but the book is utterly useless for learning to write real-life code. It always shows stuff as definitions, ans rarely describes how to separate declaration and definition - the way you always work. The descriptions of the various features are a hymn to how clever they are, not a careful description of the use, abuse, and side effects.
-
-
Wednesday 20th June 2018 03:21 GMT martinusher
Been there.....done that.....
Back in time there was a family of languages called Algol. They're the grandparents of the block structured language, its where you'd first find curly braces and semicolons. A very popular version was the 1960 model, Algol 60, which worked but had a few imperfections. These were fixed for the version Algol 68. It was a superb language with just one slight snag -- it was effectively unimplementable on the machines available at that time. Various implementations were made but most were panned as impure, not worthy or whatever.
C++ is in danger of going down the same rabbit hole -- if it isn't lost already. Its worse for us because at least all Algol sprung on us was a "Revised Report...", a well thought out theoretical document. C++ started off as an incremental improvement to a systems programming language (one that should never have been used to write user applications in), it gained wide currency because it just happened to be a useful shorthand for writing GUI applications in, it got widely taught and so it just morphed and morphed like the terror from some naff 50s sci-fi movie. Common sense, please -- some of us have do deal with the fallout from people who know all about how to write object oriented programs (but wouldn't necessarily know an object if they tripped over one...). This language has caused me so much grief over the years that if I'm in a position to make the decision I'll ban it (embedded programming and poor quality C++ are a particularly noxious combination!).
-
Saturday 23rd June 2018 22:13 GMT Libertarian Voice
It's not the features, it is how you use them that counts!
I write a lot of code in C++ that has to interface with C libraries and do not have the time nor inclination to create wrappers for every library as I would never get any work done. This is what happens in the real world; most companies are not prepared to pay you to write wrappers and would much rather employ programmers that have a reasonable understanding of C and can use it withing C++ programs and find workarounds where necessary.
The problem with c++ is not the code itself (you either use STL features or you don't, it is up to you); it is the evangelists who insist that you should write everything using strict OOP and every single available feature to write a hello world program.
The good thing about the STL is that it can save an awful lot of documentation if used properly, and OOP too has its place. Where I start to get a little annoyed with cpp is its determination to hide or mess around with what are basically pointers just for the hell of doing so, it makes no sense and over complicates things unnecessarily.
I like the language, I like the features and I like the fact that I can still use C code quite comfortably within, should the need arise or should it make the code more readable (which in many cases it does).