Talking to C Programmers about C++ [video] • Hacker News Board

Re: Talking to C Programmers about C++ [video]

#101

Post by gravypod » Sun, Sep 25, 2016, 3:39 PM UTC

sseagull wrote: post #98

gravypod wrote: post #80

Earlier quoted context omitted.

The conversation then shifts to how it does this? What if I want to print to something else? Why if I want to read differently from a stream? When you provide a shorthand that's all well and good but when you TEACH a short hand it's what's ONLY used by the students. The students will assume there is no other way to read and write then using >> and So many of the students in my CS class this semester can't do the firs…

I will agree with the point that the other methods of reading/writing from streams aren't taught early enough, and that formatted output is pretty bad with streams. I've actually written a wrapper around snprintf for printing in c++ (I should put that on github sometime) Your project looks good. Two minor observations: 1.) You have 'using' statements in a header file. This is fine for a small project, but is consider…

I wasn't sure how const worked in this language so I decided not to mess with it yet.

Coming from Java I have a blanket policy that every variable is final unless needed to be modified. I've run into those pain points.

Your first observation is one I have some into as well but I haven't been taught how to do this.

For example if my header file needs to define the method:

   void test(std::string something);

Is it bad form to them define the header in my cpp file as such?

   void test(string something);

Isn't that also bad form? Coming from C some things like this could be done but very much shouldn't have been done.

I know for a fact that namespacing is one of the hugest benifits to large projects I just don't know how to use the tools provided by C++ to do it correctly. Java? Yea I can get anything you want nice and tucked away. But C++ with the way headers and namespacing works its difficult to obviously see what I want to do and how to get it done.

Any examples?

Re: Talking to C Programmers about C++ [video]

#102

Post by gravypod » Sun, Sep 25, 2016, 3:51 PM UTC

hackits wrote: post #95

gravypod wrote: post #90

Earlier quoted context omitted.

My issue with RAII is that it's fundamentally not what you expect to happen. If I say: int i; I don't expect that to create an integer. I expect that to reserve memory in the program's space for an integer. In the same way I don't expect this to call malloc: int *i; I just expect that to hold the space in the program data where and int pointer can be stored. Furthermore I don't expect this to run any code (just as th…

Hi gravypod. It depends . Oh I hate that word. When I see int i; without context I don't know anything about where memory is allocated. It can either be the following. 1) Stack allocated 2) Heap allocated 3) Is in the read only data segment. Just starting with a int, it can be any of the above three, two that reserve the memory on the heap/stack and another that is only a read only part of memory. The heap is the onl…

Isn't "It depends" part of the problem?

For instance my professor when explaining to the other students why we use context-free grammars for parser he said "we always want a language to work how we tell it to. An if doesn't mean something different depending on where it is"

While I do agree that he is incorrect and that is a very close minded, and out dated, view of language design he is accidentally correct in another sense.

I'd like to ask "why" C++ chooses int i is different based on the location. I know the answer myself, but my peers don't and probably wont until years of pain in industry while parroting the same nonsense that C++ is the best language same as all of the other loons who think that there is a "best language".

Why is it ok for struct packing, for aligning data, and for initial memory state to decide how the program behaves?

In C++ it does, in C it's more sane but it sill happens.

> RAII helps in the situation where instead of having to do tedious code such as.

How is:

   string s = "";

and

   int i = 0;

Tedious? That seems like the sane alternative as it puts the behavior in the hand of the programmer. In nearly every language this is decided as the preferred way of allocating variables. Define AND assign to create something useful.

I don't think I understand how adding more case-specific behavior that doesn't apply to everything should be considered sane. It's more edge cases that aren't needed.

It's much simpler to say "we are just going to hold a slot in memory for any object, you need to initialize it" or to say "we are going to have default initialization for EVERY object even primitives" but it's horrible to say "we're going to do a combination of both and you have to figure it out"

