From: ········@bayou.uh.edu
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <5l3pku$fho$1@Masala.CC.UH.EDU>
Dean Roddey (·······@ng.netgate.net) wrote:
: ········@bayou.uh.edu wrote:
: > 
: > C++ is totally unsuited for advanced projects.  The only thing C++
: > and C can manage to do semi-decently are trivial projects where
: > being low level is a must.  And when I say trivial, I MEAN
: > trivial.  I say this having coded in C++ and knowing first hand
: > that it is a COUNTER productive tool.  Projects are not completed
: > because of C++, they are completed DESPITE it.  Furthermore C++
: > does not have any advanced features, unless you mean advanced
: > with respect to C which was archaic years ago.  The "features"
: > that C++ has are horrible second-rate imitations of features
: > found in other, better languages for years.
: > 

: Hmmmm... Lets see... just for conversation.

: 1) Lots of large, successful, and powerful products in the world are
: written in C++.

Read my passage above.  I said nothing about big projects not being
done in C++, I said that C++ was inadequate for them.  If you
throw enough resources at a project, you have a very good chance
of finishing it regardless of what language you are using, however
project completion says nothing about cost/time overruns and
other nasties experienced due to an inadequate language.  You
should know this (I'm assuming that you have programming
experience since you are following up to my post).


: 2) You can't write them in C++.

I'd love to know where you got this from.  Again read my
passage.  If you have difficulty understanding it then I'll
explain it to you using simpler language.  Otherwise, I'd
appreciate it if you would refrain from distorting my
statements.


: Is that a statement about C++, or about you? I've heard so many people
: who are just anti-C++ that its become white noise to me. 

If you've heard so many anti-C++ people putting down C++ then maybe
_THAT_ should tell you something.  


: C++ is a
: compromise that is intended to meet in the middle of the ease of use vs.
: performance/power scale. 

C++ is neither easy to use, nor is it powerful.  Compare C++ with a
real language like Common Lisp or Ada, and you will see what
ease of use AND power are like.  

I refuse to consider a language powerful when it has such ridiculous
limitations as the inability to treat user defined data types as
full first class members (look at arrays).  Hey no strings built in?
Gee, we can still crash our system thanks to pointers which are still
a way of life.  Got a declaration designed to protect data?  Typecast
your way around it!  If this is your idea of power and ease, then
you've just lost what little credibility you had.  C++ is a ridiculous
farce, and I have no intention of considering it as anything more
than a nuisance which I must deal with.


[Snip]

: If you don't like it,
: don't use it. Simple enough. But you will be hard pressed to talk
: someone into doing a major projects in Bubba's New Language, no matter
: how nice it is because of the commercial practicalities of the real
: world.

I'm not sure I'd call it a "practicality" in all cases, but you
do of course make a sad but true point.  


: Just for the record though, C++ does have advanced features. However,
: they exist side by side with the ability to get down to the nitty gritty
: details. That makes it complex, but it also makes it widely applicable
: to many different situations, all under one language umbrella. Its hard
: for any other language to touch that.

Advanced with relation to what?  Again I see nothing advanced with
C++ when compared to languages like Scheme or Common Lisp or
Ada.  Templates you say?  Scheme and Common Lisp have full dynamism
which trashes templates any day of the week and Ada has generics.

OOP you say?  Common Lisp has CLOS, which is superior in every
respect to C++'s hack, and is easier to use to boot, not to mention
more transparent. 

Strings?  Oh wait, C++ doesn't have them, or was this one of the
things that the STL patch was supposed to fix?  Common Lisp had
strings for ages.

Where are the advanced features?  From where I'm standing I see
a pathetic joke of a language with layer upon layer of complexity
piled on it in a futile attempt to catch up to numerous other
languages which left it in the dust long ago.

And this is not considering the very laughability of adding
OO to what is in essence a poorly designed high-level assembler
wanna-be.

Remember the classic quote:
	"Adding object orientation to C is like adding air conditioning
	 to a bicycle".

That describes C++ perfectly.



: ---------------------
: Dean Roddey
: The CIDLib Class Libraries
: 'CIDCorp
: ·······@ng.netgate.net
: http://ng.netgate.net/~droddey/

--
Cya,
Ahmed

You're all potential anarchy burgers.
If you want to be free,
Order yourself an anarchy burger,
Hold the government please.
	"Anarchy Burger, Hold the Government" by the Vandals

From: Dean Roddey
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <33767D0B.4FF2@ng.netgate.net>
········@bayou.uh.edu wrote:

> Read my passage above.  I said nothing about big projects not being
> done in C++, I said that C++ was inadequate for them.  If you
> throw enough resources at a project, you have a very good chance
> of finishing it regardless of what language you are using, however
> project completion says nothing about cost/time overruns and
> other nasties experienced due to an inadequate language.  You
> should know this (I'm assuming that you have programming
> experience since you are following up to my post).
> 

Yes I have a lot of experience with it. I personally find it quite
adequate, otherwise I wouldn't waste my time. I find that C++ has the
best, at this time, compromise of performance vs. abstraction for what I
want to do. Maybe 5 years from now I'll be willing to give up some of
the performance for something more abstract, I'll get back to you on
that in 5 years. But, whatever it is will, for better or worse, have to
be something mainstream in which I can make a good living. I sincerely
hope it is not Java.

