Live data from Hacker News

Popular Myths about C++, Part 1

isocpp.org

111–120 of 144 posts

Re: Popular Myths about C++, Part 1

#111

Earlier quoted context omitted.

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…

You need to understand so much about C to even talk about pointers in C++, and everything related to them, it's not funny. RAII -> Why? nullptr vs. NULL -> Why? Pointers -> Why? Don't use them in a certain way -> Why? The answer in all cases is C.

>The answer in all cases is C.

Starting to sound like a broken record. No, the answer in all cases can also be found in C++, and understood in C++ terms alone. C++ is a SUPERSET of C, not just an arbitrary language + C.

Re: Popular Myths about C++, Part 1

#112

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…

> Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints?

At work no. Typical enterprise world using JVM and .NET languages.

For side projects, surely yes!

It is the only language supported across all mobile OS SDKs with full access to the hardware.

If you have control over the codebase, the ability to use C++11/14 is quite comfortable, even in terms of memory management.

Now for the typical enterprise projects, with offshore developers at work I wouldn't use it. I already cry when I look at code written in less powerful languages.

Re: Popular Myths about C++, Part 1

#113
post #104

I'm looking forward for the next part, as the last three myths are the ones I'm waiting for their answers, as they should be pretty interesting. C++ has come a long way, and I really feel C++ 11 could very well replace Java as a learning language for computer science students (I don't think it'd be a good choice for an introduction to programming for non CS students), and I see many benefits in this, the biggests bei…

My biggest issue with most garbage collection implementations is the lack of RAII. While I love the ease of reading and writing Python or Lua, I'd love to be able to create a local object, like an open file or a database connection, and have it destructed immediately on return.

You can do this in all modern GC languages.

Either with a using/try with resources/with construct, or by using closures.

    // Pseudo language with FP capabilities
    let withFile filename action = 
        let fd = open filename
        action fd
        close fd

    withFile "config.sys" (fun fd -> write (readlines fd))
Real production code would also take care about proper closing the file in case of errors.

Re: Popular Myths about C++, Part 1

#114
post #98

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…

Standard libraries are part of the language. I would go so far as to say anybody who designs a language that isn't meant to make their standard libraries powerful, consistent, and elegant isn't doing any favors for the discipline.

C++ is a bit different in the variety of domains that it's applied to. To expect the same standard library to be useful in games, microcontrollers, medical instruments, aircraft control systems, kernels, and CRUD apps is a huge ask.

Maybe you don't like that, which is fine. But C++ is much broader than what's available in the standard library. C++ is a close second to C in the "how optional is the standard library?" contest.

Re: Popular Myths about C++, Part 1

#115

Good luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you. BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.

> BTW, 'multi-paradigm' is an oxymoron.

False.

What's a paradigm? It's a way of viewing things. What ways are there of viewing programming? Well, there's functional, there's structured, there's object-oriented, there's generic, and maybe some more.

