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

Popular Myths about C++, Part 2

isocpp.org

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Popular Myths about C++, Part 2

#81

Post by 72deluxe »

lelandbatey wrote: post #70
fsloth wrote: post #37

Earlier quoted context omitted.

My main gripe is the mental overhead when compared with other languages and the bulkiness of the syntax. Languages that contain lists and maps as first class types and the syntax to go with it are so much nicer. It's no joke that large C++ applications contain a poorly defined subset of common lisp. The standard library is small. Things that are included out of the box in other languages do not. Doing some simple thi…

Yeah, I totally agree on that point. With C++, it's not entirely uncommon to write lines like the following: std::vector exampleparser::tokenize(std::string some_input){ That is unless I'm doing it wrong.

You forgot to explicitly specify the allocator in the vector...... - it'll default to std::allocator and put items on the heap but you could potentially use your own and get it to put stuff on disk instead!

I don't find your example that convoluted to read to be honest.

Re: Popular Myths about C++, Part 2

#82

Post by 72deluxe »

Animats wrote: post #67

"My precious language isn't broken! It's not! Not! Not!" Strostrup writes something like this about once a year. There's some denial there. The basic problem with C++ is that it's hard to tell if something really bad is happening. Think of C++ from the view of the maintenance programmer assigned to figure out why a C++ program is crashing intermittently. Or worse, the security expert trying to figure out how a system…

How is abstraction unsafe?

Additionally, raw pointers are not dangerous. If you're passing them around as const pointers, the receiver can't do things like deleting them. If you are writing a container class (instead of using one of the existing myriad of containers in the STL) then you can use raw pointers. But typically you would not need to write your own container class; just use one of the STL's and the move semantics. You can then use references everywhere instead. Or const references. Everyone forgets about const correctness in their C++ bashing.

For concurrency, you may wish to see http://en.cppreference.com/w/cpp/thread

There's even mutexes in there.

Re: Popular Myths about C++, Part 2

#83

Post by 72deluxe »

spoiler wrote: post #60
jlarocco wrote: post #23

Earlier quoted context omitted.

My biggest complaint about C++ is all of the non-intuitive "gotchas" and corner cases hidden all over the place that seem to change with every new release. A lot of times the obvious code is either subtly broken and/or less efficient than one would expect. Reading through "Effective Modern C++," I was constantly thinking, "How is anybody supposed to remember all of these corner cases?"