> : 2) You can't write them in C++.
> 
> I'd love to know where you got this from.  Again read my
> passage.  If you have difficulty understanding it then I'll
> explain it to you using simpler language.  Otherwise, I'd
> appreciate it if you would refrain from distorting my
> statements.
>

That was a bit of sarcasm in reply to your obviously entrenched hatred
of something that just is. Were you sexually abused by a C++ programmer
as a child or something?

> : Is that a statement about C++, or about you? I've heard so many people
> : who are just anti-C++ that its become white noise to me.
> 
> If you've heard so many anti-C++ people putting down C++ then maybe
> _THAT_ should tell you something.
> 

Duh! Go to any language forum and you'll hear pretty much the same
thing. EVERY language has its ups and downs. The reason I've heard so
many about C++ is that I spend time in those forums and deal with people
who seem to have nothing better to do with their lives than abuse it
(and I periodically take time out of my very productive C++ development
efforst to argue with them.)

> : C++ is a
> : compromise that is intended to meet in the middle of the ease of use vs.
> : performance/power scale.
> 
> C++ is neither easy to use, nor is it powerful.  Compare C++ with a
> real language like Common Lisp or Ada, and you will see what
> ease of use AND power are like.
>

I have experience with the Modula and Ada worlds. I don't find them
particularly any better. Somehow people have this feeling that if you
just pretend like pointers don't exist, then everything will be happy. I
don't see it that way. I don't have any experience with Lisp, so I can't
argue with you one way or the other about it. However, it would say that
it is too far outside the mainstream for me to put any serious effort
into, even if it was the greatest thing since sliced bread.

> I refuse to consider a language powerful when it has such ridiculous
> limitations as the inability to treat user defined data types as
> full first class members (look at arrays).  Hey no strings built in?
> Gee, we can still crash our system thanks to pointers which are still
> a way of life.  Got a declaration designed to protect data?  Typecast
> your way around it!  If this is your idea of power and ease, then
> you've just lost what little credibility you had.  C++ is a ridiculous
> farce, and I have no intention of considering it as anything more
> than a nuisance which I must deal with.
>

You are confusing the basic language capabilities with the libraries.
They are not the same. Everyone has their favorite 'its got X built in'
language, but C++ was not designed to be that. In fact, its very lack of
anything built it is why it dominates. It does not tell me how to
architect me system, it lets me architect my system the way I see fit.
It does not have assumptions about the maximum size of a file or the
security system of a host OS, etc... It lets anyone build a class
framework on them that takes advantages of those features fully, unlike
a system which builds things into the language. So C++ can be the force
behind many different systems, all of which represent vastly different
views of the world. That is its power, and that's why you will probably
still be whining 10 years from now.

Yes C++ lets you typecast constness off, because it assumes you are an
adult with a brain and you are getting paid to understand why you did
it. The compiler will warn you if you do this, so its not rocket science
to deal with it (and it provides a lot of flexibility when you need it,
though you seldom do.)

BTW, I don't build my world around my credibility with you. Sorry about
that.

> 
> : Just for the record though, C++ does have advanced features. However,
> : they exist side by side with the ability to get down to the nitty gritty
> : details. That makes it complex, but it also makes it widely applicable
> : to many different situations, all under one language umbrella. Its hard
> : for any other language to touch that.
> 
> Advanced with relation to what?  Again I see nothing advanced with
> C++ when compared to languages like Scheme or Common Lisp or
> Ada.  Templates you say?  Scheme and Common Lisp have full dynamism
> which trashes templates any day of the week and Ada has generics.
>

C++ templates provide significant optimization and compile tiem safety
gains. This avoids the overhead involved in more indirect means of
acheive the same thing. Here again, this probably has a lot to do with
why C++ dominiates, because it takes a practical approach that
appreciates the limitations of even today's CPUs to handle the load
placed on them by significantly sized systems. If you don't like them,
you don't have to use them. Or better, why don't you swoon us with your
technical description of why List and Ada's mechanisms are better and
how they compare in performance to C++ template generated code?

> OOP you say?  Common Lisp has CLOS, which is superior in every
> respect to C++'s hack, and is easier to use to boot, not to mention
> more transparent.
>

Here again I cannot argue with you because I don't know Lisp. However, I
can only say that if it was that great why don't you write a better
office suite than Office 97 in Lisp and put MS out of business? We'd all
like to see that.

> Strings?  Oh wait, C++ doesn't have them, or was this one of the
> things that the STL patch was supposed to fix?  Common Lisp had
> strings for ages.
>

C++ still does not HAVE strings, nor does it want them. Strings are
things that come along with a class framework, and which are part of a
much larger architecture than the language could ever provide. The
problem with having such things built in is that they then become
limitations on the developer of frameworks (because they probably don't
have the common semantics or capabilities that the framework designer
builds into his/her other classes.) Once again, you are arguing against
something that a C++ person considers a PLUS! If I buy framework X, then
I want the strings in it to be consistent in style and architecture to
the overall scheme of framework X, not something sticking out like a
sore thumb that the framework had to hack around.

> Where are the advanced features?  From where I'm standing I see
> a pathetic joke of a language with layer upon layer of complexity
> piled on it in a futile attempt to catch up to numerous other
> languages which left it in the dust long ago.
>

It doesn't do much good to mention them because you already have
convinced yourself that they are stupid but... multiple inheritance,
templates, namespaces, inlining, mutable members, typesafe collections
via templates, polymorphism, RTTI, strong const usage, and operator
overloading come to mind.

