Ill-Advised C++ Rant, Part 2 • Hacker News Board

Re: Ill-Advised C++ Rant, Part 2

#21

Post by alschwalm » Mon, Mar 07, 2016, 3:36 AM UTC

Just to note, the proposal the author lists as "so complicated" is actually just fixing an inconsistency in the grammar where "class" and "typename" are not always synonymous in the context of template declarations. Specifically:

    template class Foo;
    template class Foo;

Are the same. But, not when declaring a template with a parameter that is itself a template:

    template class T> struct Foo;    // Compiles
    template typename T> struct Foo; // Does not compile

The proposal allows the second form to compile, fixing this inconsistency.

Re: Ill-Advised C++ Rant, Part 2

#22

Post by jjoonathan » Mon, Mar 07, 2016, 3:40 AM UTC

ryandrake wrote: post #8

GFK_of_xmaspast wrote: post #5

A bunch of those are of the form 'you know there are better ways to go about doing that sort of thing' (like 'maybe consider using a std::vector instead of that static array' and 'just make a minimal ctor for initialization, you'll save typing in the long run' and 'when do you need to know the largest value in an enum, and why can't you just toss in a dummy last element, also why aren't you using enum class') if not…

What possible use is there for being able to convert the name of an enum as a string that isn't totally bug-ridden the minute you write it?

Serialization. And don't tell me that it falls under "bug-ridden the minute you write it" because more defensive programmers than you and I have been using it responsibly in a dozen other languages for more than a dozen years.

Re: Ill-Advised C++ Rant, Part 2

#23

Post by antiquark » Mon, Mar 07, 2016, 4:09 AM UTC

He has a some good points, but the "switch" statement needs an integer for a reason... a switch can be converted a jump table in assembly language, so that the "case" can be arithmetically determined and instantly jumped to. The reason being: MOAR SPEED! A jump table is a lot faster than a sequence of else-if statments.

Re: Ill-Advised C++ Rant, Part 2

#24

Post by maxlybbert » Mon, Mar 07, 2016, 4:10 AM UTC

jonstewart wrote: post #12

I mean, finally getting standard networking and filesystem libraries is a really nice thing...

It depends on your definition of "standard." POSIX is a standard, and it's the standard nearly everybody has used for networking and filesystem access.

Re: Ill-Advised C++ Rant, Part 2

#25

Post by maxlybbert » Mon, Mar 07, 2016, 4:16 AM UTC

I found it funny how many of the complaints were really about the preprocessor. Many of them have already been addressed. If you don't like defining a macro as "do { ... } while (0)", try using an inline function. Even C has inline functions nowadays, and that's been true for more than a decade.

Re: Ill-Advised C++ Rant, Part 2

#26

Post by kibwen » Mon, Mar 07, 2016, 4:16 AM UTC

Animats wrote: post #20

I tend to agree, but gave up on fixing C++ a decade ago. I hope Rust is the future; it deals with all these issues. But Rust seems to be starting out at the complexity level it took C++ two decades to achieve.

  > Rust seems to be starting out at the complexity level it 
  > took C++ two decades to achieve.

You say this every time that Rust is compared to C++ (which is a lot!), but I have yet to see an elaboration. What in particular are you talking about?

Re: Ill-Advised C++ Rant, Part 2

#27

Post by chrisseaton » Mon, Mar 07, 2016, 4:21 AM UTC

maxlybbert wrote: post #25

I found it funny how many of the complaints were really about the preprocessor. Many of them have already been addressed. If you don't like defining a macro as "do { ... } while (0)", try using an inline function. Even C has inline functions nowadays, and that's been true for more than a decade.

If you could write it as a function why would you be writing a macro in the first place?

Re: Ill-Advised C++ Rant, Part 2

#28

Post by shiro » Mon, Mar 07, 2016, 4:23 AM UTC

antiquark wrote: post #23

He has a some good points, but the "switch" statement needs an integer for a reason... a switch can be converted a jump table in assembly language, so that the "case" can be arithmetically determined and instantly jumped to. The reason being: MOAR SPEED! A jump table is a lot faster than a sequence of else-if statments.

The compiler knows the type of the value it switched upon and generates code accordingly (efficient code on int values, dumb if-chain on other values), doesn't it? Sure it may become hard to tell if the code is efficient or not, but that property has already long been lost with operator overloading.

Re: Ill-Advised C++ Rant, Part 2

#29

Post by sago » Mon, Mar 07, 2016, 4:23 AM UTC

antiquark wrote: post #23

He has a some good points, but the "switch" statement needs an integer for a reason... a switch can be converted a jump table in assembly language, so that the "case" can be arithmetically determined and instantly jumped to. The reason being: MOAR SPEED! A jump table is a lot faster than a sequence of else-if statments.

I don't see why that follows. If switch is given an integer, the compiler could create a jump table, otherwise it can use an if statement block (or some other kinds of implementation). There's nothing in C++ that says certain statements must always have the same compiled code.

Re: Ill-Advised C++ Rant, Part 2

#30

Post by Grishnakh » Mon, Mar 07, 2016, 4:23 AM UTC

antiquark wrote: post #23

He has a some good points, but the "switch" statement needs an integer for a reason... a switch can be converted a jump table in assembly language, so that the "case" can be arithmetically determined and instantly jumped to. The reason being: MOAR SPEED! A jump table is a lot faster than a sequence of else-if statments.

So why can't the compiler be smart enough to use a jump table when this is possible, and fall back to a sequence of else-if statements when it's not? The compiler should even be able to make a more optimal sequence of assembly tests and jumps than by writing this code manually.