Celebrating 30th Anniversary of the First C++ Compiler: Let's Find Bugs In It

New submitter Andrey_Karpov writes: Cfront is a C++ compiler which came into existence in 1983 and was developed by Bjarne Stroustrup ("30 YEARS OF C++"). At that time it was known as "C with Classes". Cfront had a complete parser, symbol tables, and built a tree for each class, function, etc. Cfront was based on CPre. Cfront defined the language until circa 1990. Many of the obscure corner cases in C++ are related to the Cfront implementation limitations. The reason is that Cfront performed translation from C++ to C. In short, Cfront is a sacred artifact for a C++ programmer. So I just couldn't help checking such a project [for bugs].

Comments

Hardware requirements...

[__aaclcg7560]

I'm sure I got a PDP-8 somewhere in my back closet.

Re:Hardware requirements...

[gstoddart]

Just in case you need a space heater?

That must be some huge closet. The first VAX 11/780 I was was the size of two side by side ovens.

Re:Hardware requirements...

[Anonymous Coward]

Your "back closet"?

For whatever reason, that sounds like a euphemism.

Which, in turn, raises some serious questions.

Re:Hardware requirements...

[__aaclcg7560]

Since the first C++ compiler compiles to C code, a PDP-8 would be needed to test backward compatibility of the C code.

Re:Hardware requirements...

[__aaclcg7560]

Front closet is for coats and jackets after walking through the door. Back closet is typically a walk-in closet off the master bedroom for clothes and junk. In my case, I got five boxes of computer parts that I picked up over the years. Last year I got rid of the AT-to PS2 keyboard adapters and SCSI drives from the 1990's.

Re: Hardware requirements...

[Anonymous Coward]

Shit, I was an ENIAC once back in the forties. You should have seen me. I was freaking huge!

Re:Hardware requirements...

[Anonymous Coward]

oh, that's what that room is for! I use it for storing my butt plugs and ass dildos.

Re:Hardware requirements...

[kilodelta]

I'll see your VAX 11/780 and raise you a Data General Ecllpse MV9600U with 9 track tape drive and cpu cabinet taking up quite a lot of space.

Re:Hardware requirements...

[anjrober]

not the SCSI...i can't bear to throw away those cables....god what a pain in the ass they were....

Re:Bugs in C++ ?

[stooo]

Or features :
https://www.youtube.com/watch?...

C++ is...

[Anonymous Coward]

...a bug in and of itself.

Re:C++ is...

[bobbied]

Only if you know what you are doing...

Re:C++ is...

[stooo]

If you know what you're doing, you probably are already using another language.

Re:C++ is...

[serviscope_minor]

If you know what you're doing, you probably are already using another language.

Such as? I doubt that there's anyone not relying on C++. Never mind that every major browser (and a few minor ones) are written in C++. Many language implementations are in C++. And for those that are in C, well, all the major C compilers (LLVM, VisualStudio and now GCC of course) are written in C++.

Personally, I like the language. Oh I can whine about it all day and it has many warts, but the combination of efficiency, expressiveness, flexibility and static typing fit well with me.

Re:C++ is...

[Dutch Gun]

Nope, C++ is still a thing when you need to create really large, complex programs, and when efficiency still really matters. Here in the videogame industry, C++ absolutely reigns supreme. Nothing else even comes close. Large applications like MS Office are still written in C++, from what I'm told, as are *many* large applications. It's not just legacy stuff either.

C++ has the native performance of C, but is able to use powerful zero-cost abstractions that allow programs to scale up safely. For instance, if you write modern C++, it's almost impossible to write code that will stomp on random memory or leak resources, a real issue with C or older style C++ programs, yet that protection is completely optimized away and costs *nothing* at run-time (which I think is something many programmers don't properly appreciate).

An easy language to master? Absolutely not. It's a language that takes a long time to learn well, and it can be rather unforgiving at times, but it's great for what it does. C++ 11/14 has also really breathed new life into things as well, IMO. It's really amazing how much the language feels almost like it's using managed memory (e.g. garbage collection) now that I'm using smart pointers ubiquitously.

C++ is incredibly portable as well. My game engine works across several platforms, only a smallish percentage of the code is different between platforms, mostly for low-level graphics, audio, windowing, or other system calls.

It's stability as a language is legendary as well, and that's important for real-world projects that depend on it. You can probably still compile most the earliest C++ code on a modern compiler and expect it to still work, not to mention most C code as well.

I'd never claim C++ is the end-all, be-all of languages (I sound like I'm gushing, but I have plenty of complaints as well), but it most assuredly has a very long future with us, and for some very good reasons.

Re:C++ is...

[Anonymous Coward]

If you know what you're doing, you probably are already using another language.

Like what?

Java / C#? (yuck)
Javascript (LOL)
Python / Ruby? (yay, more fad languages)
Lisp / Haskell? (put down the bong, please)

Re: C++ is...

[Anonymous Coward]

I understand ruby being fad, but Python is def not a fad language. It's one of it not the best scripting languages we have.

Re: C++ is...

[Anonymous Coward]

> It's one of it not the best scripting languages we have.

Python isn't a scripting language per se, though it can be used that way. It's an interpreted programming language like BASIC.

Re:C++ is...

[rubycodez]

nonsense, plenty of large complex projects are written in C. Open source kernels or apache for example. Any C++ data structure or algorithm has a fairly straightforward C equivalent, "objects" in pure C are easy. No real reason to use C++ for anything, just introduces difficulty in debugging and maintenance.

Yeah, 20 years experience in c++ development here

Re:C++ is...

[Anonymous Coward]

>It's really amazing how much the language feels almost like it's using managed memory (e.g. garbage collection) now that I'm using smart pointers ubiquitously.

Add ref / release is a form of garbage collection.

Re:C++ is...

[Tyler Durden]

And what has C++ ever given us in return?

Zero-cost abstraction?

What?

Zero-cost abstraction?

Oh. Yeah yeah. It did give us that, that is true.

...And smart pointers.

Oh yeah. Smart pointers Reg. Remember what programming used to be like?

Yeah, all right, I'll grant you, zero-cost abstraction and smart pointers are two things that C++ has done.

And the portability.

Well yeah obviously the portability, I mean portability goes without saying, doesn't it? But apart from the zero-cost abstraction, smart pointers and portability...

Language stability?

Re:C++ is...

[Dutch Gun]

nonsense, plenty of large complex projects are written in C.

Where did I say they weren't? Obviously a lot of great stuff is written in C as well.

Any C++ data structure or algorithm has a fairly straightforward C equivalent, "objects" in pure C are easy.

Oh? I'd love to hear how you'd implement a ref-counted smart pointer in C. Or perhaps a scope based auto-lock/unlock mechanism. Tell me how you implement a reusable, generic container like a key-value map while remaining typesafe? How about any way at all to guarantee that a resource won't leak if you miss a function call due to some unexpected control flow? How about a way to avoid clobbering memory if you forget that you need to account for strlen() + 1?

Look, there's nothing wrong with C, but don't pretend it can do what C++ can. C is manual mode programming - the language itself is wonderfully simple and straightforward, but you have to do everything, including managing raw memory and properly cleaning up after yourself. C++ enables the compiler do a lot of automatic cleanup and safety checks, but has a cost in language complexity and obfuscation.

Yeah, 20 years experience in c++ development here

Congrats. 23 years C++ experience here.

Re:C++ is...

[serviscope_minor]

Tell me how you implement a reusable, generic container like a key-value map while remaining typesafe?

oooh! I know this one.

Please note, I'm not suggesting that it wouldn't be simpler and easier to do it in C++ with templates. Naturallt it would, but it's *possible* in C, and in fact I believe templates were part of the mechanism to formalise what people were doing in C anyway.

So basically, create a header: generic_vector.h

Do *not* give the header include guards.

Then do this:

#define VECTYPE float
#include "generic_vector.h"
#undef VECTYPE
#define VECTYPE int
#include "generic_vector.h"

And the header file looks like this:

typedef struct {
        VECTYPE* data;
        size_t size;
        size_t nelem;
} generic_vector_##VECTYPE;

static int generic_vector_##VECTYPE##_insert(VECTYPE v)
{ //Logic goes here...
} /* etc */

An alternative is to have the header file define a colossal macro and then do:

GEN_VEC(float)
GEN_VEC(int)