The reason it looks that way is because you are standing in a big pool
of self generated hatred for a language that seems to dominate despite
your feelings about it.

> And this is not considering the very laughability of adding
> OO to what is in essence a poorly designed high-level assembler
> wanna-be.
> 

That is exactly why C++ runs rough shod over your beloved languages.
That is why it covers a large range of applications under one roof. You
are damning it for its strengths.

-- 
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
·······@ng.netgate.net
http://ng.netgate.net/~droddey/
From: Daniel Wang
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <r8t911lfe4y.fsf@atomic.CS.Princeton.EDU>
>>>>> "Dean" == Dean Roddey <·······@ng.netgate.net> writes:

    Dean> ········@bayou.uh.edu wrote:
    >> Read my passage above.  I said nothing about big projects not being
    >> done in C++, I said that C++ was inadequate for them.  If you throw
    >> enough resources at a project, you have a very good chance of
    >> finishing it regardless of what language you are using, however
    >> project completion says nothing about cost/time overruns and other
    >> nasties experienced due to an inadequate language.  You should know
    >> this (I'm assuming that you have programming experience since you are
    >> following up to my post).
    >> 

    Dean> Yes I have a lot of experience with it. I personally find it quite
    Dean> adequate, otherwise I wouldn't waste my time. I find that C++ has
    Dean> the best, at this time, compromise of performance vs. abstraction
    Dean> for what I want to do. Maybe 5 years from now I'll be willing to
    Dean> give up some of the performance for something more abstract, I'll
    Dean> get back to you on that in 5 years. But, whatever it is will, for
    Dean> better or worse, have to be something mainstream in which I can
    Dean> make a good living. I sincerely hope it is not Java.

	{stuff deleted} 

These two comments illustrate an important point that people seem to be
missing. A given language is always a compromise between competing design
constraints. C++ is probably the only language that makes the design choices
it did in order to get a certain mix of abstraction/performance. This is C++
selling point. 

The problem occurs when C++ gets over sold as a solution to problems that
require more abstraction than performance. There are a lot better langauges
that provide better abstractions than C++. There are few other languages
that provide the same mix as C++ and in those application domains C++ is
a resonable tool. 

If the compiler and programming researcher do their job in a few years we
should have langauges/technology that give you the same performance as C++
without the abstraction tradeoffs*. Research will push and expand the design
space so people can build better tools, and force everyone to reconsider the
trade offs in the languages of their choice that were made when the design
space was different.

C++ sucks for X and C++ is great for Y aren't contradictory claims if X and
Y are different tasks. Now if everyone would just be clear about what X and
Y there probably be less flamage. I guess of course then the arguments will
just devolve into whether most tasks are like X or Y, so we can figure out
C++'s suckfullness on average.

*When I say performance I mean relative performance where the hardware is
fixed. The hardware folks are already changing the design space of absolute
performance. If you care about absolute performance one can make a case for
Java replacing a lot of niches that C++ is currently filling.
From: Darin Johnson
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <slrn5nerin.qu6.darin@connectnet1.connectnet.com>
In article <···············@atomic.CS.Princeton.EDU>, Daniel Wang wrote:
>These two comments illustrate an important point that people seem to be
>missing. A given language is always a compromise between competing design
>constraints. C++ is probably the only language that makes the design choices
>it did in order to get a certain mix of abstraction/performance. This is C++
>selling point.

I strongly agree here.  Much of my frustration is with C++ zealots
that don't realize there were design choices and tradeoffs, and
that the C++ way is the only correct way.  And ironically, this "C++
is best" attitude survives large changes in the language; the older
attitude of "generics and multiple inheritance just aren't important"
becomes "C++ has generics and MI, so those are good things to have".

>The problem occurs when C++ gets over sold as a solution to problems that
>require more abstraction than performance. There are a lot better langauges
>that provide better abstractions than C++. There are few other languages
>that provide the same mix as C++ and in those application domains C++ is
>a resonable tool.

Again, agreed.  Much of the frustration I feel here is from the "one
language" school.  There's a very common attitude out there that one
should need to only know one language; and it comes from schools
(ie, curriculum that uses one language/os throughout) and continues
into industry (only one compiler licensed for use on all computers).
This attitude leads to the wacky oft-heard observation of "that may
be a nice language, but how's it going to get you a job"...

>C++ sucks for X and C++ is great for Y aren't contradictory claims if X and
>Y are different tasks. Now if everyone would just be clear about what X and
>Y there probably be less flamage.

The problem is that this requires an objective viewing of the language.
But there's so much emotional baggage attached, that any "C++ is not
optimal for this one tiny subset of tasks" is treated as an insult.

-- 
Darin Johnson
·····@usa.net.delete_me
From: Dean Roddey
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <33793D7E.6B54@ng.netgate.net>
Darin Johnson wrote:
 
> >The problem occurs when C++ gets over sold as a solution to problems that
> >require more abstraction than performance. There are a lot better langauges
> >that provide better abstractions than C++. There are few other languages
> >that provide the same mix as C++ and in those application domains C++ is
> >a resonable tool.
> 
> Again, agreed.  Much of the frustration I feel here is from the "one
> language" school.  There's a very common attitude out there that one
> should need to only know one language; and it comes from schools
> (ie, curriculum that uses one language/os throughout) and continues
> into industry (only one compiler licensed for use on all computers).
> This attitude leads to the wacky oft-heard observation of "that may
> be a nice language, but how's it going to get you a job"...
> 