Re: Talking to C Programmers about C++ [video]

#103

Post by gravypod » Sun, Sep 25, 2016, 3:53 PM UTC

KKKKkkkk1 wrote: post #81

gravypod wrote: post #35

The problem with C++ is the constant introduction of unneeded features that are infinity obscure in necessity. People will say "Oh just don't use that feature" but that's not how this works. If something is there it is used. In reference to C, I don't think I know of a single feature or release that had major changes in how I wrote C. Maybe C99 and allowing me to declare in a for loop. I've been using C++ for class t…

The other thing about C++ is that you start by saying "I'll write C and only use this one extra feature from C++." and thereby you open a Pandora box. You decide to use reference types, and all of a sudden your classes are not default-assignable.

I just don't use classes. I'd like to but again it's just not a good idea.

I also don't like default constructors see my other post as to why I think they are not reliable behavior to the programmer if they don't have experience in the language.

Again I didn't lie when I said "I am using C in C++" as I am using C in C++.

Re: Talking to C Programmers about C++ [video]

#104

Post by pjmlp » Sun, Sep 25, 2016, 3:58 PM UTC

qwertyuiop924 wrote: post #73

pjmlp wrote: post #67

Earlier quoted context omitted.

> Well then, that's your problem: C++ is trying to be both low-level and high level at the same time. This isn't a good idea, IMHO. It is a very good idea and C++ isn't alone there. Professional Basic dialects, Turbo Pascal, Delphi, Modula-2, Modula-2+, Modula-3, Ada, D, Rust, Mesa/Cedar all share this idea that you can program at both levels, depending on the needs of the use case.

C++ has less distinction though, and it's so huge that even Bjarne can't keep the whole language in his head. The net result is that many people use the low-level parts of the language for high-level work and vice-versa.

The same applies to the languages I listed, given the amount of years they have.

C++ main issue has always been C's compatibility and the C subculture.

The copy-paste compatibility was necessary to bring C developers over the fence to C++, with minimal changes to their tooling.

So C++ inherited all the flaws and UB from C.

Then many of those kept using C++ as plain C with Classes, which influences many of the design decisions regarding language semantics, specially given backwards compatibility as no one wants to repeat Python's error.

Having said this, although I enjoy playing with template metaprogramming, I hope never have to deal with SFINAE, declpspec and function return arrow syntax in production.

Re: Talking to C Programmers about C++ [video]

#105

Post by dunkelheit » Sun, Sep 25, 2016, 4:41 PM UTC

caseymarquis wrote: post #75

dunkelheit wrote: post #30

Earlier quoted context omitted.

Your list of common features is a bit too broad. For instance a common sentiment among game programmers is "STL is shit, you better don't touch it at all".

What's the reasoning? I haven't regularly used c++ for ~8 years, but I know the basics. I thought the downside to STL was increased executable size? If there are no generic constraints I can imagine issues popping up; effectively using generics in .NET often means using a non-generic abstract base class, building the generic class on top of that, and then constraining the generic type to the abstract class. A pain co…

I guess the main gripe is performance. Using STL containers involves lots of implicit heap allocations and copying things around (this last thing should have improved after the introduction of move semantics, does anyone have any numbers on that?). Most of the times performance is perfectly acceptable but a few cases when it is not + inertia can give rise to this anti-STL sentiment.

Here for example std::string takes a beating: https://news.ycombinator.com/item?id=8704318

Re: Talking to C Programmers about C++ [video]

#106

Post by qwertyuiop924 » Sun, Sep 25, 2016, 7:01 PM UTC

pjmlp wrote: post #104

qwertyuiop924 wrote: post #73

Earlier quoted context omitted.

C++ has less distinction though, and it's so huge that even Bjarne can't keep the whole language in his head. The net result is that many people use the low-level parts of the language for high-level work and vice-versa.

