Data structures and Algorithms in C/C++11 | Hacker News Reader

Data structures and Algorithms in C/C++11

github.com

19 pointszyngaro15 comments

    class Tree {
    public:
    ...
      ~Tree() { ...
    ...

If you have create a non-final class with a public non-virtual destructor, you are basically guaranteed that code using your library will have memory leaks.

Sorry if this is an ignorant question, but can you elaborate on this? It's not clear to me why this would lead to memory leaks.

for example: http://stackoverflow.com/questions/461203/when-to-use-virtua...

class B : public A { ... } void foo() { A* someA = new B(...); ... delete someA; }

if A destructor is not virtual, then B's resources leak.

This covers the standard reason

http://stackoverflow.com/questions/461203/when-to-use-virtua...

If the destructor isn't implemented in derived classes, they will use the parent's destructor. Not a guaranteed memory leak..... but something you need to be aware of.

It's worse than that - if you ever have a a variable with the static type of the base class but the dynamic type of a derived class, memory will leak, even if you've implemented the destructor in derived classes. For example, this code:

  class Base {
    public:
      Base() {}
      ~Base() {}
  };

  class Derived : public Base {
    private:
      Foo* _foo;
    public:
      Derived() : _foo(new Foo) {}
      ~Derived() { delete _foo; }
  };

  int main() {
    std::unique_ptr<Base>(new Derived);
  }

The problem here is that if the destructor is not marked virtual, then when unique_ptr<Base> goes to invoke the destructor, it calls ~Base instead of ~Derived. That has no knowledge of Derived's member variables, so any memory that Derived allocated leaks. (Technically, it's undefined behavior and can do whatever it wants, but most implementations in practice will call ~Base.)

So this means the code is in C++ and not in C? The title should be more explicit on that. It's like advertising your code is in C++/C#.

> So this means the code is in C++ and not in C? The title should be more explicit on that. It's like advertising your code is in C++/C#.

It appears to be mixed. The files ending in .c contain C, the files ending in .cpp contain C++. See the Makefile, which will compile each with the relevant compiler.

Also, did you reply to the right parent?

Is it considered idiomatic to mix in test and production code in the same file, and therefore the same binary?

Also, is it considered idiomatic to not leave any commentary breadcrumbs on what files and classes and structures are for? I get that lists.h probably contains lists, and I'm guessing linked lists from the code. The rest of it is guesswork.

No. This code is fine--clean, journeyman code--but it's quite a bit below what you'd expect from the STL, Boost, or other premier libraries. Sometimes the implementations of such projects seem obfuscated, but that's often a legacy of trying to work with older, broken compilers and/or to protect against obscure corner cases.

There is no language called C/C++11 . Why do people insist on suggesting that these two languages are the same?

I didn’t feel like the author was conflating them, merely that this repo is a mixed bag of sample code in both C and in C++. The Makefile appears to compile the .c files with a C compiler, and the C++ files with a C++ compiler.

Also, the two languages, while certainly not the same language, do have parts in common, and do interoperate decently well together.

You are right. They do "interoperate" fairly well together. It is kind of like a 64 bit Linux machine can run 32 bit binaries, but a 32 bit machine can't run 64 bit code. A C developer could probably be extremely productive in C++, but reverse this and it probably wouldn't be true.

As a consequence of using all the abstraction that C++ provides, one cannot simply dive right into C and expect the same level of productivity.

> As a consequence of using all the abstraction that C++ provides, one cannot simply dive right into C and expect the same level of productivity.

Absolutely true. What I meant by "interoperate" is that it's decently easy to call C functions from C++; the other way is also possibly, but you more or less have to pass C types around, which limits productivity somewhat.

This doesn't look like a very well organized or generalized code. It reminds me of my own repo I had in school for TopCoder competitions: https://github.com/Slava/competitiveProgramming/tree/master/...

Reply on news.ycombinator.com