I hate to break it to you guys, but Java gets that medal these days. C++
is seen as some backwater. Java is the language which is being hailed as
the answer to all mankind's development needs, regardless of what those
needs are. Follow the hype and leave poor old decrepit C++ to those of
us who are doing quite well with it :-)

-----------------------
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
·······@ng.netgate.net
http://ng.netgate.net/~droddey/

"Software engineers are, in many ways, similar to normal people"
From: Thant Tessman
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <3379D8B3.41C6@nospam.acm.org>
Dean Roddey wrote:

> I hate to break it to you guys, but Java gets that medal these 
> days. C++ is seen as some backwater. Java is the language which 
> is being hailed as the answer to all mankind's development needs, 
> regardless of what those needs are. Follow the hype and leave poor 
> old decrepit C++ to those of us who are doing quite well with it :-)

Java is only successful because it was designed not to scare off
C++ programmers.  It's deja vu all over again.

-thant
From: Chris Bitmead uid(x22068)
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <BITMEADC.97May13162019@Alcatel.com.au>
>>Hey no strings built in?
>> Gee, we can still crash our system thanks to pointers which are still
>> a way of life.

In article <·············@ng.netgate.net> Dean Roddey <·······@ng.netgate.net> writes:

>You are confusing the basic language capabilities with the libraries.
>They are not the same. Everyone has their favorite 'its got X built in'
>language, but C++ was not designed to be that. In fact, its very lack of
>anything built it is why it dominates. 

Actually, there is something fundamentally broken about C++ strings
(amoungst other things :-).

You can't put an arbitrary set of characters in between " and " and
expect it to work.

e.g.

String foo("abc\0def");

will produce a string of 3 characters instead of the correct 7
characters. It doesn't matter which "String" class you use. This is an
example of the core language being broken.
From: Alaric B. Williams
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <3378b8c9.5393215@news.demon.co.uk>
On Tue, 13 May 1997 12:34:58 GMT, ···@research.att.com (Andrew Koenig)
wrote:

>	string foo("abc\0def", 7);
>
>or, if you don't want to have to count characters by hand:
>
>	char foo_init[] = "abc\0def";
>	string foo(foo_init, sizeof(foo_init)-1);
>
>where the `-1' compensates for the second \0 that C compatibility requires.

Nice <retch> - why didn't they create a new basic language-level
string, rather than try to reuse the old kludge? Perhaps using
double ' or something?

string foo(''abc\0def'');

ABW
            ##### UNIX IS LAME - EVEN LINUX! ##### 

(My previous nice signature file was just vapourised by
a Linux kernel crash that ate almost all of my main
partition, so we will have to make do with a boring and
slightly bitter .sig)

Alaric B. Williams, ······@abwillms.demon.co.uk

FUN: http://www.abwillms.demon.co.uk/alaric/wfewad.htm
INTERESTING: http://www.abwillms.demon.co.uk/os/
OTHER: http://www.abwillms.demon.co.uk/
From: Fergus Henderson
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <5lei63$6g7@mulga.cs.mu.OZ.AU>
>···@research.att.com (Andrew Koenig) wrote:
>
>>	string foo("abc\0def", 7);

I think that this problem could possibly be solved with a constructor
template, e.g.

	class string {
	public:
		template <int i> string(const char (&array_ref) [i]);
		...
	};

However, the C++ compilers I have available to me don't support template
member functions yet...

--
Fergus Henderson <···@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger ···@128.250.37.3         |     -- the last words of T. S. Garp.
From: Thant Tessman
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <337B3B64.41C6@nospam.acm.org>
Fergus Henderson wrote:
> 
> >···@research.att.com (Andrew Koenig) wrote:
> >
> >>      string foo("abc\0def", 7);
> 
> I think that this problem could possibly be solved with a constructor
> template, e.g.
> 
>         class string {
>         public:
>                 template <int i> string(const char (&array_ref) [i]);
>                 ...
>         };
> 
> However, the C++ compilers I have available to me don't support template
> member functions yet...


Very clever!  Only I tried it and it doesn't work, although I don't know
why it shouldn't.  I also tried "char array[i]" but that didn't work
either.  

(My compiler supports template member functions, but only if you use 
the "-experimental" flag, which unfortunately breaks virtual base 
classes which unfortunately we use in our app.)

Anyways, here's what I tried:


#include <iostream.h>

struct string {

  template <int i> string(const char (&array_ref)[i]) {

    _length = i-1;  // this may or may not be what people want
    _string = new char[_length];
    for (int j=0; j<i; ++j) {_string[j] = array_ref[j];}
  }
  ~string() {delete _string;}

  friend ostream& operator<<(ostream& out, const string& s) {
    for (int i=0; i<s._length; ++i) {
      if (s._string[i]=='\0') out << "NULL";
      else out << s._string[i];
    }
    return out;
  }

  int _length;
  char* _string;
};

  
main() {

  string s("hi\0there");

  cout << s << endl;
}
From: Fergus Henderson
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <5li3kv$i3p@mulga.cs.mu.OZ.AU>
Thant Tessman <·····@nospam.acm.org> writes:

>Fergus Henderson wrote:
>> 
>> >···@research.att.com (Andrew Koenig) wrote:
>> >
>> >>      string foo("abc\0def", 7);
>> 
>> I think that this problem could possibly be solved with a constructor
>> template, e.g.
>> 
>>         class string {
>>         public:
>>                 template <int i> string(const char (&array_ref) [i]);
>>                 ...
>>         };
>> 
>> However, the C++ compilers I have available to me don't support template
>> member functions yet...
>
>Very clever!  Only I tried it and it doesn't work, although I don't know
>why it shouldn't.  I also tried "char array[i]" but that didn't work
>either.  

I think it should work, probably your compiler is just broken.
(What error does it report?  Try without the const.)

--
Fergus Henderson <···@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger ···@128.250.37.3         |     -- the last words of T. S. Garp.
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <5lvh92$kb5@web.nmti.com>
In article <·············@nospam.acm.org>,
Thant Tessman  <·····@nospam.acm.org> wrote:
> (My compiler supports template member functions, but only if you use 
> the "-experimental" flag, which unfortunately breaks virtual base 
> classes which unfortunately we use in our app.)

This sort of thing is one of many reasons I have resisted getting sucked
into C++. I'll stick with C, thank you very much, until something that's
REALLY better and widely used comes along.
-- 
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-'                                Kulanu Kibo.
Hail Eris! All Hail Discordia!                                 Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO!                            Wir sind alle Kibo.
From: Chris Bitmead uid(x22068)
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <BITMEADC.97May14122904@Alcatel.com.au>
In article <··········@research.att.com> ···@research.att.com (Andrew Koenig) writes:

>In article <······················@Alcatel.com.au> ·············@Alcatel.com.au writes:
>
>> Actually, there is something fundamentally broken about C++ strings
>> (amoungst other things :-).
>
>> You can't put an arbitrary set of characters in between " and " and
>> expect it to work.
>
>> e.g.
>
>> String foo("abc\0def");
>
>> will produce a string of 3 characters instead of the correct 7
>> characters. It doesn't matter which "String" class you use. This is an
>> example of the core language being broken.
>
>It is an example of a minor inconvenience that is there for C compatibility.

This could have been fixed without touching C compatibility. Just put
a size integer before the actual string. Then make literal strings a
new type, (literal * perhaps). Then overloaded functions will choose
the literal version which will look for the size attribute. And have
literal convertable to char * just like short converts to int, but not
vice-versa.

>There is no particular difficulty in writing a string library in C++ that
>can handle arbitrary characters, and in fact the standard C++ library will
>have just such a string class.  However, C++ did not change the C syntax
>for string literals.  That means that if you want to use a literal to initialize
>a string, and you want that literal to contain any null characters, you
>have to give a length explicitly so that the library won't use the first
>null character that it finds as a sentinel.  In other words:
>
>	string foo("abc\0def", 7);
>
>or, if you don't want to have to count characters by hand:
>
>	char foo_init[] = "abc\0def";
>	string foo(foo_init, sizeof(foo_init)-1);
>
>where the `-1' compensates for the second \0 that C compatibility requires.