I remember working on a small in-house C++ library with a colleague. Being mostly a C programmer, my code in C++ was basically (as he coined it) fancy-C . Then he rewrote my code in "the C++ way," after which the code became completely opaque to me. My initial mistake was that I expected C++ to be like (or similar to) C, a mistake I believe many of us make. C++ is a lot more complex in scope (not necessarily in a bad…

I think you're right there about the differences between C and C++ and the root of the anger towards it. C is completely alien to me - I wouldn't be able to competently write a decent program in it. But C++ is a different matter.

I have worked with people who write C++ in "fancy C" style too.

Re: Popular Myths about C++, Part 2

#84

Post by Jweb_Guru »

72deluxe wrote: post #82
Animats wrote: post #67

"My precious language isn't broken! It's not! Not! Not!" Strostrup writes something like this about once a year. There's some denial there. The basic problem with C++ is that it's hard to tell if something really bad is happening. Think of C++ from the view of the maintenance programmer assigned to figure out why a C++ program is crashing intermittently. Or worse, the security expert trying to figure out how a system…

How is abstraction unsafe? Additionally, raw pointers are not dangerous. If you're passing them around as const pointers, the receiver can't do things like deleting them. If you are writing a container class (instead of using one of the existing myriad of containers in the STL) then you can use raw pointers. But typically you would not need to write your own container class; just use one of the STL's and the move sem…

Creating a dangling const pointer is pretty trivial. Hell, make it a const reference.

    #include 

    struct Foo {
        const int &dangling;

        Foo(const int &dangling): dangling(dangling) { }
    };

    Foo foo() {
        int dangling = 0;
        Foo foo(dangling);
        return foo;
    }

    int main() {
        std::cout
Neither g++ nor clang warn on this, either. I am not sure why you think const pointers are safe. They aren't. Flat out.

Re: Popular Myths about C++, Part 2

#85

Post by spoiler »

spoiler wrote: post #60
jlarocco wrote: post #23

Earlier quoted context omitted.

My biggest complaint about C++ is all of the non-intuitive "gotchas" and corner cases hidden all over the place that seem to change with every new release. A lot of times the obvious code is either subtly broken and/or less efficient than one would expect. Reading through "Effective Modern C++," I was constantly thinking, "How is anybody supposed to remember all of these corner cases?"

I remember working on a small in-house C++ library with a colleague. Being mostly a C programmer, my code in C++ was basically (as he coined it) fancy-C . Then he rewrote my code in "the C++ way," after which the code became completely opaque to me. My initial mistake was that I expected C++ to be like (or similar to) C, a mistake I believe many of us make. C++ is a lot more complex in scope (not necessarily in a bad…

EDIT: [since I exhausted the edit period] I meant to say "I'm not hating on C++" in the last sentence. :-)

Cheers!

Re: Popular Myths about C++, Part 2

#86

Post by ptx »

AnimalMuppet wrote: post #59

So far, all the comments seem to be missing Stroustrup's biggest point: garbage collection only works for memory. Destructors work for everything - memory, file handles, semaphores/locks, database connections, everything. Garbage collection handles 90% of the problem transparently to the programmer. That's wonderful (really - I'm not being sarcastic here). But the problem is, garbage collecting languages usually don'…

Many modern languages have a convenient solution for those cases as well: Python has the "with" statement combined with context managers; C# has the "using" block with the "IDisposable" interface that does essentially the same thing; even Java recently got its corresponding "try-with-resources".

Before those were introduced we had try/finally which works equally well but is slightly more verbose.

Re: Popular Myths about C++, Part 2

#87

Post by 72deluxe »

Jweb_Guru wrote: post #84
72deluxe wrote: post #82

Earlier quoted context omitted.

How is abstraction unsafe? Additionally, raw pointers are not dangerous. If you're passing them around as const pointers, the receiver can't do things like deleting them. If you are writing a container class (instead of using one of the existing myriad of containers in the STL) then you can use raw pointers. But typically you would not need to write your own container class; just use one of the STL's and the move sem…

Creating a dangling const pointer is pretty trivial. Hell, make it a const reference. #include struct Foo { const int &dangling; Foo(const int &dangling): dangling(dangling) { } }; Foo foo() { int dangling = 0; Foo foo(dangling); return foo; } int main() { std::cout Neither g++ nor clang warn on this, either. I am not sure why you think const pointers are safe. They aren't. Flat out.

Well I was assuming for pointers that they'd be initialised to something sensible. That would be a coding standard problem if they're not.

The example you give is also a problem with coding standards, I'd argue. It isn't the languages fault that you're using a reference that's going out of scope - that's just bad coding. (A pointer going out of scope isn't so bad, no?)

Re: Popular Myths about C++, Part 2

#88

Post by AnimalMuppet »

ptx wrote: post #86
AnimalMuppet wrote: post #59

So far, all the comments seem to be missing Stroustrup's biggest point: garbage collection only works for memory. Destructors work for everything - memory, file handles, semaphores/locks, database connections, everything. Garbage collection handles 90% of the problem transparently to the programmer. That's wonderful (really - I'm not being sarcastic here). But the problem is, garbage collecting languages usually don'…

Many modern languages have a convenient solution for those cases as well: Python has the "with" statement combined with context managers; C# has the "using" block with the "IDisposable" interface that does essentially the same thing; even Java recently got its corresponding "try-with-resources". Before those were introduced we had try/finally which works equally well but is slightly more verbose.

Yes, you can do this with try/finally. But if you have an object that has an open file as a member, then you open the file in the constructor, and then use the open file in the member methods, and then... what? You may have a scope that you are exiting where that object becomes irrelevant, but it may be several layers away. Having to close that object's handle in a finally in that scope seems likely to be forgotten at least some of the time.

Re: Popular Myths about C++, Part 2

#89

Post by jonkalb »

vitd wrote: post #58
jlarocco wrote: post #23

Earlier quoted context omitted.

My biggest complaint about C++ is all of the non-intuitive "gotchas" and corner cases hidden all over the place that seem to change with every new release. A lot of times the obvious code is either subtly broken and/or less efficient than one would expect. Reading through "Effective Modern C++," I was constantly thinking, "How is anybody supposed to remember all of these corner cases?"

I concur with this. I use C++ daily and have been for about 20 years, and I still run into gotchas and things I misunderstand all the time. I feel it's even worse than that, though. There seems to be a culture among C++ programmers to do things in overly clever ways and to push the limits of readability and understandability. Just look at the headers for the standard C++ template library, for example. (I'm currently…

Looking at the headers is not the way to learn about the library. Anything that you learned that wasn't documented in the standard or any of the many books, articles, and videos available would be an implementation detail that you couldn't rely on in portable code or even in the next version of gcc.

These files are only intended to be seen by the compiler and it doesn't complain about indentation or single letter variables.

Re: Popular Myths about C++, Part 2

#90

Post by Animats »

72deluxe wrote: post #82
Animats wrote: post #67

"My precious language isn't broken! It's not! Not! Not!" Strostrup writes something like this about once a year. There's some denial there. The basic problem with C++ is that it's hard to tell if something really bad is happening. Think of C++ from the view of the maintenance programmer assigned to figure out why a C++ program is crashing intermittently. Or worse, the security expert trying to figure out how a system…

How is abstraction unsafe? Additionally, raw pointers are not dangerous. If you're passing them around as const pointers, the receiver can't do things like deleting them. If you are writing a container class (instead of using one of the existing myriad of containers in the STL) then you can use raw pointers. But typically you would not need to write your own container class; just use one of the STL's and the move sem…

How is abstraction (hiding) unsafe?

Objects hide their implementation details. An object is only a valid abstraction if it correctly hides its implementation details and the user can ignore them. If there are hidden constraints on what a user can do with an object, but those are not enforced by the object, the object is an unsuccessful abstraction and a potential source of bugs.

Additionally, raw pointers are not dangerous.

Two words: "buffer overflow". C pointers lose size information.

Post reply on HN