but I generally prefer the former since the debugging is much easier, and it's the least nasty option of the two.

So there you go, it is possible to make generic, typesafe container in C by severely abusing the preprocessor. Obviously a key/value one would be more complesx, and have multiple #defines, one each for the two types and then more for the comparator function for ordering.

I invite any C fan to claim that lot would be easier to read then the equivalent C++ code...

Look, there's nothing wrong with C, but don't pretend it can do what C++ can. C is manual mode programming - the language itself is wonderfully simple and straightforward, but you have to do everything, including managing raw memory and properly cleaning up after yourself.

This is one of the things I don't understand. If you're programming in C you're *programming*. IOW automating things that could be done by hand. Why would you not want to automate away half of the work?

Re:C++ is...

[Anonymous Coward]

Congrats, you just sketched out a non working version of std::vector in 20 lines...

Re:C++ is...

[serviscope_minor]

Congrats, you just sketched out a non working version of std::vector in 20 lines...

That was kinda the point: to show it's possible to do such stuff in C.

Re:C++ is...

[rubycodez]

You are so funny, all those things you mention exist in the libraries of major scripting languages with constructs made in pure C

You're making an argument for why those that love needless complexity shouldn't be allowed to design languages

Re:C++ is...

[The Evil Atheist]

Where's the automatic resource cleanup?

Re:C++ is...

[serviscope_minor]

There isn't, but I think the OP asked for type safety and generality, not resource cleanup.

Seriously, why is everyone going full pedant overload on this? Generic programming is perfectly possible in C, if extremely unpleasant. Templates were in no small part designed to allow people to use something more pleasant and obvious than macro fuckery.

Re:C++ is...

[The Evil Atheist]

Resource cleanup is definitely part of generality. I would argue even part of type safety. Just because it's overlooked doesn't mean it isn't a crucial part of it. Clean generic programming is only really possible with value semantics, and value semantics means resource cleanup for non-trivial types.

Re:C++ is...

[serviscope_minor]

Resource cleanup is definitely part of generality. I would argue even part of type safety

No, I disagree. The generality and type safety was really about generic programming, as in can it be used on a variety of types without messing aronud with void*. Type safety is something quite specific and doesn't in any definition I've seen include resource cleanup.

Just because it's overlooked doesn't mean it isn't a crucial part of it.

I don't think it's overlooked but it's not a part of type safety. Type safety is about whether you can have type violations, not whether you run out of memory because you forgot to free something.

Clean generic programming is only really possible with value semantics, and value semantics means resource cleanup for non-trivial types.

You can emulate that all in C if you like with abuse of macros. But C idiomatically tends to work with pointers more, which are really reference semantics. I mean sure you might leak if you're not super-super careful but you can get type safety and genericity in C.

If I had to choose between losing templated from C++ and losing destructors, I'd almost certainly lose the latter, since you can amulate the former badly and with more pain but nonetheless reasonably completely with macros, but there's nothing you can do about the latter.

Obviously that's a silly hypothetical.

Re:C++ is...

[The Evil Atheist]

Type safety is something quite specific and doesn't in any definition I've seen include resource cleanup.

Which is my point. Just because it's overlooked such that it doesn't figure into other people's definitions doesn't mean it isn't necessary. We have a lot of experience with generic programming, and resource cleanup has been found to be a requirement.

not whether you run out of memory because you forgot to free something.

Memory cleanup is only a small part of resource cleanup. This point has been repeated to death.

But C idiomatically tends to work with pointers more, which are really reference semantics. I mean sure you might leak if you're not super-super careful but you can get type safety and genericity in C.

Which is why actual generic programming isn't possible in C, because it can't emulate value semantics for complex types. If you have to be super-super careful, then it's not generic.

Re:C++ is...

[serviscope_minor]

Which is my point. Just because it's overlooked such that it doesn't figure into other people's definitions doesn't mean it isn't necessary. We have a lot of experience with generic programming, and resource cleanup has been found to be a requirement.

Resource cleanup is useful both with and without generic programming. You can write typesafe (this has a specific definition), generic code with manual cleanup or with automatic cleanup. For example, a std::vector is typesafe, in that you can't have type violations (unless you screw with casting---C++ isn't the best example), generic in that it works for all T, but it won't clean up whatever those T*s point to.

Resource cleanup is simply an orthogonal concept to type safety and genericity.

You can write templates with incomplete resource cleanup (above) and it's certainly generic (which means works on more than one type) and typesafe (which means you can't store a ofstream* in a vector).

Memory cleanup is only a small part of resource cleanup. This point has been repeated to death.

Picking one example resource out does not make my example incorrect. So well done for ignoring the point and making a tangential, irrelevant criticism rather than addressing the point I was making.

Which is why actual generic programming isn't possible in C,

Except it is, using the definitions of "generic" that everyone else uses.

because it can't emulate value semantics for complex types.

Plenty of languages implement generic programming with reference semantics just fine. A vector> is essentially reference semantics, on Ts, and that's certainly an example of generic programming.

If you have to be super-super careful, then it's not generic.

I don't think you understand what generic programming is. It's not about care it's about parameterization over types. And you can certainly parameterize over types in C, with sufficient effort.

Re:C++ is...

[The Evil Atheist]

Resource cleanup is useful both with and without generic programming. You can write typesafe (this has a specific definition), generic code with manual cleanup or with automatic cleanup.

But generic programming is not useful without resource cleanup. Generic programming algorithms, as I keep saying, relies on value semantics. If the algorithms are working on things that, say, have mutable state, then the generic algorithm breaks. Value semantics means type safe automatic resource cleanup becomes a necessity and thus should be included in the definition. People only resist it because it would mean their language can't be generic.

For example, a std::vector is typesafe, in that you can't have type violations (unless you screw with casting---C++ isn't the best example), generic in that it works for all T, but it won't clean up whatever those T*s point to.

No, that's why you store objects in vectors, not raw pointers. If you store objects in vectors, it will clean up all Ts, including smart pointers.

Plenty of languages implement generic programming with reference semantics just fine.

No, they don't. eg Java's generics aren't generic. They're just syntactic sugar for type casting.

Except it is, using the definitions of "generic" that everyone else uses.

"Everyone else" uses incomplete definitions of generic. It's incomplete given the experience of generic programming, namely in C++. Your "generic vector" does not allow generic algorithms to operate on them because of reference semantics and non-generic resource cleanup.

It's not about care it's about parameterization over types. And you can certainly parameterize over types in C, with sufficient effort.

The parametrization is incomplete if it doesn't include type-aware cleanup (and copy and move and even swap).

Picking one example resource out does not make my example incorrect. So well done for ignoring the point and making a tangential, irrelevant criticism rather than addressing the point I was making.

Really? But you thought nothing of reducing "resource management" down to a leaked memory strawman completely irrelevant to the larger picture of value semantics. I love when people accuse me of apparently doing something when they were the ones to actually do it first.

Re:C++ is...

[serviscope_minor]

But generic programming is not useful without resource cleanup

That's trivially false. std::sort does not cause any allocations or deletions of the type T objects.

Generic programming algorithms, as I keep saying, relies on value semantics

You can keep saying that and you'll keep being wrong. The definition of "generic programming" is parameterisation of types:

https://en.wikipedia.org/wiki/...

No, that's why you store objects in vectors, not raw pointers. If you store objects in vectors, it will clean up all Ts, including smart pointers.

That's great unless you don't want it to, e.g, if you're storing iterators in a std::vector, aka pointers, i.e. reference semantics.

No, they don't. eg Java's generics aren't generic. They're just syntactic sugar for type casting.

Who cares how it's implemented underneath? You can make classcontaining a vector and wrap it so that operator[] always returns the T boxed up by the any. That's still generic code. Java still allows you to parameterize stuff over types. Not the world's best generics sure, but it's still type parameterization. C# is similar but goes rather further because it has generics in the VM so it doesn't need to do type erasure like Java does.

Nonetheless you now have to modify your silly semantic fiddling yet again because C# now fits your definition (not type erasure and runtime casting) but is reference based.

"Everyone else" uses incomplete definitions of generic. It's incomplete given the experience of generic programming, namely in C++.

You know, except not. If literally everyone else is using a different definition from you, then it is you that are wrong not them. Definitions are simply language and language is ultimately defined by how it is used. If you perversely insist on different definitions of terms from everyone else then you're always going to be talking at cross purposes.