The same applies to the languages I listed, given the amount of years they have. C++ main issue has always been C's compatibility and the C subculture. The copy-paste compatibility was necessary to bring C developers over the fence to C++, with minimal changes to their tooling. So C++ inherited all the flaws and UB from C. Then many of those kept using C++ as plain C with Classes, which influences many of the design…

...But that's not often how those languages are used.

And most of those "flaws" aren't flaws in C: They were deliberate design decisons. Arguably bad ones, yes, but they were made a reason. By C++, most of those decisions didn't have any reasons, or were actively against C++'s goals, if not C.

I know you hate C, but blaming C for C++'s problems is like blaming dogs for the monstrous dog demon that someone made with gene editing. C compatability was a bad idea, but you can't blame C for that. Also, it's overly baroque.

But yeah, I think we can all agree that complex TMP is kinda sucky.

Re: Talking to C Programmers about C++ [video]

#107

Post by pjmlp » Sun, Sep 25, 2016, 7:33 PM UTC

qwertyuiop924 wrote: post #106

pjmlp wrote: post #104

Earlier quoted context omitted.

The same applies to the languages I listed, given the amount of years they have. C++ main issue has always been C's compatibility and the C subculture. The copy-paste compatibility was necessary to bring C developers over the fence to C++, with minimal changes to their tooling. So C++ inherited all the flaws and UB from C. Then many of those kept using C++ as plain C with Classes, which influences many of the design…

...But that's not often how those languages are used. And most of those "flaws" aren't flaws in C: They were deliberate design decisons. Arguably bad ones, yes, but they were made a reason. By C++, most of those decisions didn't have any reasons, or were actively against C++'s goals, if not C. I know you hate C, but blaming C for C++'s problems is like blaming dogs for the monstrous dog demon that someone made with g…

Those decisions are documented in "The Design and Evolution of C++".

Re: Talking to C Programmers about C++ [video]

#108

Post by gravypod » Sun, Sep 25, 2016, 7:39 PM UTC

hackits wrote: post #77

Koshkin wrote: post #74

Earlier quoted context omitted.

Problem is, using destructors (and RAII) may have, in general, certain performance implications that C may not be willing to deal with. This is somewhat similar to demanding that C had a garbage collector built in. Note that, being lazy, memory management by means of garbage collection may turn out being more efficient than using the (eager) destructors.

Don't see how there could be any performance implications with having RAII within C. It would be a simple method call with the this pointer to the struct during complication. Though if your performance consideration is at the assembly code level why use C? I've had some good/bad experiences with garbage collectors. They do help improve productivity and ROI within the enterprise space where memory isn't too much of of…

If anything this video shows us that there is probably a lot less of a performance hit actually is take.

That's one of the things mentioned in the source video.

Re: Talking to C Programmers about C++ [video]

#109

Post by IshKebab » Sun, Sep 25, 2016, 7:51 PM UTC

faragon wrote: post #25

In my opinion, many C++ projects would be simpler, cheaper, safer, and better maintained, if were written in C (with adequate libraries, e.g. for strings, vectors, maps, threads, timers, sockets, etc.).

I guess you're joking, but just in case, C++ prevents entire classes of errors that are almost guaranteed in C projects.

Re: Talking to C Programmers about C++ [video]

#110

Post by loeg » Sun, Sep 25, 2016, 8:10 PM UTC

pjmlp wrote: post #62

loeg wrote: post #45

Earlier quoted context omitted.

The obvious comparison is C — where it is common to know 95-100% of the language. (The 5% I'd pick is general disagreement about expectations of UB and "weird" pointers, like pointers to array types.)

People that don't write portable C code think that they know 95-100% of the language. I don't miss the days in the late 90's, early 2000, writing portable C code across multiple compilers from each OS vendor, across all major UNIX flavours and Windows. Many that think to master C, actually master C in compiler X targeting OS Y.

What a sweeping generalization. Perhaps. But it's certainly easier to master portable C than portable C++.