Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Popular Myths about C++, Part 1

isocpp.org

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Popular Myths about C++, Part 1

#131

Post by mike-cardwell »

StephanTLavavej wrote: post #127
pierrebai wrote: post #60

Earlier quoted context omitted.

This is the archetypal problem with benchmarks: not only are they hard to design, but people will incorrectly nit-pick the results. You count the number of allocations, without looking at the big picture: this is a toy example. It provides the hard-coded input to the function. This results in the C version not having to allocate memory for the hard-coded literals and the function problably being inlined and optimized…

C++14's "meow"s is syntactic sugar for string("meow"), with identical efficiency.

If that's the case, then when I do:

  auto str = "something";
Why is "str" a "const char " rather than a std::string? Tested using "-std=c++14" with both gcc version 4.9.1, clang 3.5.0 and with both libstdc++ and libc++ ?

[edit] If you're the guy who does the MSDN videos on C++, thank you*. They've been incredibly useful to me.

Re: Popular Myths about C++, Part 1

#132

Post by jbergens »

Scea91 wrote: post #78
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…

With the recent updates to the standard C++ is actually a really pleasant language to use. You just have to know a lot, but the reward is there.

Yes, but it seems the whole team (or all teams in large enterprise projects) must know a lot. Otherwise you still and up with a lot of hard to read, unsafe code. If you start with a very large codebase of old C/C++ you might have to rewrite large parts of it to reap the benefits and in that case you might want to look into other languages as alternatives. I agree that for a green field project with very good developers C++ 14 looks nice.

Re: Popular Myths about C++, Part 1

#133

Post by maratc »

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:…

> return "mailto" + ":" + name+'@'+domain;

Apparently, the first `+` is a problem, so just take it away:

    return "mailto"  ":" + name+'@'+domain; // there, problem solved.

Re: Popular Myths about C++, Part 1

#134

Post by throwawayaway »

pjmlp wrote: post #130
throwawayaway wrote: post #120

Earlier quoted context omitted.

people keep using this "new C++ devs" proviso, it's a red herring. to remind you: > What exactly do you need to know about C, that is not part of C++, to understand C++? why can't you memcpy classes but you can structs? it's a confederation of languages, i think coldtea's idea of representing it as a superset is excellent, you cannot understand C++ by taking out its C subset. if that's your attitude where it's not th…

> why can't you memcpy classes but you can structs? Since when?! Try this on a struct and it will go boom! The only difference between structs and classes is the default access specifier. > C++ is full of this. you only get to "why" with C. No, you get the why by knowing Assembly and how computers work. Any system programming language since FORTRAN exposes the same set of issues. We never teached C at our university…

struct_type s1 = {0,0,0,0,0}; struct_type s2 = {0,1,2,3,4};

memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :?

> There were no C lectures, nor teaching what is C or C++.

> Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes

What exactly do you mean by the first statement? You mean you never taught people the difference?

You can't properly explain the existence of the struct data type without C, this is nothing to do with FORTRAN.

> I never saw anyone speaking about learning BCPL to use K&R C, or having to learn Pascal to use Ada or Modula-2.

that is not the argument I am making. the argument people are making is that you can learn C++ without learning C. they seem to be forgetting that in the process of understanding C++, you have to learn C. if you do not understand C, you cannot understand C++.

to transplant your argument, if you take out all the keywords from BCPL that are shared with C and try to learn C without using them, you aren't going to get anywhere.

Re: Popular Myths about C++, Part 1

#135

Post by pjmlp »

throwawayaway wrote: post #134
pjmlp wrote: post #130

Earlier quoted context omitted.

> why can't you memcpy classes but you can structs? Since when?! Try this on a struct and it will go boom! The only difference between structs and classes is the default access specifier. > C++ is full of this. you only get to "why" with C. No, you get the why by knowing Assembly and how computers work. Any system programming language since FORTRAN exposes the same set of issues. We never teached C at our university…

struct_type s1 = {0,0,0,0,0}; struct_type s2 = {0,1,2,3,4}; memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :? > There were no C lectures, nor teaching what is C or C++. > Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes What exactly do you mean by the first statement? You mean you never taught people the difference? You can't properly explain the existence…

> memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :?

This only works if struct_type is a POD.

Meaning no member functions, no virtual functions and no inheritance.

> What exactly do you mean by the first statement? You mean you never taught people the difference?

No, why should I, it is all C++.

It might be called struct, but only the keyword is the same, the semantics are quite different.

So why bother students heads with needless details how a C compiler sees a struct and a C++ sees a struct?

A struct is a class with default public access, that is all.

> You can't properly explain the existence of the struct data type without C, this is nothing to do with FORTRAN.

Why? It is a C++ data type. Why should I use another programming language to explain it?

> If you do not understand C, you cannot understand C++.

I wonder how my students could manage their exams.

You have to learn C++ relation to computer hardware and the design decisions behind it.

This means computer architecture and Assembly, C is not required.

Sure one can explain that some decisions are related to the desire to have C++ interoperate with zero attrition in the C Eco-system, but that isn't required to explain C++ language features.

Do you also want people to learn C before C# and D?

Keywords and programming concepts are common across programming languages.

Re: Popular Myths about C++, Part 1

#136

Post by Scea91 »

jbergens wrote: post #132
Scea91 wrote: post #78

Earlier quoted context omitted.

With the recent updates to the standard C++ is actually a really pleasant language to use. You just have to know a lot, but the reward is there.