Your "generic vector" does not allow generic algorithms to operate on them because of reference semantics and non-generic resource cleanup.

Tell me, what cleanup does std::sort require? The thing you're talking about is containers which is literally a subset of generic programming. Furthermore containers will work perfectly on all structs without pointers internally, which includes a lot of useful cases. The only time they don't work perfectly is if those pointers (and other resource handles) need cleanup: at that point you have to do the clean up yourself.

Of course you could always make the C style std::vector call a user-specified cleanup function. By making it one of the #defines rather than abusing void* it's even type safe.

All you're arguing is that without automatic resource cleanup, certain generic containers in certain cases require more effort.

The parametrization is incomplete if it doesn't include type-aware cleanup (and copy and move and even swap).

Reference heavy languages don't have the concept of move, because they don't need it. You can move any C struct with memmove or memcpy. As long as you don't clean up the sets of handles in both copies you're fine. That is also the way D works in a lot of cases. I invite you to tell me why D doesn't have generics...

Really?

Yes really, because it's easier to say "run out of memory" than "run out of memory or file handles or semaphores or thread handles or shared memory segment keys or inodes and so on". The point is precisely the same. It's also not a straw man because it's actually a real problem (running out of memory) that will really happen and almost certainly sooner than anything else if you never free. You well know this, but for some reason you want to engage in idiotic pedantry and fiddling with weird corner cases of definitions than have an actual discussion.

Speaking as a C++ programmer...

[Anonymous Coward]

"Sacred Artifact"? Are you kidding?

I will happily agree that the language and compilers were both pretty awful back then. The worst warts have been beaten out now, and it's a pretty capable language in the main but this is now. 1990s C++ was horrible.

what to be thankful for 30 years on

[Anonymous Coward]

I think C++ was great when it was the best tool we had, but it's time is past now that we have more modern tools and techniques.

The basic problems with it are (1) it is wildly arcane, (2) it is an unmanaged language that gives low level access without adequate tools to guard that access. The problems with this have been glaringly obvious over the past decades, with buffer overruns in C++ code one of the biggest security headaches of the last decades.

Some argue that "really really good programmers don't do that", but actual history proves them wrong, and even if it was true, most programmers are not in the upper 1% who might be able to do that. We need tools that normal programmers can use safely.

C++ isn't much taught in universities any more so it will die out. It had a good run, but times change, and the world moves on. Good to look back and see where we came from though - those who don't understand history are condemned to repeat it,a s they say

Re:what to be thankful for 30 years on

[bobbied]

But it's small and fast when you use it right..

C++ is but a tool we use to get our jobs done. Every tool has it's limitations, provisos, flaws and a purpose. When a tool is placed in the hands of a skilled craftsman using it for it's intended purpose it produces excellent results, but if it's used by somebody without the necessary skills, or for a task it is not designed to do, the results can be horrid. C++ may be dated, but for some problem domains it remains the tool of choice. You don't write device drivers in Java for a reason.

The wise programmer keeps as many tools in his tool box as possible. He sharpens them and maintains them and keeps adding the new and useful tools he finds. He knows the intended purpose and best use of his tools and selects the appropriate tools for the job at hand. All to often, young bucks show up to work armed with only ONE tool shiny and new, thinking that it is the only tool they need for any job. They deride the old salts who use the "old" tools well and make fun of the well warn, old tools they use. "Use this new shiny tool," they say, "It's the only tool you need." While the old experienced guys chuckle and shake their heads, remembering when they too said similar things and try to teach the younger ones that there is value in putting tools in the box...

Re: what to be thankful for 30 years on

[Anonymous Coward]

Of course, none of that is true; yours are the mere ravings of the ignorant.

Re:what to be thankful for 30 years on

[Anonymous Coward]

it is an unmanaged language that gives low level access without adequate tools to guard that access.

Uh, have you heard of smart pointers? Or RAII? Have you used C++ in the last 5-10 years... at all, actually?

Re:what to be thankful for 30 years on

[tibit]

Exactly. Modern C++ should mostly read like a high-level managed language would, not C.

Re:what to be thankful for 30 years on

[Anonymous Coward]

C++ isn't much taught in universities any more so it will die out.

Hahaha, you're cute.

Imagine if it had never been done

[Anonymous Coward]

What a better place the world, and thousands of CompSci 101 classes, would have been.

Re:Imagine if it had never been done

[__aaclcg7560]

Without C++ there would be no Java. Since my community college couldn't afford a new Microsoft site license, I had to learn every flavor of Java for all my programming courses. Meh...

Re:Imagine if it had never been done

[Anonymous Coward]

Did you learn Java real time ? If you did what was your college ?

Re: Imagine if it had never been done

[Anonymous Coward]

without c++ and unix we might run some sort of oo algol systems, which have been much more secure rhan the c kernels since 1960. c and unix have been foisted on this world in order to make it less secure. of course, there exist opposite definitions of security...

Re: Imagine if it had never been done

[__aaclcg7560]

Security was never the primary design goal for C, UNIX or the Internet. The technology for the last half-century got "foisted on this world" because it worked and worked quite well.

Re:Imagine if it had never been done

[Anonymous Coward]

Without C++ there would be no Java. Since my community college couldn't afford a new Microsoft site license, I had to learn every flavor of Java for all my programming courses. Meh...

GCC was free the last time I checked and a free graphical frontend should be possible to find as well. Notepad++ would do (not 100% of license for a college though). Using java instead of C++ for license issues sounds more like an excuse to me, partly because in my university days Microsoft donated licenses to the students and I got free windows and stuff. After all they wanted the new engineering students to be used to microsoft products when they joined the software workforce.

I learned Java as well, not due to costs, but because the cross platform code made it "the only language you will ever need in the future". Everybody hated it and preferred C or C++ (C was actually surprisingly popular compared to C++) and to this day I haven't had the need to use java even once since I graduated. I use C++ for performance and scripting langauges for whatever uni figured I should use Java for.

Re:Imagine if it had never been done

[__aaclcg7560]

While Microsoft may donate to the universities, it required payment from the community college that I attended. The dean taught C/C++ and GCC in the Linux Admin classes. The administration refused to go with open source programming because Microsoft Visual Studio was the industry norm and Java was the next industry norm on the horizon. When the funding issue did get resolved, none of the classroom computers could run VS .NET as the hardware was too old. I never used Java after graduating from school. These days I use Python and occasionally Cython (C compiler for Python).

Re:Imagine if it had never been done

[wbo]

This sounds like the people over that particular program at your community college didn't really understand what options were available.

The Express versions of Visual Studio .NET has been free for quite some time for personal or academic use (starting with Visual Studio 2006). Even before that, the Microsoft C++ command-line compiler has been available as free download as a part of the Windows SDK/Platform SDK since the release of Windows XP (if not before).

It is true that the Windows SDK does not include an IDE of any kind but it includes the compiler and linker, so all you really need is a text editor to use it to develop programs.

Re:Imagine if it had never been done

[__aaclcg7560]

I don't think Notepad (or Notepad++) has the same cachet as Microsoft Visual Studio on a resume. Getting a job is the whole point of learning computer programming at a community college. If you know C/C++ but don't know MSVS, you're not going to get a job. The same thing for Java if you don't know Eclipse or Netbeans.

Re:Imagine if it had never been done

[Anonymous Coward]

I can confidently say that I don't hire people who know the IDE. I don't care if they know the IDE. The IDE should take all of about 10 seconds to grok. And a complete newbie can make it without a true understanding of the IDE with just a few simple walkthroughs of some basic tasks.

