Live data from Hacker News

C++: Is It Really a Cruel Joke? (2003)

webhome.phy.duke.edu

101–110 of 155 posts

Re: C++: Is It Really a Cruel Joke? (2003)

#101

> There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about '90 or '91. I felt sorry for them really, but I thought people would learn from their mistakes. I've talked to some of the people at Mentor Graphics who were there during that period. The company basically went from #1 in the industry to #3 or so during the course of the C++…

JWZ told a similar story about Netscape between versions 3 and 4 being rewritten in C++. The full story is in the book Coders at Work, but part of it appears here:

https://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-r...

Of course this was mid-90s when both the language and especially the compilers were quite different from now (and the compilers very buggy indeed).

Re: C++: Is It Really a Cruel Joke? (2003)

#102

From the "interview" of "Stroustrup": > ... You know, when we had our first C++ compiler, at AT&T, I compiled 'Hello World', and couldn't believe the size of the executable. 2.1MB > Interviewer: What? Well, compilers have come a long way, since then. > Stroustrup: They have? Try it on the latest version of g++ - you won't get much change out of half a megabyte. So, for grins, I did, with the gcc7 port from macports,…

    #include
    int main(){
            printf("Hello World");
            return 0;
    }
>5649591 -rwxr-xr-x 1 user user 8288 Jul 5 21:49 a.out

What am I doing wrong?

Re: C++: Is It Really a Cruel Joke? (2003)

#103
post #45

I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..

I'm going to throw my vote in for D. I've been porting a few small classes from c++ to d for a project i'm working on. The D versions are about half as many lines. There are no header files or #defines/#ifdefs everywhere. I replaced most of the setters/getters with @properties

Re: C++: Is It Really a Cruel Joke? (2003)

#104
post #45

I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..

I was involved with a large OCaml project with a GUI which was compiled on Windows and Linux. We didn't try macOS but it would probably have been possible to port it there too. For the GUI we used Gtk (with a Windows-flavoured theme on Windows). It was written with emacs, built using a bunch of Makefiles, and shipped as a native binary on both platforms, with an NSIS-based installer on Windows.

Re: C++: Is It Really a Cruel Joke? (2003)

#105
post #97

Earlier quoted context omitted.

I love Rust. Especially for emudev and embedded development (fields I would traditionally use C or C++). However, it still performs worse than C++ in most cases [1]. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

A number of those C++ benchmarks are "cheating" by using SIMD intrinsics, which was only stabilized in Rust about two weeks ago.

1) Specifically which of those C++ programs? Innuendo is not OK.

2) Even with cheating in scare quotes, name-calling is not OK.

Re: C++: Is It Really a Cruel Joke? (2003)

#107
post #63

Earlier quoted context omitted.

Which OS? Linux and Darwin are still entirely C in the kernel, I believe. Windows is C++.

I use windows 10. Kernel is still Win32 C calls but I bet a lot of the services on top aren't.

Just because it's a C API doesn't mean it's not C++ underneath. Heck, Microsoft's C runtime is written in C++ nowadays.

Re: C++: Is It Really a Cruel Joke? (2003)

#108
post #76

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup [1] [1] http://www.stroustrup.com/bs_faq.html#really-say-that

There are plenty of languages in use that people genuinely enjoy using [1]. A lot of complexity in languages tends to be completely incidental. It's often not inherent in the problem the language solves, and it's just a design decision somebody made based on their aesthetic and experience at the time. A lot of people seem to take pride in memorizing these quirks, but they're just that. There's nothing fundamentally i…

I can think of only two C++ "quirks" that meet the definition of "just mental clutter; nothing fundamentally interesting about them."

  1. Nested templates closing brackets conflicting with `>>` operator, necessitating `> >`. This was fixed in C++ 11.
  2. Syntax for declaring an automatic variable conflicts with the syntax for C function type: `Thing mything();`.
Those two certainly seem to be "unforced errors" where the language is simply stepping on its own feet for no good reason, and one of them hasn't even been relevant for over five years.

In all other cases in my experience, investigating the rationale behind a particular quirk has led to a fairly interesting reason; a difference between the heap and the stack, say, or the language giving you the option to not do some work that may be expensive and unnecessary. For example, beginners often are surprised and annoyed that `remove_if()` doesn't actually remove anything and they need to call `erase()`. But most STL algorithms work on a pair of start and end iterators and you can simply work with the new "past-the-end" iterator returned from `remove_if()` allowing you to combine or omit the calls to `erase()`. This is certainly quirky but its not "mental clutter": there actually is a fairly interesting reason for the API being designed this way, rooted in the zero-overhead principle.

In my experience that has been the rule, not the exception - taking the time to understand the "why" behind a given quirk usually results in being forced to admit to yourself, "yes, I see; that is the only way it could have been designed as a zero overhead abstraction. The 'simpler' alternative I had in my head would require some overhead to implement." I think that's the reason why so many people on this thread who have read "The Design and Evolution of C++" change their mind and come away with praise for the language - because it lays bare the logic behind many of those design decisions.

I would be interested to hear which quirks in C++ you view as mental clutter and/or design mistakes. As far as I can tell, most of C++'s usability problems come from it being too carefully designed and too backwards compatible. And after witnessing disasters such as Perl 6, I'm not sure "backwards compatible" is really a "mistake" per se.

Re: C++: Is It Really a Cruel Joke? (2003)

#109
post #96
post #47

Earlier quoted context omitted.

The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have…

Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.

The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.

Re: C++: Is It Really a Cruel Joke? (2003)

#110
post #80

Earlier quoted context omitted.

Only if it need to have backward compatibility. Rust doesn’t so it can be vastly simpler.

How is Rust simpler than C++?

Are you talking about grokking the language and its more excotic concepts or writing code on it?

I have almost 30 years of C++ experience and about 6 months of Rust. My gut feeling is that the languages are equally difficult to understand but that the experience of writing code in them is very different.

I'm sure Rust will have its own set of surprises as I keep using it.

But I can't believe they will be nearly as bad as those that C++ comes with. ;)

Post reply on HN