Yes, quite right. I was not being critical of gcc, but of my own coding orientation. I've reached similar conclusions as you outline
There is a rather large body of material I desperately need to read and absorb. That's exactly the problem I'm trying to contend with in trying to convert my work to Linux/gcc/x/ppp... and why some gentle assists from the list are so useful in helping me get started David ----- Original Message ----- From: Colin Watson <[EMAIL PROTECTED]> To: <debian-user@lists.debian.org> Sent: Sunday, February 13, 2000 2:54 AM Subject: Re: Segmentation fault > [EMAIL PROTECTED] (davidturetsky) wrote: > >I see from further investigation that gcc wants me to be more actively > >concerned with memory management than was required under Visual C, and I was > >logging on to apologize for bothering the list. I posted because this code > >ran cleanly under Visual C, so I thought I ran into a Linux nuance > > > >It looks as though I was running into problems when trying to scan an input > >file using c notation which is less efficient of memory, so I'm in the > >process of revising all of the I/O to use c++ resources. > > This surprises me; I'd have thought stdio was more memory-efficient than > iostreams, if it's an issue at all (which I rather doubt). Regardless, a > segmentation fault is an indication of a memory access bug in your > program rather than running out of memory (it may not have happened in > Visual C simply because you were lucky in the way Visual C allocated > memory for you), so you may be trying to fix the wrong problem by doing > all this rewriting. (Of course, you may be lucky and accidentally fix it > in the process, or the problem may have been that you didn't know how to > use stdio and are more successful in using iostreams, but I suppose it > depends whether you actually want to know what you're doing ...) > > >In general, I am beginning to notice that gcc's posture is that you do more > >for yourself. It also seems to be strictly limited to ANSI c. For example, > >there doesn't seem to be any support for min, max, and itoa and I ended up > >writing/rewriting that portion of the code > > I think you desperately need to read 'info gcc' and 'info libc'. gcc is > notoriously far from limited to ANSI C. :) > > Actually, your problem is not with gcc, it seems to be that the GNU C > Library (libc/glibc) doesn't have what you want; it's far from limited > to ANSI C either, but any C programmer worth his/her salt knows that if > you use extensions in your code you should expect them not to be > portable. glibc simply has different extensions to Visual C; in general > I've found it a much more helpful and much better documented C library > than the Microsoft one, but I may be biased. > > Besides, min(), max(), and itoa() are hardly difficult. How about: > > #define min(a,b) ((a) < (b) ? (a) : (b)) > #define max(a,b) ((a) > (b) ? (a) : (b)) > > ... or equivalent function definitions if the double evaluation bothers > you, and sprintf() instead of itoa()? If you program in ANSI C wherever > possible to start with rather than lazily using extensions, you'll have > a much easier time of it.