Yes, but it seems the whole team (or all teams in large enterprise projects) must know a lot. Otherwise you still and up with a lot of hard to read, unsafe code. If you start with a very large codebase of old C/C++ you might have to rewrite large parts of it to reap the benefits and in that case you might want to look into other languages as alternatives. I agree that for a green field project with very good develope…

I agree 100%.

Re: Popular Myths about C++, Part 1

#137

Post by throwawayaway »

pjmlp wrote: post #135
throwawayaway wrote: post #134

Earlier quoted context omitted.

struct_type s1 = {0,0,0,0,0}; struct_type s2 = {0,1,2,3,4}; memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :? > There were no C lectures, nor teaching what is C or C++. > Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes What exactly do you mean by the first statement? You mean you never taught people the difference? You can't properly explain the existence…

> memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :? This only works if struct_type is a POD. Meaning no member functions, no virtual functions and no inheritance. > What exactly do you mean by the first statement? You mean you never taught people the difference? No, why should I, it is all C++. It might be called struct, but only the keyword is the same, the semantics are quite different. So why bother st…

the question is why does a struct exist at all. just because they could pass an exam is not a great indicator of understanding. if your students put member functions, virtual functions or inheritance into a struct i wonder what mental gymnastics you would engage to explain why they shouldn't do that without using C to do so.

it's like having a debate with the iraqi information minister, you don't even believe yourself what you are saying.

C# and D are sufficiently different, D and C# will not compile most/any C programs.

as soon as any of your students got in to a professional context and have to use C++ in anger, they found out pretty quickly that they actually didn't understand it. you did them a disservice by ignoring C.

the design decisions in C++ are reactions to C - not computer hardware, architecture or assembly. there are a few exceptions to this, but they are small in number.

the "why" is staring you in the face and you are willingly ignoring it. it's actually infuriating to try and learn from someone with this attitude, never explaining why correctly but giving directions with no explanation or falsified explanation.

Re: Popular Myths about C++, Part 1

#138

Post by pjmlp »

throwawayaway wrote: post #137
pjmlp wrote: post #135

Earlier quoted context omitted.

> memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :? This only works if struct_type is a POD. Meaning no member functions, no virtual functions and no inheritance. > What exactly do you mean by the first statement? You mean you never taught people the difference? No, why should I, it is all C++. It might be called struct, but only the keyword is the same, the semantics are quite different. So why bother st…

the question is why does a struct exist at all. just because they could pass an exam is not a great indicator of understanding. if your students put member functions, virtual functions or inheritance into a struct i wonder what mental gymnastics you would engage to explain why they shouldn't do that without using C to do so. it's like having a debate with the iraqi information minister, you don't even believe yoursel…

Everything from C++ can be discussed in the context of C++, there is no need to refer to other languages.

A struct is a C++ data type that offers the same set of features as a class, just with a public access as default.

The use cases for a struct are POD (Plain Old Data) used to aggregate variables that refer to a common data structure, hence struct as abbreviation.

> C# and D are sufficiently different, D and C# will not compile most/any C programs.

But they also have struct. So you don't need to explain struct to those developers?

You can also do memcopy and pointer manipulations in C# and D.

Why shouldn't then they also learn about C?

Regarding the C subset in C++, it is actually C89 with a few semantic changes.

There quite a few examples of C89 compliant code that won't compile with a C++ compiler or will have strange behaviors.

The way struct namespaces work is such example.

Re: Popular Myths about C++, Part 1

#139

Post by throwawayaway »

pjmlp wrote: post #138
throwawayaway wrote: post #137

Earlier quoted context omitted.

the question is why does a struct exist at all. just because they could pass an exam is not a great indicator of understanding. if your students put member functions, virtual functions or inheritance into a struct i wonder what mental gymnastics you would engage to explain why they shouldn't do that without using C to do so. it's like having a debate with the iraqi information minister, you don't even believe yoursel…

Everything from C++ can be discussed in the context of C++, there is no need to refer to other languages. A struct is a C++ data type that offers the same set of features as a class, just with a public access as default. The use cases for a struct are POD (Plain Old Data) used to aggregate variables that refer to a common data structure, hence struct as abbreviation. > C# and D are sufficiently different, D and C# wi…

>Use struts when you just need a data container. Use classes when you need to add behaviour. Simple rule,

> A struct is a C++ data type that offers the same set of features as a class, just with a public access as default.

these are lies. at this point it's a semantic argument, what you mean by "understand" is "use". what i mean by understand is its dictionary meaning.

to answer your questions, no you don't need to explain them or teach C to them because the syntax for struct in those languages is not identical to C. that is why. because they are not C structs. "C++ structs" are C structs with some syntatic sugar applied. C structs will not compile in those languages. C structs are not valid code in those languages.

I am aware of the long list of minor incompatibilities between C89 and C++, and how C++11 has removed some and added more

In short you know nothing about this I don't already know and you are quite happy to knowingly deceive your students. i object but there's no point in debating with you further.

Re: Popular Myths about C++, Part 1

#140

Post by mikeash »

maratc wrote: post #133
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:…

> return "mailto" + ":" + name+'@'+domain; Apparently, the first `+` is a problem, so just take it away: return "mailto" ":" + name+'@'+domain; // there, problem solved.

Of course. Now, do you want to sit down and explain why that's necessary to somebody who's still grappling with the concept of for loops?
Post reply on HN