bright@Data-IO.COM (Walter Bright) (11/24/88)
In article <1304@cod.NOSC.MIL> mball@cod.nosc.mil.UUCP (Michael S. Ball) writes: >In article <3637@pt.cs.cmu.edu> agn@unh.cs.cmu.edu (Andreas Nowatzyk) writes: >>(1): In case you wondered how this can happen: the inline-function >> needs to know the line-number of where it appears in the source code. >The only way an inline function can tell the line number at a call >is to pass the line number as a parameter to the function, in which >case it will work whether expanded or not. Inline function processing is >done long after preprocessing, which is where the line number is known. This is a rather significant problem with inlines. On a related issue, in my C programs, if I enable debugging: #ifdef DEBUG #define malloc(s) malloc_debug((s),__LINE__,__FILE__) #define free(p) free_debug((p),__LINE__,__FILE__) #endif My debugging allocator stores the line and file of where the alloc occurred, and some other info. The object is to be able to: 1. Track down wild pointers. 2. When storage is not free'd, report where it was allocated. 3. Detect cases where you attempt to free pointers that weren't allocated. 4. Detect cases of trying to free a pointer more than once. 5. A few other things. The point is, I find this extremely useful. But the overhead for it is high, so I like to be able to turn it off with the DEBUG switch. The trouble with inline functions is that the __LINE__ and __FILE__ are expanded at the *definition* of the function, not at its use. The trouble with new and delete is that there appears to be no way to have the line and file silently added (without modifying the compiler itself). Can anyone figure a way out of this? I'd really like to have a reasonable solution...