You can't make C++ not ugly, but you can't not try (2010) • Hacker News Board

Re: You can't make C++ not ugly, but you can't not try (2010)

#121

Post by gumby » Thu, Feb 27, 2020, 10:58 AM UTC

downerending wrote: post #5

gumby wrote: post #2

This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…

You wish. Unless I'm terribly misinformed, "modern C++" contains all of the features of the prior versions, which means that in the real world you have to learn and deal with all of it .

I don’t really understand your point. Just because all the implementations support the `asm` keyword doesn’t mean you need to know the assembly language of every CPU that has a c++ compiler.

You can write your code in modern c++ and ignore prehistoric carbuncles (some of which have been deprecated and eliminated FWIW). And you can call external code written in older dialects without having to look into its source code.

Re: You can't make C++ not ugly, but you can't not try (2010)

#122

Post by gpderetta » Thu, Feb 27, 2020, 11:00 AM UTC

pjmlp wrote: post #76

JonathonW wrote: post #3

Earlier quoted context omitted.

The author also seems to really, really want C++ to be Python, despite that they're completely different languages for completely different purposes that make completely different sets of design tradeoffs. In that respect, the author probably wouldn't be happy with modern C++, either. For example, C++ is never going to be a garbage-collected language (by default, at least). Modern C++ gives you better tools to deal w…

Actually C++11 introduced a GC API.

It seems to me that just a couple of do nothing placeholders were added to please Hans Boehm and get him to work on the c++ memory model :).

Re: You can't make C++ not ugly, but you can't not try (2010)

#123

Post by gpderetta » Thu, Feb 27, 2020, 11:03 AM UTC

AnimalMuppet wrote: post #61

unlinked_dll wrote: post #9

Most of what the author complains about w.r.t callbacks is fixed with std::function and lambdas (member function pointer syntax is necessarily weird, because methods aren't just normal functions). I definitely don't miss the days of std::bind. Nowadays you just do something like using Callback = std::function ; // or whatever Callback cbk = [&](int i) { return instance.method(i); }; I've also seen some real evil hack…

What's so awful about pointer to member? I've used it a couple of times, and didn't think it was particularly weird. I mean, yes, I had to look up the syntax, but it was rather straightforward.

there is nothing wrong with them, but pointers to member do not close over this, so you still need some form of binding to use them as callbacks.

Re: You can't make C++ not ugly, but you can't not try (2010)

#124

Post by sarabande » Thu, Feb 27, 2020, 11:10 AM UTC

Replace the two double negatives and you get a better title:

"You can't make C++ beautiful, but you must try."

Re: You can't make C++ not ugly, but you can't not try (2010)

#125

Post by gpderetta » Thu, Feb 27, 2020, 11:11 AM UTC

AnimalMuppet wrote: post #64

TheOtherHobbes wrote: post #28

Earlier quoted context omitted.

Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?

I don't know about templating, but... is Haskell's Hindley-Milner type identification system Turing complete? For that matter, Lisp's macros are definitely Turing complete, and they are... a templating system on steroids, maybe? About mindshare: Lisp has zealots, but they are few, even if they are loud, and they are on HN more than many other places. C++ is perhaps not loved, but in some circles it is very well respe…

> is Haskell's Hindley-Milner type identification system Turing complete?

I'm out of my depth, but I'm pretty sure HM is not Turing complete by design as otherwise it wouldn't be able to guarantee that inference completes. An HM type system is about as powerful you can get without being Turing complete.

There are extensions to the type systems of languages that use HM making them Turing complete, but when using those extensions inference is not guaranteed or doesn't work at all.

Re: You can't make C++ not ugly, but you can't not try (2010)

#126

Post by de_watcher » Thu, Feb 27, 2020, 11:20 AM UTC

kllrnohj wrote: post #91

pjmlp wrote: post #89

Earlier quoted context omitted.

Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler, and does not require lots of paperwork for adoption at many shops.

> Because STL is part of the compiler, guaranteed to work on every platform supported by the compiler No it isn't and no it's not. There are even platforms where an STL isn't even provided out of the box, you have to pick one. And there's quite a few at that - libc++, libstdc++, stlport, etc... But clang, g++, etc... they don't care. To them it's just another library you're linking against, no different from any othe…

You're a troll from 2003. I remember huge forum threads about STL.

Now it's the Standard Library like in any other language.

Re: You can't make C++ not ugly, but you can't not try (2010)

#127

Post by mehrdadn » Thu, Feb 27, 2020, 11:22 AM UTC

kllrnohj wrote: post #57

vlovich123 wrote: post #47

Earlier quoted context omitted.

I still think the STL containers are the sane default to reach for & switch to more obscure ones when the problem domain and performance requirements say to use a different one.

You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…

Small vectors break iterator guarantees, for one thing. They also really only make sense for tiny objects (ints, etc.) given you don't want a pickup truck's worth of data on your stack. They're most definitely not general-purpose.

There are lots of subtleties STL containers have to worry about in designing containers, regarding everything from iterator & pointer invalidation to allocation and allocator propagation. All this is because they're designed to be general-purpose and support most conceivable use cases. Their replacements have to trade off requirements in order to get better performance or otherwise improve on some axes.

Re: You can't make C++ not ugly, but you can't not try (2010)

#128

Post by _pmf_ » Thu, Feb 27, 2020, 11:32 AM UTC

Rusky wrote: post #18

gumby wrote: post #2

This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…

To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…

> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!)

This is surprising for Java devs, but given that value semantics must be supported, there's no way to avoid it.

Re: You can't make C++ not ugly, but you can't not try (2010)

#129

Post by KptMarchewa » Thu, Feb 27, 2020, 11:34 AM UTC

UncleMeat wrote: post #23

downerending wrote: post #15

Earlier quoted context omitted.

I'm not saying it's a bug. I'm saying that backwards compatibility means that you still have to deal with all of the historic flaws of the language today . The article is indeed still relevant.

But that’s true for literally everything. If you have a cpp code base and are building new stuff in rust to interop then you still have legacy cpp code even though rust has fewer problems.

Not really. Legacy stuff can be contained. For example, you could specify language version level in file and it would disable removed/deprecated stuff.

Re: You can't make C++ not ugly, but you can't not try (2010)

#130

Post by virtualritz » Thu, Feb 27, 2020, 11:42 AM UTC

I recently picked up a C++ codebase I wrote maybe 30% myself and which was last touched in 2013. It's a plug-in for a DCC app. The 3rd party API it communicates with was changed so refactoring was inevitable.

Before I started refactoring I decided to make everything 'less ugly' by moving it to C++17. Which would also help me get back into the code, after eight years.

I spent two days on this. Then I decided: fuck it. I will RIIR™.[1]

It will mean that it will take me at least two months to get a beta of the product with feature parity vs. maybe a week to port the old codebase to the new API.

But on the other hand the C++ code is littered with stuff that 'just works' but can explode in your face and which eventually needs some safety net written around it. Which will likely take at least two months to do properly.

The truth is: after one and a half years of Rust C++ feels painfully ugly.

For context: I started with C++ with Borland's TurboC++ (moving from C) when I was 15. I used C++ for almost 30 years by now. It's about time.

[1] Yes, I did read http://adventures.michaelfbryan.com/posts/how-not-to-riir/