Thread: assert(tree != NULL) doesnt fail

  1. #16
    Registered User
    Join Date
    Apr 2019
    Posts
    662
    Quote Originally Posted by laserlight View Post
    I asked you why, not "give me another example in which you did this unnecessary thing". So nope, you don't have to do that. Not for list, not for tree.
    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 ......

  2. #17
    Registered User
    Join Date
    May 2019
    Posts
    209
    @cooper1200, are you as short on sleep as I am?

    My wife and my cats are my excuse...and I'm going for a nap again soon

  3. #18
    Registered User
    Join Date
    Apr 2019
    Posts
    662
    its a long story but yes....im a little short tempered today sorry

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,064
    Quote 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.)
    Last edited by laserlight; 06-14-2019 at 06:33 AM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    Registered User
    Join Date
    May 2019
    Posts
    209
    @cooper1200, it's all good. I was just noticing that since you signed off at 1am your time, and your up and going (what, 6 hours later?) that you're rather busy.

    @laserlight's point is rather refined and may take a while to absorb, as I have managed to follow your progress (it's been quite interesting) through several threads. The points in the previous post by laserlight is about overall design and user perspective which you'll begin to consider once you have rotations in hand.

    I'll check in later, I think you have material in our 4 page exchange that gets you well into rotation.

  6. #21
    Registered User
    Join Date
    Apr 2019
    Posts
    662
    @laserlight i do appreciate all the help you have given me as i appreciate all the help from others and apolagise if you thought i didn't.
    one of the issues with learning from a book or the internet is its easy to fall into the mindset of right this is the way they have done it it must be the only way. i hadn't thought about why they were allocating memory for the list struct or in this case for the tree.

    i guess another failing of mine is i don't look at my code as a commercial thing. its more of a tool to build knowledge and maybe for my own personal use

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Assert: When to and when not to.
    By Shamino in forum C++ Programming
    Replies: 22
    Last Post: 01-27-2012, 09:55 AM
  2. fail to count digit of an integer (fail at 9)
    By azsquall in forum C++ Programming
    Replies: 3
    Last Post: 05-02-2008, 09:42 AM
  3. accept(ListenSocket, NULL, NULL); cause program to hang?
    By draggy in forum Networking/Device Communication
    Replies: 11
    Last Post: 06-16-2006, 03:40 PM
  4. Assert
    By Shamino in forum C++ Programming
    Replies: 8
    Last Post: 01-24-2006, 11:02 AM
  5. assert
    By ammar in forum C++ Programming
    Replies: 1
    Last Post: 10-19-2002, 08:17 AM

Tags for this Thread