Popular Myths about C++, Part 1 • Hacker News Board

Re: Popular Myths about C++, Part 1

#61

Post by pjmlp » Tue, Dec 09, 2014, 3:01 PM UTC

throwawayaway wrote: post #52

pjmlp wrote: post #51

Earlier quoted context omitted.

To allow Bjarne to sell C++ to C developers, specially those ex-Assembly programmers that were force-feed to C. You don't need to learn C, just read "The Design and Evolution of C++".

But how can you explain their existence and all the C++ behaviour derived from that without using C - you can't.

Yes, you can. I am having this discussion since 1993.

Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes, besides the initial history introduction.

The fact that the C++ language contains a (almost) C compatible subset doesn't require students to be aware of it. It is all ANSI C++.

Re: Popular Myths about C++, Part 1

#62

Post by jbooth » Tue, Dec 09, 2014, 3:01 PM UTC

bkeroack wrote: post #45

millstone wrote: post #20

Earlier quoted context omitted.

Much of C++ can only be understood in the context of C. For example, why are string literals not std::string, and what the heck are null-terminated strings about? In your alternate universe, C++ would be a nonsense language full of absurd design decisions. Understanding C is perhaps necessary to understand why C++ works the way it does.

Even further, why are strings considered a linear sequence of 8-bit characters (defaulting to ASCII)? That's madness in 2014! If I give you a sequence of bytes and tell you it's a "string", that's no more meaningful than if I gave you a bunch of bytes and said "this is music" or "this is a picture". Without telling you the encoding you have to blindly guess how to interpret it. Go does a good job of rectifying this:…

I know it's a rhetorical question, but "Unicode didn't exist when C or C++ were invented" is a really good answer.

Re: Popular Myths about C++, Part 1

#63

Post by throwawayaway » Tue, Dec 09, 2014, 3:02 PM UTC

pjmlp wrote: post #61

throwawayaway wrote: post #52

Earlier quoted context omitted.

But how can you explain their existence and all the C++ behaviour derived from that without using C - you can't.

Yes, you can. I am having this discussion since 1993. Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes, besides the initial history introduction. The fact that the C++ language contains a (almost) C compatible subset doesn't require students to be aware of it. It is all ANSI C++.

ok: why do structs exist and why are their members public? why don't you just use classes with public?

i have been taught extremely poorly and am many years your junior. K&R/stan lipmann's "inside the C++ object model" was a huge "oh ok, I've been basically lied to the entire time"

Re: Popular Myths about C++, Part 1

#64

Post by pjmlp » Tue, Dec 09, 2014, 3:02 PM UTC

throwawayaway wrote: post #58

pjmlp wrote: post #57

Earlier quoted context omitted.

By using them like safe system programming languages from Algol/Mesa line do. Out function parameters are implicit pointers via references. Cannot be null. Pointers and arrays aren't compatible. Pointer arithmetic is frown upon and in many of those languages requires an explicit unsafe block/system module import.

would it be fair to say you have just described references, or do I have to go and lookup this algol/mesa stuff?

I can provide a better example, but only tonight. At work now.

Re: Popular Myths about C++, Part 1

#65

Post by jlarocco » Tue, Dec 09, 2014, 3:08 PM UTC

mikeash wrote: post #40

A major problem with C++ is a lack of consistency, which you run into if you start trying to generalize the ideas presented in this article. The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course: return name+'@'+domain; I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well: return "mailto:…

> auto v = {1,2,3,5,8,13};

> Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time!

IMO it would be more confusing if that created a vector. Unless the compiler is reading your mind, how is it supposed to know you meant a vector, a set, deque, a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?

Re: Popular Myths about C++, Part 1

#66

Post by mikeash » Tue, Dec 09, 2014, 3:13 PM UTC

jlarocco wrote: post #65

mikeash wrote: post #40

A major problem with C++ is a lack of consistency, which you run into if you start trying to generalize the ideas presented in this article. The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course: return name+'@'+domain; I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well: return "mailto:…

> auto v = {1,2,3,5,8,13}; > Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time! IMO it would be more confusing if that created a vector . Unless the compiler is reading your mind, how is it supposed to know you meant a vector , a set , deque , a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?