Yeah, and how many core dumps has mistakes doing this caused over
time? I'll bet the lost productivity from that old chestnut is
probably running in the hundreds of millions of dollars already.
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <5lvh4o$k43@web.nmti.com>
In article <··········@research.att.com>,
Andrew Koenig <···@research.att.com> wrote:
> or, if you don't want to have to count characters by hand:

> 	char foo_init[] = "abc\0def";
> 	string foo(foo_init, sizeof(foo_init)-1);

> where the `-1' compensates for the second \0 that C compatibility requires.

#define STRING(s) init_static_string(s,sizeof s)
-- 
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-'                                Kulanu Kibo.
Hail Eris! All Hail Discordia!                                 Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO!                            Wir sind alle Kibo.
From: Alaric B. Williams
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <3378aaf0.1848708@news.demon.co.uk>
On Sun, 11 May 1997 19:14:35 -0700, Dean Roddey
<·······@ng.netgate.net> wrote:

>Yes I have a lot of experience with it. I personally find it quite
>adequate, otherwise I wouldn't waste my time. I find that C++ has the
>best, at this time, compromise of performance vs. abstraction for what I
>want to do.

What other languages have you studied, then? COBOL and FORTRAN,
perhaps?

> Maybe 5 years from now I'll be willing to give up some of
>the performance for something more abstract,

Why?

> I'll get back to you on
>that in 5 years. But, whatever it is will, for better or worse, have to
>be something mainstream in which I can make a good living. I sincerely
>hope it is not Java.

Eurgh! Don't /say/ the J word!

>> I'd love to know where you got this from.  Again read my
>> passage.  If you have difficulty understanding it then I'll
>> explain it to you using simpler language.  Otherwise, I'd
>> appreciate it if you would refrain from distorting my
>> statements.

>That was a bit of sarcasm in reply to your obviously entrenched hatred
>of something that just is. Were you sexually abused by a C++ programmer
>as a child or something?

:-)

>> If you've heard so many anti-C++ people putting down C++ then maybe
>> _THAT_ should tell you something.
>
>Duh! Go to any language forum and you'll hear pretty much the same
>thing. EVERY language has its ups and downs. The reason I've heard so
>many about C++ is that I spend time in those forums and deal with people
>who seem to have nothing better to do with their lives than abuse it
>(and I periodically take time out of my very productive C++ development
>efforst to argue with them.)

How about those people who have nothing better to do with their lives
than abuse, say, Eiffel?

>> C++ is neither easy to use, nor is it powerful.  Compare C++ with a
>> real language like Common Lisp or Ada, and you will see what
>> ease of use AND power are like.
>>
>
>I have experience with the Modula and Ada worlds. I don't find them
>particularly any better. Somehow people have this feeling that if you
>just pretend like pointers don't exist, then everything will be happy.

/Who/ thinks that?

> I
>don't see it that way. I don't have any experience with Lisp, so I can't
>argue with you one way or the other about it. However, it would say that
>it is too far outside the mainstream for me to put any serious effort
>into, even if it was the greatest thing since sliced bread.

Alas, mainstreamness instead of goodness as a language chooser -
that's not so much the fault of any one language, as the entire
computer industry :-(

>> I refuse to consider a language powerful when it has such ridiculous
>> limitations as the inability to treat user defined data types as
>> full first class members (look at arrays).  Hey no strings built in?
>> Gee, we can still crash our system thanks to pointers which are still
>> a way of life.  Got a declaration designed to protect data?  Typecast
>> your way around it!  If this is your idea of power and ease, then
>> you've just lost what little credibility you had.  C++ is a ridiculous
>> farce, and I have no intention of considering it as anything more
>> than a nuisance which I must deal with.

>You are confusing the basic language capabilities with the libraries.
>They are not the same. Everyone has their favorite 'its got X built in'
>language, but C++ was not designed to be that. In fact, its very lack of
>anything built it is why it dominates.

It has WAY to much built in! It's a bloated language! 

> It does not tell me how to
>architect me system, it lets me architect my system the way I see fit.

Interesting theory.

>It does not have assumptions about the maximum size of a file or the
>security system of a host OS, etc...

Really? I didn't realise C ints were extensible. I thought they had
fixed sizes. I guess GCC is just a poor implementation, then, that
imposes this 4Gig limit unless I go to long long ints manually. But
few files are that big, so I have to waste space. Hmmm. 

> It lets anyone build a class
>framework on them that takes advantages of those features fully, unlike
>a system which builds things into the language.

Really? I guess you lied that you've used it before then. Last time I
looked (yesterday pm), C++ had templates, OOP, various amusing data
types (what, exactly, is an int?), a whole host of control structures
(if, while, for, do, select), a dirty hack of a macro system, and a
set of allocation strategies (static, global, local-static,
stack-based, and heap-allocated).

If you want a core-based language, WHY are you using C++?

Take Scheme, for example.

Most basic operations are:

(if <condition> <do-this> <else-do-this>)
(lambda (<args>) <body>)
(<closure> <args>...)

And the data types: symbols, various kinds of numbers, strings,
arrays, closures, and pairs. Probably a couple of others.

In terms of that, we can define OOP, control structures, macros...

> So C++ can be the force
>behind many different systems, all of which represent vastly different
>views of the world. That is its power, and that's why you will probably
>still be whining 10 years from now.

Yes - because C++ makes such a POOR job of doing what it is used for.

>Yes C++ lets you typecast constness off, because it assumes you are an
>adult with a brain and you are getting paid to understand why you did
>it.

Right, and your point is?

> The compiler will warn you if you do this, so its not rocket science
>to deal with it (and it provides a lot of flexibility when you need it,
>though you seldom do.)

Yes. Many languages will allow something like this, depending; and the
best languages have no need of this strange operation, since they
rarely use variables.

>BTW, I don't build my world around my credibility with you. Sorry about
>that.

Shame, isn't it? Ahmed could teach you a few things, it seems :-(

>> Advanced with relation to what?  Again I see nothing advanced with
>> C++ when compared to languages like Scheme or Common Lisp or
>> Ada.  Templates you say?  Scheme and Common Lisp have full dynamism
>> which trashes templates any day of the week and Ada has generics.
>
>C++ templates provide significant optimization and compile tiem safety
>gains. This avoids the overhead involved in more indirect means of
>acheive the same thing.

ROFL!

> Here again, this probably has a lot to do with
>why C++ dominiates, because it takes a practical approach that
>appreciates the limitations of even today's CPUs to handle the load
>placed on them by significantly sized systems.

Are you for REAL?

> If you don't like them,
>you don't have to use them.

Thank GOD!

> Or better, why don't you swoon us with your
>technical description of why List and Ada's mechanisms are better and
>how they compare in performance to C++ template generated code?

Interesting. CMU-CL, a Common Lisp implementation, produces benchmark
code that runs faster than the equivelant C compiled by gcc on the
same platform, I hear. And a lot less effort went into CMU-CL than
gcc, I think you'll agree?

>> OOP you say?  Common Lisp has CLOS, which is superior in every
>> respect to C++'s hack, and is easier to use to boot, not to mention
>> more transparent.
>>
>
>Here again I cannot argue with you because I don't know Lisp. However, I
>can only say that if it was that great why don't you write a better
>office suite than Office 97 in Lisp and put MS out of business? We'd all
>like to see that.

Say, why don't you build a starship and collect some soil samples from
Mars?

>> Strings?  Oh wait, C++ doesn't have them, or was this one of the
>> things that the STL patch was supposed to fix?  Common Lisp had
>> strings for ages.
>>

>C++ still does not HAVE strings, nor does it want them.

Amusing, isn't it?

> Strings are
>things that come along with a class framework, and which are part of a
>much larger architecture than the language could ever provide.

I hear the STL implementation is almost workable, although I've never
had the chance to play with it.

> The
>problem with having such things built in is that they then become
>limitations on the developer of frameworks (because they probably don't
>have the common semantics or capabilities that the framework designer
>builds into his/her other classes.)

Would you hire such an incompetent developer, or use such a poor
string type, or both?

> Once again, you are arguing against
>something that a C++ person considers a PLUS!

Don't worry, the condition is curable.

> If I buy framework X, then
>I want the strings in it to be consistent in style and architecture to
>the overall scheme of framework X, not something sticking out like a
>sore thumb that the framework had to hack around.

Oh come ON! You really think that people should be locked into their
"frameworks" like this? Like Microsoft's marketing strategy: you buy
Microsoft, you kiss compatability goodbye. You use a C++ "framework",
it dictates the string class you should use. And you say that's GOOD?

>> Where are the advanced features?  From where I'm standing I see
>> a pathetic joke of a language with layer upon layer of complexity
>> piled on it in a futile attempt to catch up to numerous other
>> languages which left it in the dust long ago.

>It doesn't do much good to mention them because you already have
>convinced yourself that they are stupid but... multiple inheritance,

Advanced? How LONG have they been around now?

>templates,

I guess they're a doable hack in the absence of a real type system.

> namespaces,

!

> inlining,

That's not a language thing, it's an implementation thing. Oh, sorry,
I almost forgot - C++ isn't good enough to let the compiler do it's
own inling. It has to have it's hand held. Don't you realise that good
languages inline WITHOUT HAVING TO BE HELPED? Even gcc seems capable
of automatically inlining, come to think of it... so why have the
inline keyword, exactly? 

> mutable members,

That sounds painful :-)

> typesafe collections
>via templates,

"Typesafe" and "C" don't usually go in a positive sentence like that.

> polymorphism,

Really? I only thought there was limited polymorphism on the class
hierachy level. Feel free to state a counterexample.

> RTTI,

Which, may I add, first appeared in the early seventies or thereabouts
- when was Lisp originally created? I forget.

> strong const usage,

You call that strong? You should try Eiffel.

> and operator
>overloading come to mind.

"Operator overloading" is pretty poor compared to a generic function,
don't you agree?

>The reason it looks that way is because you are standing in a big pool
>of self generated hatred for a language that seems to dominate despite
>your feelings about it.

I can't speak for Ahmed, but I don't hate C or C++. C is OK as a
portable assembler, and it has some good support out there in the form
of compilers and libraries. I can't really find a use for C++,
although I am forced to use it since it's all I have. Anyway, what I
do dislike is the way people get religious about languages (not just C
and C++; I have seen FORTH religion and Eiffel religion that come to
mind, as well, and have similar misgivings; also, there is OS
religion, such as UNIX adorers - especially Linux fans!), without
actually studying things like functional programming. I mean, I hear
people say things like "Oh, C is good because it's fast". C is HARD to
implement efficiently! A quick and dirty C compiler has acceptable
performance, but to get decent performance, you need to go through a
lot of contortions in the compiler. Look at gcc! It's one of the
fastest C++ compilers, and it's HUGE.

Now, languages like Scheme, if implemented naively, are very slow.
However, it takes relatively little effort to get vast speed increases
compared to C++.

>> And this is not considering the very laughability of adding
>> OO to what is in essence a poorly designed high-level assembler
>> wanna-be.

>That is exactly why C++ runs rough shod over your beloved languages.

Not true!

>That is why it covers a large range of applications under one roof. You
>are damning it for its strengths.

Jack of some trades, master of none.

OTOH, a well designed language can be master of some, jack of a few
others.


ABW
            ##### UNIX IS LAME - EVEN LINUX! ##### 

(My previous nice signature file was just vapourised by
a Linux kernel crash that ate almost all of my main
partition, so we will have to make do with a boring and
slightly bitter .sig)

Alaric B. Williams, ······@abwillms.demon.co.uk

FUN: http://www.abwillms.demon.co.uk/alaric/wfewad.htm
INTERESTING: http://www.abwillms.demon.co.uk/os/
OTHER: http://www.abwillms.demon.co.uk/
From: Dean Roddey
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <337A8AE1.63DF@ng.netgate.net>
Alaric B. Williams wrote:
> 
> On Sun, 11 May 1997 19:14:35 -0700, Dean Roddey
> <·······@ng.netgate.net> wrote:
> 
> >Yes I have a lot of experience with it. I personally find it quite
> >adequate, otherwise I wouldn't waste my time. I find that C++ has the
> >best, at this time, compromise of performance vs. abstraction for what I
> >want to do.
> 
> What other languages have you studied, then? COBOL and FORTRAN,
> perhaps?
> 

Once again, I appreciate your deep insights, but I don't have time for
another pissing contest. Nothing I ever say will convince you of
anything, so I just don't have the time to waste. Sorry.

-- 
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
·······@ng.netgate.net
http://ng.netgate.net/~droddey/

"Software engineers are, in many ways, similar to normal people"
From: Alaric B. Williams
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <337b7c79.12989668@news.demon.co.uk>
On Wed, 14 May 1997 21:02:41 -0700, Dean Roddey
<·······@ng.netgate.net> wrote:

>Alaric B. Williams wrote:

>Once again, I appreciate your deep insights, but I don't have time for
>another pissing contest. Nothing I ever say will convince you of
>anything, so I just don't have the time to waste. Sorry.

Hey, that's OK, I wasn't actually hoping for a flamewar anyway! I was
in a somewhat bad mood with people extolling anti-scientific arguments
like yours at the time.

All my points still stand, though; the anger only affected my wording!

>Dean Roddey

ABW
--

Limited Warranty: Macrosoft Corporation cannot accept
any responsobility for geological, ecological, biological, sociological,
political, or nuclear disasters caused by Windows for Early Warning
and Defence. The software is supplied as is, with no express or
implied warranty, and with no guarantee of fitness of purpose,
or sufficient reliability to be placed in a situation to threaten
millions, if not billions, of innocent lives.

FUN: http://www.abwillms.demon.co.uk/alaric/wfewad.htm
INTERESTING: http://www.abwillms.demon.co.uk/os/
OTHER: http://www.abwillms.demon.co.uk/
From: Matt Kennel (Remove 'nospam' to reply)
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <slrn5nih07.ag0.kennel@lyapunov.ucsd.edu>
On Sun, 11 May 1997 19:14:35 -0700, Dean Roddey <·······@ng.netgate.net> wrote:
:
:It doesn't do much good to mention them because you already have
:convinced yourself that they are stupid but... multiple inheritance,
:templates, namespaces, inlining, mutable members, typesafe collections
:via templates, polymorphism, RTTI, strong const usage, and operator
:overloading come to mind.

If that's why you like C++, you really must try Eiffel. 

:Dean Roddey
:The CIDLib Class Libraries

-- 
Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
Don't blame me, I voted for Emperor Mollari. 
From: Peter da Silva
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <5lvgiq$jk8@web.nmti.com>
In article <···············@atomic.cs.princeton.edu>,
Daniel Wang <·······@atomic.CS.Princeton.EDU> wrote:
> These two comments illustrate an important point that people seem to be
> missing. A given language is always a compromise between competing design
> constraints. C++ is probably the only language that makes the design choices
> it did in order to get a certain mix of abstraction/performance. This is C++
> selling point. 

I don't see how you can possibly argue that C++ is the way it is to get a
certain mix of abstraction and performance. C++ is the way it is because
it had to remain compatible, to some extent, with C.

And I don't see how the problems with C++ are due to a lack of abstraction.

Languages like Modula are no more "abstract" than C. They support all the
same operations on all the same data types. You can write compilers in
them that generate just as fast code as a C compiler.

The problem with C++ is that C is not a good language for the sorts of
things people use C++ for, and C++ incorporates most of the problems of C.

What makes C++ a good language is that C was a good language for the compiler
technology of the '70s and early '80s. 

The language itself is relatively easy to implement with all the basic
functionality, and the functionality the language provides is good enough to
wrote interesting programs in. This wasn't true of Lisp, Pascal, Forth, Ada,
Modula, and so on. They all suffered in various ways... either they were too
hard to write cheap compilers for, or the defacto language description was
not complete enough to write useful software without developing extensions.

My favorite language of the period, SmallTalk, died on the vine because Xerox
thought they could make a lot of money from it.

But today, there's no reason a good Smalltalk compiler couldn't be built that
produced every bit as good code as C. There's good effectively-free Modula
compilers. We don't need "compiler and programming researchers" to bridge
the gap, what we need are plugins. Libraries and tools that provide the
same functionality as all the C and C++ ones that are the REAL reason C++
is the unchallenged king of the road.
-- 
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-'                                Kulanu Kibo.
Hail Eris! All Hail Discordia!                                 Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO!                            Wir sind alle Kibo.
From: Dean Roddey
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date: 
Message-ID: <33767F25.E6F@ng.netgate.net>
········@bayou.uh.edu wrote:
> 
> Dean Roddey (·······@ng.netgate.net) wrote:
> : ········@bayou.uh.edu wrote:

> Strings?  Oh wait, C++ doesn't have them, or was this one of the
> things that the STL patch was supposed to fix?  Common Lisp had
> strings for ages.
> 

Oh, and I don't think I made myself clear enough on this point. STL is
'just a library' just like anyone else's. The reason that C++ is so
popular is that anyone can create their own vision of such a system. STL
just happens to be one that picked to ship with the language because its
small and simple and serves for many day to day applications. However
C++, unlike most other languages, does not define a world it just
defines a language with which anyone can build a world. Therefore, I can
go out and buy a C++ framework that represents a world that I feel
comfortable with, or I can build one, which I do. That represents a lot
of freedom to many people. Languages that come with the kitchen sink
built in will never be able to move as fast because they will build
assumptions about system capabilties into their attached world view.
Those assumptions will be out of date before the first large project is
built most likely. So the world view either changes (destroying the
supposed portability and platform abstraction claimed by many such
languages), or the applications written in that langauge don't take
advantage of the new capabilities of the newer operating systems. That
will keep a language out of the running more than anything else, because
having access to the newest, hippest operating system stuff is what
drives the industry.

For instance, if the language contains file I/O operations and those are
defined with a 32 bit offset value for file position, it cannot take
advantage of a 64 bit file system. If a language defines types for any
kind of system resource but does not have a means to apply security
access to them programatically, then it cannot take advantage of
something like NT's security system. Or, if it does, it does so by
having an inconsistent implementation on each platform. The language
obviously will usually not have a GUI interface API, therefore it will
hav to interface to the host OS' GUI. This will involve dealing with raw
pointers and arbitrary structures blah blah blah. C++ is well positioned
to deal with these things directly, with minimal overhead and gotchas.

------------------------
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
·······@ng.netgate.net
http://ng.netgate.net/~droddey/