I hire people that know how to program, and preferably are familiar with the syntax of the language the current project is written in. (These days, that's mostly C# and T-SQL, since I work at a Microsoft shop.)

And if I'm looking for a C# developer, and I see that they know C/C++ as well, I'm far more likely to hire them than a guy that doesn't know how to even think about what's going on behind the scenes in .Net.

(The same goes for Java, its various IDE's, and the behind-the-scenes stuff in the JRE.)

Re:Imagine if it had never been done

[__aaclcg7560]

Tell that to the HR drone who writes up the job description. I wouldn't be surprised if Microsoft Visual Studios is listed as a requirement for the job applicants you want to interview.

Re: Imagine if it had never been done

[Anonymous Coward]

in the words of mr putin: the internet was created by the cia for the cia.

he is spot on, except that he mixes up cia and nsa/jcs/stratcom.

cyberwar for cyber warrior careers and world domination !!!

Re: Imagine if it had never been done

[__aaclcg7560]

The Internet was created by DAPRA. The civilian application was a byproduct.

https://en.wikipedia.org/wiki/DARPA

Re:Imagine if it had never been done

[angel'o'sphere]

If you know C/C++ but don't know MSVS, you're not going to get a job. The same thing for Java if you don't know Eclipse or Netbeans.
That is nonsense. No one cares what IDE I use.
And I switch to an unknown IDE immediately.
What the fuck should be the difference between them?
In Java there is basically none at all and if we use C++ all IDEs generate a makefile.
If you believe you did not get the latest job because you did not know the IDE you have a serious problem.

Re:Imagine if it had never been done

[__aaclcg7560]

If you believe you did not get the latest job because you did not know the IDE you have a serious problem.

You have obviously never dealt with a recruiter or HR drone following a checklist. If you didn't have what's on the checklist, you didn't get the interview or job. I was once turned down for an interview because I didn't know "Red Hat GUI" for a Linux job that was 99% command line work, which I thought I was perfect for because the Linux command line 99% of the time. Since I didn't know "Red Hat GUI" and that box couldn't be checked off, the recruiter hung up on me.

Re:Imagine if it had never been done

[Anonymous Coward]

HR drops people for reasons, which makes no sense at all. I was called to a job interview, which then got canceled because they figured that since I'm used to the big city, I would leave their farming community quickly because I would be bored instantly. At the time I lived in a town with 16k people and if I got the job I would move to one with 20k people. They knew that I had local knowledge and relatives in their area, meaning I would be aware of what it's like to live in that area. When asking what they meant by the big city, they mentioned a city I never lived in and never want to live in.

I called the manager of the department with the open job and spoke to him about it. Yeah I wanted that job and didn't really take some HR no for an answer. It didn't provide me with the job, but I got the impression that I started a fight between the development and the HR departments. It still upsets me though because it was the dream job for me and I'm quite sure they wouldn't get a better candidate. Master thesis spot on for the assignment and how often do you get an engineer with matching skills and which speaks the both foreign languages you need? Maybe they didn't believe that I actually matched every single requirements they came up with, even the "it would be nice to know, but not required" list, but I did match everything. It really was the perfect job for me.

Re:Imagine if it had never been done

[angel'o'sphere]

I don't get called by drones like that.
When I have a phone interview I'm usually hired after it.
Next time simply cheat and face palm when you are sure it is just a drone.

Re:Imagine if it had never been done

[pi_rules]

Recruiters generally have no idea what they're talking about. You kind of have to pad your resume and language you use about yourself and skills against that.

This is OLD advice (I haven't had to make a resume in 15 years) was to list every possible interpretation of your skillset for the resume consumed by headhunters. Example:

- JDBC
- Java Database Connections
- C++
- Microsoft Visual C++
- Unix
- HPUX
- Solaris
- Linux
- PHP
- PHP4
- PHP5

The headhunters are just scanning and checking boxes. If you feel "icky" about saying you know MSVC++ when you haven't used it just grab the freebie compilers and throw some stuff at it. There... legit.

Re:Imagine if it had never been done

[__aaclcg7560]

If an Indian recruiter calls with an incomprehensible accent calls, I answer "yes" to every question on their script. If they get confused by a "yes" answer and repeat the question, I answer "no" for that question and "yes" to the remaining questions. Surprisingly, this works every time. I've gotten a few interviews this way.

Re:Imagine if it had never been done

[__aaclcg7560]

My five-page resume that I put on the job search websites is loaded with buzzwords from the last 20 years. Recruiters love this version. I give the hiring managers my two-page resume that summarizes the last three positions and/or last three years. For my current I.T. job, I had to provide my long resume because 10 to 15 years of I.T. experience was a requirement.

Re:Imagine if it had never been done

[Anonymous Coward]

Visual Studio Express has been valid for educational use since at least 2007. There's also Qt Creator, or Eclipse CDT, or Netbeans. If this was less than a couple of years ago, Jetbrains CLion is free for both classroom use and anybody who can prove they're a teacher or student. Code::Blocks has been around forever, as has Dev-C++ (and more recently wxDev-C++). TL;DR: Either you or your college just spouted a bunch of bullshit.

Blogspam

[Anonymous Coward]

This "new submitter" is the "science adviser" of the company who wrote that blog post, of which the main point is to sell you their product.

Re: Blogspam

[Anonymous Coward]

The funny thing is that on reddit, this guy and his employees have been blogspamming his product for years, hiding it in posts like "analysis of this project", or "finding bugs in that project."

Despite having multiple shill accounts like "Coder_CPP" and "resistor54" (among others), the community barely catches on and we have to suffer through cleverly placed product placement every few days.

Part of how they got away with it for so long is their reputation is so high as they have their own subreddit http://reddit.com/r/viva64 where they post links to random articles (and their own) and the shill accounts upvote each other.

I've been following him for a while; in addition to slashdot, he's managed to post shill articles on Intel.com (which I didn't know was a thing), medium.com (which apparently anyone can post an "article" to and it looks legitimate), and others.

Now he's made it to slashdot. Congratulations, Andrey, you're now going to infect yet another site with blogspam and people will be none the wiser.

Re: Blogspam

[Anonymous Coward]

so I'm just some anon guy too, but in general I've found that code quality everywhere is so shitty it is impossible to call enough attention to things you should be doing in order to make code better.

These are not lazy shills, they at the least show value by finding bugs and potential bugs and showing how careful analysis can find bugs in code.

What value have you provided?

Re: Blogspam

[Anonymous Coward]

But in this case, his product is actually good. We have used it for years. Saved us a fortune.

Re: Blogspam

[tibit]

That's true, but even if I wanted to throw money at them, I can't. They don't offer a stand-alone product. It's a Visual Studio plug-in. I don't use Visual Studio, other than for the compilers, so - meh.

Isn't C just a glorified macro assembler?

[Anonymous Coward]

Before C++ came around, wasn't C just a glorified macro assembler?

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

And before that...

https://en.wikipedia.org/wiki/BCPL

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

It still is.

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

Before C++ came around, wasn't C just a glorified macro assembler?

Not exactly. It was intended to be an actual compiled language but one with as little overhead as possible and the ability to touch the hardware easily. It's considered a "middle level language". Where low level languages would be various assemblers and what not. High level languages (i.e. most other compiled language) deliberately abstract away the low level functionality to make writing applications easier. C was designed specifically as an in-house tool at Bell Labs for rewriting Unix and escaped sometime in the late 60's/early 70's. It was and always will be a compiled language, albeit one with only a very small base of core functionality.

When they wrote it, Kernighan and Ritchie discarded most of the overhead that came with other languages. The linking of pointers to arrays and array arithmetic simplified the compiling while providing the bare minimum of array functionality. The lack of pretty much any built in functions made the language simple and compact. Putting all that functionality in libraries means you only needed to include just the pieces you used. And if you didn't need something, the language didn't force you to link it in. The language gave you just the few pieces that were absolutely necessary and you were responsible for the rest. The standard libraries that evolved after that are what gave C the ability to be a general purpose language.

C is a great language for writing small, tight, efficient, low level programs as long as you know what you're doing and are willing to work with just a few small, sharp tools. It still has it's place in embedded systems and for writing operating systems (or at least the kernel). Beyond that, it's really quite limited. But no, it's not just a macro assembler. It is more than that.

Re:Isn't C just a glorified macro assembler?

[bobbied]

Yea, so? But it hid the details of the processor programing model from the programmer. So C programs became CPU independent, all you needed to do is create a cross compiler for your new CPU. It's just abstracting away the hardware dependence of Macro assemblers...

Java is just a way to abstract away the memory management issues of C++ (well it's at least partly that..)

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

No.

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

Dammit, meant to say _C++_ is a glorified macro assembler. A lot of the C++ I write would probably be easier in macro assembler. At least there, I can rely on two's complement arithmetic to work, and the assembler won't silently delete arbitrary parts of my code.

Re: Isn't C just a glorified macro assembler?

[Anonymous Coward]

c and unix compared to algol mainframes: like coke and home made apple juice.

a fucking retardation.

Re:Isn't C just a glorified macro assembler?

[lgw]

Mwh, the only thing C gives you over a good macro assembler is parsing of arithmetic expressions, and a somewhat processor-independent syntax. It's a nice layer of abstraction now that compiler optimization is so good, but originally was a real pain if you needed performance. (No one hand hand-code optimal assembly against a modern architecture, so you the performance arguments have swapped ends these days).

Re:Isn't C just a glorified macro assembler?

[lgw]

You do realize there are no "memory management issues" in modern C++, right? Java abstracts away the memory management issues of C, and of C++ written like C.

The advantage of Java and C# is the easier learning curve. C++ can be bizarre and arcane, while the managed languages are simpler to get right, and so you can far more easily hire programmers who won't screw everything up.

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

When C was first created, there was little to no compiler optimization available. The lack of overhead in the C language meant that the compiler added little to no bloat over the code that was written. What you wrote is what you got.

Of course, that meant the inefficiency and bloat came in when average programmers started to implement more complex data and algorithms without knowing how to do it efficiently...

Re:Isn't C just a glorified macro assembler?

[lgw]

The abstraction in C made writing hand-optimized code a guessing game in the early days. Rather than just writing what you wanted, you had to guess what would be compiled into what you wanted, and check the object code to see if you guessed write. How to rotate a register, how to get both the result and remainder of a single division instruction, that sort of thing. Often people just inlined the desired assembly.

"What you wrote is what you got" was not how veteran assembly devs saw it - there was a lot of arcane C syntax (none of it standardized in the early days) needed to get what you wanted.

None of that is relevant any more, of course. These days the struggle for efficient code is more about understanding the arcane twists of each kernel (e.g., how do I allocate a buffer from userland to ensure no-copy I/O in this environment).

Re:Isn't C just a glorified macro assembler?

[bobbied]

Oh yes there are memory management issues in C++, you still have to take care of it unless you only use stack and static storage. There are memory management issues in Java too, but most don't understand why they exist or how to avoid them (thankfully most don't run into the issues, but they are there).

What you are talking about is that we have ABSTRACTED memory management tasks by going through libraries and templates. The "problem" hasn't been "fixed", all we've done is make it easy for programmers to not think about it if they wish. That doesn't mean the programmer shouldn't be aware of how C++ manages memory and how your libraries and templates deal with it. It's the same problem that C has, only it can be a lot worse in C++ because many programmers don't fully understand when the compiler is going to run your constructors and destructors.

Sure, Java (aka C#), seems easier to you. It's what they teach in school because you can ignore whole swaths of information about what the hardware is really doing because it's abstracted away. But that doesn't mean C++ is old and arcane, nor is it bizarre if you truly understand what is going on beneath your programs feet. Java and C# just isolate you from all this by abstraction, but you pay a price for the convenience. Java and C# are slower, MUCH slower, and they use a lot more resources when they run. You also don't have much control over memory management, in Java and C#, everything pretty much stops when the garbage collector is running and there is not much you can do about it. In C and C++ you can write code that you know won't be interrupted for garbage collection, which may not be important to you, but it is important to some of us who are writing time sensitive systems with strict time budgets.

Admit it. Java and C# are only tools, just like C and C++. Each is a the preferred solution for specific tasks and are not better or worse than the other. They are just tools that bring their unique features to the table. A wise programmer has as many tools in the tool box as possible. He keeps them sharp and hones his skills so he can skillfully apply the BEST tool for the job at hand.

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

Well sure. Any time you had a project that already mixed C and assembly, there already was a lot of detailed work to manipulate the processor very specifically and no small amount of just inlining the assembly code rather than figuring out how to write C syntax. And I've done my share of that, mostly early in my career. But compared to high level languages, C offered substantial efficiency improvements at the cost of having to "roll your own" on just about everything you wanted to do. And more often than not, the compiled C code was "good enough" to get the job done.

Re:Isn't C just a glorified macro assembler?

[lgw]

What you are talking about is that we have ABSTRACTED memory management tasks by going through libraries and templates. The "problem" hasn't been "fixed", all we've done is make it easy for programmers to not think about it if they wish.

Yeah, sure, that's all any programming language ever is: layers of abstraction over assembly. My point was, from a practical perspective, you don't worry about memory leaks in modern C++ code any more than you do in modern Java code. But of course Java only offers the "no leaks" way, which in C++ you must discover the "no leaks" way, giving Java the easier learning curve. (You can still get memory leaks with anything, of course, if you try hard enough, but I'm talking about the 99% case here).

But that doesn't mean C++ is old and arcane, nor is it bizarre

Placement new. Weak references. Static initialization quirks (so many lock management and reference counting bugs caused by that over the years!). A Turing-complete templating language, so that you can turn your compiler run into a game of Tetris. Heck, just the fundamental need to understand that vectors will copy their member as they grow, and so you need to use the appropriate kind of smart pointer for that (which has changed, what 3 times now over the life of the language).

Bizarre and arcane. All there for good reason, to solve problems that can't otherwise be solved, but bizarre and arcane.

Java and C# are slower, MUCH slower, and they use a lot more resources when they run.

I used to work on code where that mattered, back in the day. Now everything is I/O bound and horizontally scalable, in my world, and CPU load is around 5% average in my service fleet.

OTOH, guys working in the IOT world with devices with 4K of memory still love C.

Admit it. Java and C# are only tools, just like C and C++

Do you see anyone around here saying different?

Re:Isn't C just a glorified macro assembler?

[lgw]

Sure, I get your point, but there were plenty of fast low-level (or "mid-level" if you want to call it that) languages back in the day, which have mostly faded into obscurity or oblivion now*. C was popular and lasting IMO because it was straightforward, because it felt like a sort of cross-platform macro-assembler. Just a few arcane quirks to figure out for the instructions C didn't represent directly.

*My worst coding project ever was supporting legacy PL/S code. (Made extra fun since IBM never released the compiler so I was bugfixing the generated object.) Ug - give me C any day!

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

Yeah, I still don't know what made C stand out over other languages. I never really got to know other languages that were around at the time. I bet the ability to cross compile between platforms was a significant contributor. That and it didn't obfuscate much on you so you could mostly know what was going on for every line of code you wrote.

It still amazes me the legacy that an escaped Bell Labs experiment like C has had with syntax of so many languages. C++, Java, C#, csh, Perl, Ruby, et al trace their syntax roots to C, which I believe was derived somewhat from B and BCPL (and others?).

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

What made C stand out is that it was the systems language for Unix, which became the lingua franca of academic computing during the late 70s/80s, because it came with source code and relatively benign licensing terms (for the time). This is, you could teach both operating systems (using Unix) and compilers (using C) classes using these systems, since the code base was available and understood, an attractive prospect in academia. Which means generations of students were exposed to it and carried it to their professional careers.

The syntax of C was not remarkably creative, since it was entirely based on Algol's, which is the language to which all those examples you mentioned actually trace their roots.

 

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

C did not hide the details of the processor in the least. For the most part, C behaves like a portable assembler for a virtual PDP target.

Re:Isn't C just a glorified macro assembler?

[david_thornley]

Way back when, there were lots of different architectures, and they had their own C-level languages (CDC system programmers used Cybol, for example). C is the one that survived, because it was the language of Unix, and Unix caught on. It's multiplatform because Unix is. That gave it staying power. Nobody uses Cybol anymore, because it was tied to an architecture that just died.

Re:Isn't C just a glorified macro assembler?

[david_thornley]

There are memory management issues. Passing around auto_ptr and unique_ptr is tricky. shared_ptr can be a performance drag, as its memory accesses aren't necessarily local. Smart pointers can create a circular data structure just like in Java, except that good garbage collection in Java will collect that structure once it's inaccessible. If you're doing more than just mechanically using smart pointers (placement new, for example), there's other hassles.

I love the language, but I can't recommend using C++ heavily without knowing where the bodies are buried.

Re:Isn't C just a glorified macro assembler?

[bobbied]

What you are talking about is that we have ABSTRACTED memory management tasks by going through libraries and templates. The "problem" hasn't been "fixed", all we've done is make it easy for programmers to not think about it if they wish.

Yeah, sure, that's all any programming language ever is: layers of abstraction over assembly. My point was, from a practical perspective, you don't worry about memory leaks in modern C++ code any more than you do in modern Java code. But of course Java only offers the "no leaks" way, which in C++ you must discover the "no leaks" way, giving Java the easier learning curve. (You can still get memory leaks with anything, of course, if you try hard enough, but I'm talking about the 99% case here).

Um, like it or not, memory leaks still exist in Java and it's not that hard to stumble into code that causes them. The problem is that most people don't understand the parts that are abstracted away, they don't think they need to, so it's easy to stumble over your shoelaces and not know why. Yea, Java makes it a bit harder to bleed memory, but it doesn't eliminate the problem.

But that doesn't mean C++ is old and arcane, nor is it bizarre

Placement new. Weak references. Static initialization quirks (so many lock management and reference counting bugs caused by that over the years!). A Turing-complete templating language, so that you can turn your compiler run into a game of Tetris. Heck, just the fundamental need to understand that vectors will copy their member as they grow, and so you need to use the appropriate kind of smart pointer for that (which has changed, what 3 times now over the life of the language).

Bizarre and arcane. All there for good reason, to solve problems that can't otherwise be solved, but bizarre and arcane.

One man's garbage is another's treasure. You need to understand what you pay for all this convenience. I'm not saying Java doesn't have it's good points. All I'm saying is that there are time when other tools are better choices. I use Java, I use C++, heck I use Perl and Python too, but part of my job is to know what tool works best for which problem and have the skills to effectively apply the tool necessary.

Java and C# are slower, MUCH slower, and they use a lot more resources when they run.

I used to work on code where that mattered, back in the day. Now everything is I/O bound and horizontally scalable, in my world, and CPU load is around 5% average in my service fleet.

OTOH, guys working in the IOT world with devices with 4K of memory still love C.

You work on large machines, great. Some of us work in constrained places, where size, weight, power consumption and heat dissipation are primary design constraints. I work in embedded systems where I don't have the luxury of just inserting more memory or a faster processor and where a Java interpreter would NEVER fit, much less run. No, I'm not writing device drivers, but I do have design constraints that make using Java a problem. So I say again, you pick the tool for the job at hand, so you want as many tools in the box as you can get.

Admit it. Java and C# are only tools, just like C and C++

Do you see anyone around here saying different?

Yes, I see you defending Java while talking down C++ and I'm not sure you know the details well enough to make the claims you have. Java DOES have memory leaks, they are just not common because the JVM takes care of most of that for you. Plus, all the convienince comes at a price, all the abstraction costs you. You may not care for your application, but it's still there. I've always been saying "Use the best tool."

So, shall we discuss Emacs verses VI next?

Re:Isn't C just a glorified macro assembler?

[Darinbob]

A can see why you're anonymous.

Re:Isn't C just a glorified macro assembler?

[Darinbob]

Ie, you can hire dumber programmers in order to make dumber programs.

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

> C did not hide the details of the processor in the least.

Okay, how do you know your word size?
Big-endian or little-endian?
Segments for flat address space?
Interrupt I/O or memory mapped?
Floating-point unit built in?

If you can tell any of that from generic C code, then you might have a point.

Programming in C is nothing like assembler, I wish people would stop propagating this myth. Pointers and ++/-- don't an assembler make.

Re:Isn't C just a glorified macro assembler?

[angel'o'sphere]

except that good^H^H^H^H every garbage collection in Java^H^H^H^H any language will collect that structure once it's inaccessible.
FTFY.

Re:Isn't C just a glorified macro assembler?

[angel'o'sphere]

Yes, it was. However they did not call it "glorified macro" but "portable".

No idea why so many answers to you pretend it wasn't.

The inventors of C defined it that way.

OTOH: what is wrong with that :D

Re:Isn't C just a glorified macro assembler?

[jrumney]

The lack of pretty much any built in functions

There's sizeof(), but that may have been a later addition.

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

sizeof() is an operator, at least syntactically. Under the hood it works like a function, but only for arrays at runtime. Otherwise it works at compile time.

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

The sizeof() function may have the syntax of a function but it's evaluated at compile time. It doesn't actually compile into a function call.

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

It really wasn't. C was developed out of B and BCPL, largely so they could implement types and data structures beyond what they could do in assembly. They already had an assembler, and if they were interested in "glorifying" it with syntactic sugar, they would have simply added something like the C preprocessor.

C wasn't even portable in the beginning, according to Ritchie's The Development of the C Language - interest in that aspect came later.

That paper is a fascinating read. It's a window into the goals they were trying to reach for their system, and they certainly didn't have a vision of how ubiquitous C would become - it was simply a tool for their own use, to make their jobs simpler.

Re:Isn't C just a glorified macro assembler?

[tibit]

auto_ptr doesn't exist, as far as anyone sane is concerned. unique_ptr is not passed around, it's moved around. shared_ptr is supposed to be used with make_shared.

I fully agree that using C++ without understanding of what's going on will catch up with you, sooner or later. I have an engineer to train in C++ with very little programming background and all I can say is that it requires that I pay a lot of attention to detail, so as not to teach destructive overgeneralizations or oversimplifications, while teaching enough to make her productive on real code.

Re:Isn't C just a glorified macro assembler?

[lgw]

Dude, you need to be less sensitive if you think I was running down C++ at the expense of Java. Don't make it a religious issue, you won't find happiness along that path.

Re:Isn't C just a glorified macro assembler?

[jrumney]

So what is a "built in function", if not one that is evaluated by the compiler rather than being defined in a library or by a macro in a header file?

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

Really great language provide something called ephemerons, which basically solve the issue of leaking objects in mark & sweep garbage collectors. Lua has ephemeron tables. And Lua is a really great language. I think Lua was the second widely used language--first if we exclude any Smalltalk implementation as widely used--to implement ephemerons formally.

The Wikipedia article says that C# has ephemeron tables, too. But the description of ephemerons is slightly wrong in the article--weak references are not sufficient by themselves--which makes me skeptical of the claim. Ephemerons solve at least one problem not solvable by careful use of weak references, and that's when a key-value pair in a property table (e.g. hash table) has a cycle--the value contains a reference to the key indexing it in the table. Ephemerons are distinct and more general than weak references. This case is described in the original paper, "Ephemerons: A New Finalization Mechanism". I'm not a GC guy so don't bother arguing with me on this. If I'm wrong, at least read the paper and explain either why the author was wrong, or why I misunderstood him.

The only problem is that ephemerons, like weak references, must be explicitly marked as such by the programmer. So ultimately there's no such thing as completely automatic garbage collection. Also, while ephemerons are more general than weak references, the worse case complexity of an ephemeron is much worse than a weak reference, although it's easy to avoid as it's a function of the number of ephemerons which reference each other, which is almost never.

Re:Isn't C just a glorified macro assembler?

[grimmjeeper]

It is exactly what it says. It is an actual function (i.e. executable code module) but it's built into the language and provided in the base linked package. C supplies defined functions as part of a library that is not part of the core language. That's the difference.

Re:Isn't C just a glorified macro assembler?

[Anonymous Coward]

It is depressive, but I _knew_ the . (operator) syntax would be a success.... djb

Re:Bugs in C++ ?

[Anonymous Coward]

I don't think C++ can have bugs at all as it's not an implementation. It could have unspecified conditions, but not bugs. A C++ compiler would likely contain plenty of bugs, but those bugs would be when the compiler does something else than expected of the C++ standard. Looking for bugs in C++ itself would be like looking for bugs in the English language. It might not always be the best and most logical solution, but there aren't any bugs. There are plenty of user errors though.

Biggest C++ bug? Boost

[Anonymous Coward]

Boost.

For those who can't figure out how to do something badly on their own.

The timeline in the first link:

[Anonymous Coward]

1979 - Work on "C with classes" started
At that time, "Object Oriented programming was considered too slow, too special purpose, and too difficult for ordinary mortals."

Well, I'm glad C++ fixed that last problem!

Re:The timeline in the first link:

[umghhh]

Now you are responsible for coffee on my keyboard and parts of display and frankly this is tragic rather than funny. I still laugh tho...

Glorious ride

[Anonymous Coward]

I have been there through most of this glorious ride. It is a little disappointing that after all that time programmers can't agree on a good, universal string class, and numerics (matrix, vector, complex numbers). Scheme is still a better way to program a computer.

Re:Glorious ride

[Anonymous Coward]

I'm in the aerospace world and it always amazes me how many unrelated vector/matrix/quaternion/etc libraries the average software project contains. It is a rare and disciplined project that only has one implementation of these things.

Re: Glorious ride

[Anonymous Coward]

yeah, we need to invoke functional languages because REAL alternatives offend the ftMeade INSECURITY folks.

ada, pascal, algol, rust, modula 2, oberon - all bad for the world dominators.

Re:Bugs in C++ ?

[Anonymous Coward]

C++ can have, and has had, bugs.

The standard for C++ could specify something impossible, for example. Like, make std::string impossible. This is similar to having a program that fails to compile, but as the standard is interpreted, it only causes problems when someone actually interprets it.

It could also have mistakes (as opposed to bugs), like mandating that your sort routine take at least O(n^3) time.

You can examine the defects and fixes in the C++ standard; they are published publicly. A defect is usually fixed by compilers even when compiling in prior version modes.

C backend would not impose limitations

[Eravnrekaree]

Translating to C would not impose a limitation on the language features of C++, its possible to generate whatever C code you need to support C++ features. Using an LALR parser would introduce limitations on language design, however. This was once very common.

Re:C backend would not impose limitations

[lgw]

Translating to C would not impose a limitation on the language features of C++

Practical limitations, for one guy banging out a language implementation in a hurry. C syntax was kept intact wherever possible, so that no translation would be needed. Which in turn led to quick adoption of C++ by C coders (which doomed C++ code to forever be ruined by C-style coding).

Re:C backend would not impose limitations

[tibit]

doomed C++ code to forever be ruined by C-style coding

This is very true. The especially troubling aspect of how C++ is usually taught is that they start with the C feature set and then "build" on top of that. It's completely ass-backwards, and I hate these teachers with a passion. I then have to undo the damage they've done to the impressionable students that then work with me...

Re:C backend would not impose limitations

[lgw]

I've basically given up professional C++ over this. I'd love a smaller project where I get to set the coding standards for a team small enough that I could actually CR everything and keep the rot from setting in, but somehow I've migrated to the big guys where that sort of team doesn't exist.

Re:C backend would not impose limitations

[Anonymous Coward]

The _only_ thing that makes C++ useful is it's strong ABI, semantic, and syntactic compatibility with C. Otherwise, there are many other languages which are the superior to C++. For example, D. Everything wrong with C++ is related to its relationship to C.

Which is why I prefer C over C++. C is a language driven by a few brilliant but limited abstractions--most notably the pointer. Within certain problem spaces, pointers are concise and descriptive and efficient and just a beautiful abstraction. C++ by contrast is a language with a cornucopia of theoretically powerful abstractions nevertheless severely limited by its compatibility with C. Well implemented lexical closures and coroutines are insanely powerful. Lua, for example, exhibits this. Lambdas in C++ are bastardized; and the current draft of so-called "coroutines" for C++ are merely a limited form of generators. Technically they fit the original definition of coroutines. But modern implementations of coroutines (e.g. as in Lua) are much more powerful and transparent--an abstraction which can be used to implement a form of cooperative threading. Most language designers would not use the term coroutines to describe what's in the C++ draft.

Look at everything that C++ has to offer, and it's done better in many other languages. And some languages can compete nearly feature-for-feature with C++ and still come out the best. The _only_ redeeming quality of C++ is it's C compatibility. But that's becoming less and less useful. Lua (but the PUC Lua VM and especially LuaJIT) has amazing support for interfacing with C without being hobbled by C.

CFront wasn't a compiler

[mveloso]

CFront wasn't a compiler, it was a preprocessor that spat out C code that was subsequently compiled by whatever C compiler you happened to have.

Looking at CFront output was the best way to understand how C++ actually worked at the time, since it was all mapped to pretty straightforward C constructs. I don't think anyone around today knows what a vtable and ptable is, but back then it was how you could tell the programmers who really dug in to the language from those that didn't.

Re:CFront wasn't a compiler

[Kjella]

Looking at CFront output was the best way to understand how C++ actually worked at the time, since it was all mapped to pretty straightforward C constructs. I don't think anyone around today knows what a vtable and ptable is, but back then it was how you could tell the programmers who really dug in to the language from those that didn't.

A ptable I got no idea, but a vtable is used whenever you use a virtual function and invokes an extra pointer dereferencing as opposed to a plain function. And I never learned C, but I had to learn that much to make inheritance work like I wanted in C++.

Re:CFront wasn't a compiler

[Dutch Gun]

Certainly every professional C++ programmer I've ever worked with knows what a vtable is. I have no idea what a ptable is though - never heard the term before.

Re:CFront wasn't a compiler

[IceAgeComing]

Looking at the article, there are Pclass, Ptable, Pname... there's no real documentation explaining them, but it's probably just a reminder to the programmer that the variable represents a "Pointer to" something.

It's frowned on today to put a variable's type in the name (look up Hungarian Notation), but in the old days, C allowed implicit type casting, which meant that the compiler would not blink if you assigned a non-pointer variable to a pointer variable. It made for some...interesting bug hunting back in the day.

Re:CFront wasn't a compiler

[edtice1559]

It still makes for bug hunting today. See the article today about 32-bit vs 64-bit Windows. Assign a pointer to an int to an int and it works just fine in a 32-bit build. Compile for 64-bit and fire up your debugger. Most compilers will generate a warning for this but there are often so many warnings (from things that used to be considered a sign of smartness) in any project of appreciable size that cleaning them all up is a project in and of itself and you don't know which ones will destabilize your 64-bit version.

Re:CFront wasn't a compiler

[Anonymous Coward]

> I have no idea what a ptable is though - never heard the term before.

It's what you eat your Pthanksgiving pturkey off of.

Re:CFront wasn't a compiler

[tlhIngan]

It still makes for bug hunting today. See the article today about 32-bit vs 64-bit Windows. Assign a pointer to an int to an int and it works just fine in a 32-bit build. Compile for 64-bit and fire up your debugger. Most compilers will generate a warning for this but there are often so many warnings (from things that used to be considered a sign of smartness) in any project of appreciable size that cleaning them all up is a project in and of itself and you don't know which ones will destabilize your 64-bit version.

Yes, and that's why modern C uses inttypes.h, and if you want to cast a pointer to an int, you use intptr_t - it's an int guaranteed to be big enough to fit a pointer. It might be bigger than the pointer, but it is safe to cast the pointer to the int and back using intptr_t.

Though the only thing I don't like is how the compilers are picky when using printf() style functions and the various int types - long longs, etc., all see to require a different % specifier. It would be nice if gcc, besides telling you the % specifier was wrong, what you should use instead. Many hours were wasted trying to find out if you were to use %d, %llu, %lu, %l or %ll or varying combinations thereof to satisfy the compiler. intptr_t is especially nasty in that regard. Though there are supposed to be definitions as well but they're clunky as all heck to use. (Where's the "Pick the right thing for the type" option?).

Re: CFront wasn't a compiler

[Anonymous Coward]

this kind of shit is plain evil, including the pointer arithmetic DRECK.

did algol have this wicked evil?

Re:CFront wasn't a compiler

[edtice1559]

I don't think that anybody would (intentionally) do this today. There are very few "green field" projects out there, though. Everybody has millions of lines of existing code that was written before those features existed. (C++11 and C++14 were the first updates in a decade). I go to places where many of the files are still 8.3 format all uppercase letters back from a time when the file systems were limited that way. Systems are large and you may call an API that uses a fairly modern interface but it wraps and abstracts some legacy capability that isn't so friendly to being compiled for different type sizes. As the languages gain new features, we're able to build more complex systems. Unfortunately, this means that the programmers are always one step ahead of the language. There's stuff we are writing today that is going to subject us to pain in the future. Just not enough time has elapsed yet for us to know what those behaviors are.

Guess we should pull up the old joke

[Anon-Admin]

I remember when it first came out. Back in the days of BBS's

The old joke was

"Have you seen the new C+++"

I wonder how many will still get the joke?

Re:Guess we should pull up the old joke

[Anon-Admin]

Hmm, slashdot ate the punchline.

"Have you seen the new C+++ No Carrier"

Had to drop the grater than and less than signs. Wow how times have changed. lol

Re:Guess we should pull up the old joke

[IceAgeComing]

I needed the "No Carrier" reminder and then I got the joke...Wow, yes I remember those days.

Re:Guess we should pull up the old joke

[narcc]

Times haven't changed, <things> are exactly the same as they were previously. ><

It is a tradition for users, regardless of how long they've been here, to forget something simple like how to use < and > in a forum post. I don't know how many times I've seen someone complain that Slashdot ate this or that bit of their post. Should have used the preview button...

Just use &lt; instead of typing a < and you'll be fine. You can also use &gt; in place of simply typing a >, if you're a bit paranoid. Type &amp;lt; to write out &lt; should you need to explain this to someone else.

Terrible compiler error messages

[IceAgeComing]

I don't know if it was CFront, but the first C++ programs I wrote were for homework assignments in the late 1980's. The compiler output was unreadable, of course, because it wasn't compiling my code. It was compiling a C++ to C translation of my code. All I really knew was that there was a problem with my program *somewhere* at the line, or above it, where the first error message appeared. It was an exercise in agony management.

I remember thinking, "what an awful language!" at the time. Of course that changed eventually; I remember Borland's C++ compiler being especially good at producing helpful error messages.

Re:Terrible compiler error messages

[edtice1559]

C++ compiler error messages have only gotten worse. The compiler vendors try to make them meaningful but the language standard and rules are so complex it often takes multi kilobyte messages to explain the problem. Try making a minor mistake in a template instantiation. Back in the day we didn't have templates so the error messages at least fit on one screen.

Re:Terrible compiler error messages

[Dutch Gun]

I was a bit luckier, in that I learned the language using Turbo C++. It was a fantastic compiler/IDE for DOS. I actually still have very fond memories of working on my hobby projects in that environment. Later in my schooling, using gcc on Unix workstations felt really primitive by comparison. By the time I turned pro, it was pretty much all MSVC.

What's funny (or sad, I suppose) is that, to this day, template-generated error messages are as horrible as ever. Hopefully we'll either get concepts or some other system to improve them, but I guess for now it just remains one of C++'s warts.

Re:Terrible compiler error messages

[david_thornley]

The only really big problem in C++ error message is template errors. It's possible to rewrite them into clarity, but that's awkward. I'm not aware of anything in Modern C++ that made error messages harder, so they've been improving since templates were introduced.

Re: Terrible compiler error messages

[Anonymous Coward]

with teutonic brutality i declare that one does not need template crap at all. use a proper macro language and expand into a file on disk. then your ide can show a good error message along with the real code and the real problem.

i worked on a major cad system which does generic containers via macros.

time to question the unclothed emperor !

Re: Terrible compiler error messages

[Anonymous Coward]

write your own m4 based macro container classes. expand code to disk. stl is an overly complex scheisshaufen. plus stl vectors are not doing bounds checking easily. retarded c dreck.

Re:Terrible compiler error messages

[edtice1559]

Somebody must agree with you since they modded me down. I see your point, but modern C++ *is* templates. And not only are the messages themselves hard to understand, even if the error message itself is completely clear, the cause is often disagreement about what the language standard says rather than a traditional syntax error. As a simple example, the Microsoft and Intel compilers allows partial specialization of a template function within a template during template *definition*. This is really convenient, but not clear if it is actually allowed by the language. GCC allows something similar but does less type inferring. A fair criticism of the original comments is that the error messages are complicated because the language is complicated. As the language keeps becoming more complicated, the messages get even harder to understand even if they are otherwise improved. And it's not reasonable to discount templates because they are all over the standard headers and you can get a template error even if not explicitly using them. That's one area where the messages are clearly worse. The messages when using standard libraries are way more complicated because the implementations have become more sophisticated to support templates.

C++11 is almost a different language

[tepples]

Uh, have you heard of smart pointers?

Yes, and the pre-C++11 std::auto_ptr was a confusing piece of crap.

Or RAII?

Isn't that the trade group that sues music fans? Oh wait, that's RIAA. But yes, I understand the advantages of automatic finalization.

Have you used C++ in the last 5-10 years

Last 4 years would be more honest, as C++11 added the smart pointers and other things that make modern C++ feel like modern C++.

Re:C++11 is almost a different language

[Anonymous Coward]

Yes, and the pre-C++11 std::auto_ptr was a confusing piece of crap.

Which is why everyone used the boost smart pointers or rolled their own before C++'11 support started coming. In fact, std::shared_ptr is pretty much straight out of boost. Ditto (I believe) for weak_ptr and unique_ptr.

Isn't that the trade group that sues music fans? Oh wait, that's RIAA.

What is the point of this comment?

Last 4 years would be more honest, as C++11 added the smart pointers

I was using smart pointers well before 4 years ago. See above on boost.

Re:C++11 is almost a different language

[Anonymous Coward]

>> Isn't that the trade group that sues music fans? Oh wait, that's RIAA.
> What is the point of this comment?

"That's a, I say, that's a JOKE, son."

Re:C++11 is almost a different language

[david_thornley]

Yes, and the pre-C++11 std::auto_ptr was a confusing piece of crap.

Which is why you'll never get one through a code review at my company. std::unique_ptr does what auto_ptr did, only much more elegantly. std::shared_ptr is also useful.

Isn't that the trade group that sues music fans? Oh wait, that's RIAA. But yes, I understand the advantages of automatic finalization.

I'm not sure you really do understand RAII, if you refer to it as "automatic finalization". It's far more useful than finalization in the languages I've seen that use it. It's a unified resource manager that can handle every type of resource uniformly.

Re:C++11 is almost a different language

[tibit]

That's correct. The oft overlooked aspect of RAII is that C++ has strictly defined order of object destruction. It forms the core language semantics and modern C++ would be useless without it. Calling it "automatic finalization" is completely missing the point.

Re:C++11 is almost a different language

[Anonymous Coward]

"deterministic destruction" (aka finalization)

3B2, porting

[emil]

I am going to bet you that the 3B2 was that primary computer architecture for cfront.

However, it does appear that cfront was extremely portable:

As Cfront was written in C++, it was a challenge to bootstrap on a machine without a C++ compiler/translator. Along with the Cfront C++ sources, a special "half-preprocessed" version of the C code resulting from compiling Cfront with itself was also provided. This C code was to be compiled with the native C compiler, and the resulting executable could then be used to compile the Cfront C++ sources.

Re: 3B2, porting

[calgarybill]

Actually I remember compiling and using front on my 3B1/UnixPC

Sadly, I don't remember either

[mveloso]

I don't remember what the ptable was for anymore either.

I do remember name mangling, which I suppose doesn't happen anymore?

Re:Sadly, I don't remember either

[erapert]

LLVM, VisualStudio, and G++ all still name mangle. It's necessary to implement function overloading if I'm not mistaken.

CFront is not a compiler

[naris]

It's a pre-processor that translates C++ to C, that then has to then be compiled by a C Compiler. Back in the day, I used the Glockenspiel implement of CFront that then used the Microsoft C Compiler (this was before Microsoft had a C++ compiler) to compile the resulting C code to .obj files to be linked by Microsoft's LINKer.

Re:CFront is not a compiler

[Anonymous Coward]

It's still a compiler, it translates a source language into a target language. The fact that the target language also needs to be compiled makes no difference.

Let's Find Bugs In It

[Anonymous Coward]

No, let's not OK? Really.

I would rather sever one of my own fingers than spend time searching for bugs in an old and obsolete piece of code. No matter how "sacred" you think it is, it's just another legacy system to me. And searching for bugs seems like one of the least interesting, least relevant activities you could do with legacy code. How about evaluating it's architecture? How about a critique of how the ability and features of the legacy system fit with the times? But a bug search??

I could add some unkind comments about needing some purpose in your life. Yet people find meaning and interest in the oddest things. The thing that's even odder though, is feeling the need to publicize this deeply eccentric hobby. What's next, a discussion of the giant ball of belly-button lint you have in your closet?

PVS-Studio slashvertisement

[lokedhs]

It's the monthly PVS-Studio slashvertisement. In this case, only the last words of the summary (within parentheses at that) suggested what this was about, and it took until a couple of paragraphs into TFA until it was mention, but sure enough, it was your regular post showing PVS-Studio output from a random open source software project.

Seriously, this is getting old.