At 15:13 2005-10-16, Shraddhan wrote:
>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?
if you read "The Design & Evolution of C++" Bjarne says that some
stuff just had to be left in because of "the old farts" who would
have just refused to even TRY any language that didn't "put a lot of
your least favorite things here". He wasn't even going to add the
keyword class, except that _everyone_ knew that if you were going to
support OO the language _had_ to have the keyword class (ignoring
completely that struct works just fine).
> >>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!)
oh, I'm sorry I thought you said it wouldn't break any existing code.
>[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.
you and me both... have you looked at any of the "meta templage
programming" stuff floating around?
> > 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
>deleted, I'm sure everyone understands the point]
>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?
I don't really consider strcpy (or any of the strxxx) functions to be
part of C++ (other than the standard C library was included just
'cuz). std::string generally whomps any use of char* and char array.
> 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.
ewwww, CString? std::string whomps it too, IMO
>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.
yeah, there's a lot of junk out there these days.
>Regards
>
>Shraddhan
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
> >-----------------------------------------~-~>
>CHECK THE ARCHIVE BEFORE POSTING!!!! Archive is available at
>http://www.eScribe.com/software/C-Paradise/
>
> >------------------------------------------_->
>
>
>
>Yahoo! Groups Links
>
>
>
>
Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/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/