The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. For example, in Python:

    x = [1, 2, 3, 5, 8, 13] # this is a list of integers
    y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers

There's nothing inherently wrong with C++'s initializer list approach. Nor is there anything inherently wrong with auto. But they collide in unfortunate ways because they haven't been designed such that they go well together. C++ is full of things like this. Responding with "well, that makes the most sense" for any given feature is missing the point entirely.

Re: Popular Myths about C++, Part 1

#67

Post by claudius » Tue, Dec 09, 2014, 3:14 PM UTC

mikeash wrote: post #59

humanrebar wrote: post #50

Earlier quoted context omitted.

To be fair everything you're upset about is a problem with the standard C++ library, not the language itself. Not to say that the language doesn't have issues. The initializer list example you provide is half of one, but only because people don't like to write algorithm-based code. This is actually fine: auto v = {1, 2, 3, 5, 8, 13}; for (auto i : v) { std::cout ...all that being said, the C++ standard library gets s…

The standard library is part of the language. But that aside, the fact that + doesn't work on string literals cannot possibly be a problem with the standard library. The fact that the language lets you extend + to work with some types but not others is not a problem with the standard library. As for initializer lists, the problem isn't simply that {} doesn't produce a vector, it's that identical-looking constructs do…

> a = b can do completely different things depending on where you see it and what declarations are visible and on and on.

I don’t see your problem with this. "a + b" certainly can and should do "completely different things depending on where you see it" and "+" is commonly used in completely different contexts in real-world usage, too, e.g. integer addition, integer addition modulo x, real number addition, complex number addition, vector addition, matrix addition, vector space addition, set addition/union etc. etc.

To restrict "+" to only act on integers (or reals?) and require a +_real, +_complex, +_vector, +_matrix etc. seems unreasonable.

Now, given that "+" may well do whatever it seems fit with its two operands, why should "=" not be allowed to do the same?

Re: Popular Myths about C++, Part 1

#68

Post by Ragnarork » Tue, Dec 09, 2014, 3:15 PM UTC

throwawayaway wrote: post #49

Ragnarork wrote: post #48

Earlier quoted context omitted.

Pointers aren't even there for supporting a legacy language, they have their use and are distinct from references. Mixing the two and thinking they are equivalent (though they are close in what they do) is a mistake.

How can you have pointers without allowing all the holes that C allows?

By not using them like in C.

Of course this isn't an argument, but this shows that even though C++ doesn't prevent you from falling into the same trap that are present in C, it does give you the tool to at least allow you to do better than C to avoid these traps, notably thanks to RAII.

Oh and let's not forget nullptr, which is a blessing compared to NULL.

Pointers are still a feature of both languages.

Pointers in C++ are basically the same than in C, just with mechanisms that solve the ownership and some safety problems.

So yes, it allows the same holes, but at least you have tools to avoid falling in them.

Re: Popular Myths about C++, Part 1

#69

Post by vonmoltke » Tue, Dec 09, 2014, 3:21 PM UTC

CountHackulus wrote: post #46

Symmetry wrote: post #22

What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import . And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.

snprintf isn't a standard function. There's certain platforms that don't have it. I know, it happened to me on z/Linux.

snprintf is a standard function, but only as of C99.

Re: Popular Myths about C++, Part 1

#70

Post by bstamour » Tue, Dec 09, 2014, 3:31 PM UTC

WhitneyLand wrote: post #43

Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints? Back in the day I read Bjarne's book cover to cover, used C++ for very large scale projects, and was one of those guys who could make sense of arbitrarily complex pointer expressions. Now I mostly regret it. Led down the rabbit hold of multiple inheritance, STL being much more complicated than templating in other langu…

I still use C++ because it not only allows me to write high performance code, but also allows me to easily express high level ideas without worrying about too much overhead. I can write generic algorithms in terms of monoids and semigroups and I can write device drivers. I do a lot of signal processing at work, so sometimes these high-level and low-level concepts exist side-by-side in the same codebase.

Edit: I should mention that by no means to I think C++ is perfect. Very few other languages, however, give you the amount of low-level control, and the tools to build cheap, powerful abstractions, like C++ does.