Thread: assert(tree != NULL) doesnt fail

Originally Posted by cooper1200

well as many highly competent programmers looked over my double linked and single linked lists and you yourself helped me with getting the correct terms for passing in and out of the functions

As I have resumed work after a two-year partial break for postgraduate studies, I cannot keep track of what you've been doing, and I don't have the time to look over every single aspect of your programs.

The thing is that, broadly speaking, there are two general approaches to writing libraries: the library can have structs for which users of the library are permitted access to the internals of the structs, or the library can have structs for which users of the library are not permitted access to the internals of the structs.

The former is basically the approach that you appear to be taking. In this approach, an advantage is that even if you didn't foresee some usage that requires access to the internals of your library, users of your library can write the missing functionality themselves, and they aren't necessarily limited to how exactly you want to create objects of types from your library, as is my point here: they wouldn't need to dynamically allocate a list or a tree if they don't need it; your library would handle whatever internal dynamic allocation of the internals (or they could even write variations of it themselves). Forcing users of your library otherwise is just unnecessary: they can always override you, so why make it difficult for them to do so?

As long as you don't rename struct members, you use typedefs to provide some flexibility to change types, etc, you can still have some backwards compatibility as you improve your library. The disadvantages of course is that such changes to the internals are limited if you don't want to break backwards compatibility, you may have a harder time enforcing constraints, and then even a backwards compatible change to say, a struct, may require users of your library to recompile their own code.

The latter is an approach that allows you to change the internals of your library with impunity. You can rename struct members, delete them, change their types to completely different types, etc, and if you're using the opaque pointer idiom, users of your library don't even need to recompile their code: they can just relink. The disadvantage then is that if you designed your library interface poorly, users of your library would be stuck with whatever you gave them. Now, with the opaque pointer idiom to implement this approach, users of your library cannot create objects of struct types from your library at will: they won't know the internals, so they can neither declare a variable on the stack nor use sizeof with malloc. Rather, under this approach, you would provide functions to create and destroy the objects through the opaque pointer, and these would presumably wrap malloc and free or some other possibly OS-specific memory allocation/deallocation functions.

One of my favourite examples of this latter approach is SQLite3: it's well documented so you can see what everything is about, and over the years they have tried to maintain backwards compatibility even when they realised that function signatures need to change, so you can see how the interface has evolved by comparing the legacy functions to the current ones. (They also have a rather easy to use one header + one source file that you can compile with your program approach, but this source file is an amalgamation of their actual source files, so it isn't quite so simple to copy their approach.)