- What is the data structure of a NULL? - 6 Updates
- Don't be fooled by cpp.sh - 19 Updates
| James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 30 06:03AM -0800 Ned Latham wrote: > James Kuyper wrote: ... > http://www.users.on.net/~nedlatham/Software/mclib/Documents/sourcecode.html > Check AVLC and ListC, also read > http://www.users.on.net/~nedlatham/Software/mclib/Documents/mclists.html That is not the kind of response I was asking for. Let me be more explicit: I'm looking for a single C++ construct, from a single line of code, that you were only able to use because of what you know about how null pointers are represented on the target implementation. That is, inherently, a construct that would not produce the desired result if the code were ported to an implementation that uses a different way to represent null pointers. It's fine if you need to provide additional lines of code, or even system documentation, to provide the proper context for that construct. However, I need you to actually identify the particular construct you're referring to. Can you give me the exact location in that body of code of at least one such construct? Better yet, could you quote that line of code? |
| David Brown <david.brown@hesbynett.no>: Dec 30 05:24PM +0100 On 30/12/2019 12:20, Ned Latham wrote: >> I had a quick look at the code - for the sake of your sanity, don't read >> it. > Well, if you're not going to read any documentation, why bother indeed. You didn't link to documentation - you linked to the source code. The source code was, of course, the important part for the discussion. (I found the document pages too.) >> I don't know what language Ned is trying to use, > Using, David. mclib is a working C++ library. Has been for at least ten > years. I only looked at the source code you linked - it is not complete, because it is written in a sort-of C, sort-of C++, sort-of something else mix using your own macros. >> but it is not C++ >> as other people know it. > The documentation tells you that. And why. No, it does not. >> (Hint - it is full of macros like WHILE and IF >> and the like, which are not defined anywhere. > Don't be stupider than you have to be, David. They are not defined in the source code you linked. They are defined in the file "mcdef.h", which was not in the links (it is in the tarball that can be found by a little digging from your links). There are few thinks more irritating to programmers than some nitwit who thinks it helps to make one programming language look like another. Macros to try to make your C or C++ code like BASIC are /not/ a good idea, and never have been. > The documentation would have told you that AVLC and ListC are designed to > be totally independent of type (past, present and future). Pointers can do > that; templates cannot. They're a code bloat idea, anyway. Had you linked to the documentation, it would have told me that. It says nothing about /why/ that might be a useful idea. (A reasonable answer would be "the code is from 1995, when C++ compilers had limited and inefficient support for templates".) >> free? Ned doesn't.) > Those are design decisions too, idiot. The C++ library throws exceptions. > Exceptions are evil, especially in low-level code. RAII is orthogonal to exceptions. You can use one feature without the other, though they work well together. I can appreciate that your code was written before non-throwing "new" was widely available. Some of your design decisions are reasonable enough for code from 1995 - but hardly examples of how to write C++ in this generation. > And BTW, it's calloc(), not malloc(). Linux malloc() has a tendency to > return "optimistic" pointers, which for my purposes is an unreliable > behaviour. Yes, you mentioned that in your documentation. It was one of many incorrect statements. |
| David Brown <david.brown@hesbynett.no>: Dec 30 05:27PM +0100 On 30/12/2019 11:19, Ned Latham wrote: > What you've got is working code and documentation describing it. The AVLC > Specification document details three funcions that take void* parameters > and also return void*, Extract(), Find(), Insert(). Even though you apparently have no intention of answering Keith's questions sensibly, could you at least say why you think a function returning void* is dependent on the representation of null pointers? Your documentation says your code relies on void* being the same size as int. I didn't see anything in the code that actually depends on that (but I have not gone through it in detail) - but that bears no direct relationship on the representation of null pointer constants. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 30 06:16PM > David Brown wrote: <cut> >> [...] New and delete rather than malloc and free? I suspect this is the heart of the problem. > Those are design decisions too, idiot. The C++ library throws exceptions. > Exceptions are evil, especially in low-level code. > And BTW, it's calloc() You assume that null pointers are represented with all-bits-zero because you want to use calloc, and you want to use calloc because you think new will throw an exception. (If you know about non-throwing new then I can't see any reason for not using it, thereby allowing null pointers to dealt with by a constructor as C++ intended.) Also your test for null pointers being all-bits-zero (as provided by calloc) is flawed: #ifndef NULL #define NULL 0 #elif (NULL != 0) #error NULL is defined as non-zero! 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment