

Data structures and Algorithms in C/C++11 - zyngaro
https://github.com/iyedb/datalgo

======
mgraczyk

        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.

:(

~~~
bhangi
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.

~~~
eclipsor
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.

~~~
nostrademons
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.)

------
ryanobjc
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.

~~~
jonstewart
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.

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

~~~
deathanatos
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.

~~~
_RPM
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.

~~~
deathanatos
> 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.

------
imslavko
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/...](https://github.com/Slava/competitiveProgramming/tree/master/prewritten-
code)