Can C++ be used to write non-object-oriented, non-functional, purely structured-programming-style procedural code? Yes, it can. (Essentially, that's the subset that's in common between C and C++.) Can it be used to write object-oriented code? Certainly. Can it be used to write functional code? Again, yes (though not nearly as purely as the Haskell zealots would like - but C++ doesn't enforce the purity the way Haskell does precisely because C++ is multi-paradigm). Can C++ be used to write generic code? Yes. (I have heard that the STL was written in C++ because, at the time, it was the only widely used language that would do what Stepanov wanted to be able to do.)

Four different paradigms. You can write C++ code using any of them, or you can mix and match. That's multi-paradigm.

Or are you arguing that, if you have more than one paradigm, you don't have any? That might be true of a program, though I think that the argument is merely a matter of definition, and therefore not very interesting. But if the language makes it easy to write in several paradigms, it seems perfectly appropriate to call it multi-paradigm.

Re: Popular Myths about C++, Part 1

#116

Earlier quoted context omitted.

Try it with optimizations on: gcc -std=c99 -O3 -Wall -Wextra test.c -o test g++ -std=c++11 -O3 -Wall -Wextra test.cpp -o test In my experience, C++ compilers are great at eliding temporaries and various constructor calls (and related memory allocations), but only if optimizations are turned on.

Made no difference

Thanks. It was worth a shot. Which version of GCC are we talking about?

Re: Popular Myths about C++, Part 1

#117

Earlier quoted context omitted.

Made no difference

Thanks. It was worth a shot. Which version of GCC are we talking about?

The different versions of gcc and clang that I tried are higher up in this thread: https://news.ycombinator.com/item?id=8722519

Re: Popular Myths about C++, Part 1

#118
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?

Some examples using Modula-2, a Mesa's successor.

How it allows for all the C pointer features, while adding a little bit more safety.

    MODULE examples;
    IMPORT Terminal, SYSTEM;

    (* procedure with reference parameter, no need for pointers *)
    PROCEDURE ChangeParam (VAR changeMe: CARDINAL);
    BEGIN
      changeMe := 25;
    END ChangeParam;

    (* 
       procedure with a slice, bounds given by HIGH(changeMe) and LOW(changeMe).
       also a string in this case
       no need for explicit pointers
    *)
    PROCEDURE DumpLetters (VAR letters: ARRAY OF CHAR);
    VAR
      i : CARDINAL;
      
    BEGIN
      FOR i := 0 TO HIGH(letters) DO
         WriteChar(letters[i]);
      WriteLn;
      (* Or just use *)
      WriteString (letters);
    END DumpLetters;


    VAR
      anInt : CARDINAL := 12 ;
      aPtr : POINTER TO CHAR;
      aBuffer : ARRAY [1..2] OF CHAR;
      anAddr : ADDRESS; (* think void* *)
      aPtr2 : POINTER TO CHAR;
      
    BEGIN
      WriteInt(anInt); (* writes 12 *)
      ChangeParam (anInt);
      WriteInt(anInt); (* writes 25 *)
      DumpLetters ('A simple string');
      NEW(aPtr); (* The compiler knows the size, no need for sizeof, but you can use ALLOCATE(aPTR, SIZE(CHAR)) if you want *)
      
      (* This is where it shares the same problems with C, due to manual memory control  *)
      DISPOSE(aPtr); 
      
      (* do pointer arithmetic if really required *)
      anAddr := SYSTEM.ADDADR (SYSTEM.ADR(aBuffer), SIZE(CHAR) * 1); 
      aPtr2 := SYSTEM.CAST(POINTER TO CHAR, anAddr); (* aPtr2 now points to aBuffer(2) *)
    END examples;
So the compiler will mark this module as unsafe since the meta-package SYSTEM is being used.

All Modula-2 successors, have GC support, as such the DISPOSE() would have to be written as SYSTEM.DISPOSE() and could only be applied to untraced pointers.

Re: Popular Myths about C++, Part 1

#119

Earlier quoted context omitted.

You need to understand so much about C to even talk about pointers in C++, and everything related to them, it's not funny. RAII -> Why? nullptr vs. NULL -> Why? Pointers -> Why? Don't use them in a certain way -> Why? The answer in all cases is C.

> The answer in all cases is C. Starting to sound like a broken record. No, the answer in all cases can also be found in C++, and understood in C++ terms alone. C++ is a SUPERSET of C, not just an arbitrary language + C.

cheers for the broken record warning.

i will now abstain from further conversation - i will leave you with this - i don't care to read your answer in case i have to respond and you might have to deal with some more repetition:

using the language of sets, the set of C++ minus the set of C, with what is now left:

how can you explain the things i have listed?

Re: Popular Myths about C++, Part 1

#120
post #110

Earlier quoted context omitted.

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"

> why do structs exist and why are their members public? why don't you just use classes with public? To be able to reuse existing C code in a C++ compiler, while allowing them to participate in class hierarchies. This is the real reason, but you don't need to explain it like that to new C++ devs. Use struts when you just need a data container. Use classes when you need to add behaviour. Simple rule, no need to talk a…

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 the real reason, but you think your explanation is sufficient:

your withholding information is limiting my education and as a student i would hate that. your explanation isn't an explanation, it's an order/instruction without explanation, C++ is full of this. you only get to "why" with C.

Post reply on HN