At 23:36 on 15 Oct 2005, Victor A. Wagner wrote, in response to my message:
>> And surely, we should ban the use of C++. It DOES NOT adhere to the
>> C standard!!!!
>
> of course it doesn't, it's a new and better language. (this isn't
> really relevant either, but I couldn't let it pass)
But this is the very point I was making, that C++ is a newer and much better
language. So then why choose to limit it with the deficiencies of an older
language?
>>And I disagree that the ability to nest comments is merely a style
>>issue. The choice of where to locate comments certainly is to do
>>with style, but the inability to nest them is a practical issue, and
>>should have been revised many years ago. After all, to allow nested
>>comments would not cause old code to break.
>
> I'm afraid you're mistaken, the following legal C program would quit
> compiling if you changed the rules on nested comments
>
> /****************************************
> Hi there boys and girls, this is kinda silly
> /***************************************/
> #include "stdio.h"
> int main()
> {
> puts("This is a legal C program");
> return 0;
> }
But I was talking of C++ programs. If you were to copy and paste the above code
into a C++ compiler that allowed nested /* */ comments, the compiler would of
course throw up errors, but these would be easy enough to find, and fixing the
problem is purely a cosmetic change, not a change to the code itself.
After all, if you copy and paste a chunk of Fortran or Basic into C++, you get
far more "errors" to fix. (I know, as I do this occasionally!)
[Chunks deleted here.]
>>Yes, nice talking with you. Call me a newbie if you like. My first
>>programming experience started only in about 1968
>
> Geez, you've been doing this only 3 years less than I have......
> apologies "newbie", lol.
But I _still_ don't know it all... Actually, a lot of stuff leaves me just
baffled.
> btw, if you really want to take off on the C "designers"....
> I think the biggest fiasco is that you can include the same file more than
> once
> yes, I know that "guards" puportedly "solve" the problem, but consider
> you can probably count on the thumb of one hand the number of people
> that NEEDED the ability to include a file repeatedly
> and S/HE would have been in the top, oh 1 or so of all the C coders
> in all of history.
> S/HE should have had to do something special to make their "include
> more than once" work instead of everyone else having to put the stupid:
> #ifndef somesymbolthatnobodyelsewilleveruseinmylifetime
> #define somesymbolthatnobodyelsewilleveruseinmylifetime
> ......
> #endif
> in all header files ever since
> only to find out that someone else DID use the symbol and now one of
> you has to change a perfectly good working file due to name collision
I wholeheartedly agree. Some of the most frustrating and difficult problems I
have had were to do with included files. The last time this happened, the
compiler complained that I had altered the definition of a macro. To pin down
the problem, I told it to not include the offending header file in one CPP
file. The compiler then complained that the macro was not defined at all. Heads
you lose, tails you lose...
Modern computers certainly bear no comparison to the ones we used to use. So
it's a shame that C++ carries on the deficiencies of C. I have another example:
Why on earth does strcpy return a pointer to its destination string? The
programmer already knows where the destination string is, and what _would_ be
useful to know would be the location of the terminating zero byte. This would
have been easy to implement, after all strcpy knows where the terminating zero
byte is, because it wrote it just before it finished.
Microsoft give an example of the use of strcpy and strcat:
#include <string.h>
#include <stdio.h>
void main( void ) {
char string[80];
strcpy( string, "Hello world from " );
strcat( string, "strcpy " );
strcat( string, "and " );
strcat( string, "strcat!" );
printf( "String = %s\n", string );
}
I consider this sort of thing to be grossly inefficient, and it gets slower and
slower with each call to strcat which has to scan the whole length of the
contents of the string being built, each time it adds more on. This is 17
characters the first time, 24 the second time, then 28. So it scans through a
total of 69 characters in order to add 18 characters to a string. If I was
writing to a 4K buffer, well ...
If strcpy returned a pointer to the terminating zero byte, we could write the
code as follows:
void main( void ) {
char string[80];
char * p = strcpy( string, "Hello world from " );
p = strcpy( p, "strcpy " );
p = strcpy( p, "and " );
p = strcpy( p, "strcat!" );
printf( "String = %s\n", string );
}
But this will not work, it is against the standard. So I have to write my own
code to do 99% of the work done by strcpy. I use the MFC CString class a lot.
In fact, it seems impossible to avoid using it entirely when programming for
Windows in C++. But it is grossly inefficient if you use it in code like the
above.
My attitude here is a legacy of the days of programming when RAM was very much
at a premium and processors were a thousand times slower. However, I wish some
other programmers had a frugal attitude. Some months ago, I discovered that my
backup software used 700MB of RAM to back up about 350,000 files. That's an
incredible 2K of RAM per file. When the backup finished, I had to wait several
minutes while the computer discarded unwanted virtual memory. Clearly the
programmers took the attitude of "grab as much as you want", without
considering who might be paying the price. I don't use this software any more.
Regards
Shraddhan
[Non-text portions of this message have been removed]
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/EbFolB/TM
--------------------------------------------------------------------~->
>-----------------------------------------~-~>
CHECK THE ARCHIVE BEFORE POSTING!!!! Archive is available at
http://www.eScribe.com/software/C-Paradise/
>------------------------------------------_->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/C-Paradise/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
