D

[Hans Aberg]

Is it not time to make a new language D drawing on the experiences from C
and C++?

Specifically, such a language should zip out the parts of C that are
problematic and caused ambiguities and problems in C++. For example, the
many implicit type conversions and problems in the C syntax which are
difficult handle in a C++ high level language style. (There is an example
in the Bison manual in the GLR parser section of a C++ language
ambiguity).

Then one would first get a cleaner C core, not having to worry about
upwards compatibility so much anymore. Further this core can be designed
with respect to more modern CPU structures in mind.

The experiences from C++ will tell mainly how to implement statically
computable user definable structures, including some generic programming
then.

To this, one needs a level above the C++ level, handling parallelism,
distributed programming and better handling of dynamic objects (so it
becomes easier to create Java style polymorphic classes), including ones
choice of GC if needed.

On the level below the C level, one can think of a "portable assembler
level" like C-- and/or a byte code level, which can be used as an
intermediate to an assembler level. This level should also provide hooks
to "universal binary standards" like CORBA and Unicode, which C and C++
carefully avoids due to their history.

See you in comp.std.d. :-)

Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <re***********@member.ams.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

[Victor Bazarov]

"Hans Aberg" <re***********@matematik.su.se> wrote...

Is it not time to make a new language D drawing on the experiences from C
and C++?

There is 'D' already. Search for it on the Web.

Victor

[Ioannis Vranos]

"Hans Aberg" <re***********@matematik.su.se> wrote in message
news:re****************************@du130-86.ppp.su-anst.tninet.se...

Is it not time to make a new language D drawing on the experiences from C
and C++?
There have been many language attempts named "D".


Specifically, such a language should zip out the parts of C that are
problematic and caused ambiguities and problems in C++. For example, the
many implicit type conversions and problems in the C syntax which are
difficult handle in a C++ high level language style. (There is an example
in the Bison manual in the GLR parser section of a C++ language
ambiguity).

Then one would first get a cleaner C core, not having to worry about
upwards compatibility so much anymore. Further this core can be designed
with respect to more modern CPU structures in mind.

The experiences from C++ will tell mainly how to implement statically
computable user definable structures, including some generic programming
then.

To this, one needs a level above the C++ level, handling parallelism,
distributed programming and better handling of dynamic objects (so it
becomes easier to create Java style polymorphic classes), including ones
choice of GC if needed.

On the level below the C level, one can think of a "portable assembler
level" like C-- and/or a byte code level, which can be used as an
intermediate to an assembler level. This level should also provide hooks
to "universal binary standards" like CORBA and Unicode, which C and C++
carefully avoids due to their history.

There is no need to create a new language which has nothing more to offer
than the existing ones. Also C++ evolution iis based on providing superior
alternatives which you can use in place of the legacy ones.
Take for example exception handling in the place of return value checking.

In essence, what you are telling is to "recreate" a subset of the now
existing C++. Do something better, use the new and superior facilities that
C++ has to offer than the old stuff.


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Andrew Edwards]

"Hans Aberg" <re***********@matematik.su.se> wrote in message
news:re****************************@du130-86.ppp.su-anst.tninet.se...

Is it not time to make a new language D drawing on the experiences from C
and C++?

See for yourself:

http://www.digitalmars.com/d

[Richard Bos]

re***********@matematik.su.se (Hans Aberg) wrote:

Is it not time to make a new language D drawing on the experiences from C
and C++?

It has been that time several times now, if the people shouting from the
wings are to be believed. In fact, several such languages exist,
beginning with C++, but somehow none of them has replaced C. Tell you
what, though: you do the drudge work (a couple of years' hard work
should be enough), and we'll tell you whether we like it or not. Now all
you have to do is make sure that you don't create yet another
C-with-classes.

Richard

[Ioannis Vranos]

"Paul Hsieh" <qe*@pobox.com> wrote in message
news:MP************************@news.sf.sbcglobal. net...

There is also no way to communicate to the C/C++ faithful here (or other
similar newsgroups) that a more progressive stance on the evolution of the
standard (based on lessons learned from *those* languages) could significantly revitalize the C/C++ languages.

Check this: http://www.research.att.com/~bs/C++0x_keynote.pdf

If you have new ideas why don't you submit them in the committee or at least
at comp.std.c++ ? :-)

Just look at the C99 standard to see where the future of C is. They added
complex numbers to lure away all those hordes of Fortran programmers ...
*sigh*.
Yes i agree with you. C99 is a dead language. Instead of providing complex
and stuff as part of new header files only, they made them built in and with
ugly names!

You'd probably be better off trying to work on Python, Ruby, LUA, or a language of your own creation than trying to motivate anyone here to *improve* the C standard. Nobody cares anymore.

I disagree with you regarding C++!


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Alan Balmer]

On Wed, 09 Jul 2003 06:41:51 GMT, qe*@pobox.com (Paul Hsieh) wrote:

iv*@nothis.emails.ru says:

There is no need to create a new language which has nothing more to offer
than the existing ones. Also C++ evolution iis based on providing superior
alternatives which you can use in place of the legacy ones.
"Hans Aberg" <re***********@matematik.su.se wrote:

>
> See you in comp.std.d. :-)

<snip>There is also no way to communicate to the C/C++ faithful here (or other
similar newsgroups) that a more progressive stance on the evolution of the
standard (based on lessons learned from *those* languages) could significantly
revitalize the C/C++ languages.
I didn't know they needed "revitalizing."
Just look at the C99 standard to see where the future of C is. They added
complex numbers to lure away all those hordes of Fortran programmers ...
*sigh*.
Gosh, I didn't even know there was a contest! Do the members of the
standards committee get bonuses if enough programmers use C? Like many
programmers, I use the tool which is best for the job, considering all
relevant factors, and often that's C.
You'd probably be better off trying to work on Python, Ruby, LUA, or a language
of your own creation than trying to motivate anyone here to *improve* the C
standard.

That's what jvr said - there's no need to radically change C if there
are other languages to do the job. And no need to invent another
language if what you need already exists.

It seems that you are advocating that C/C++ evolve into the perfect
programming language. There ain't no such animal.

--
Al Balmer
Balmer Consulting
re************************@att.net

[llewelly]

qe*@pobox.com (Paul Hsieh) writes:

iv*@nothis.emails.ru says:

There is no need to create a new language which has nothing more to offer
than the existing ones. Also C++ evolution iis based on providing superior
alternatives which you can use in place of the legacy ones.
"Hans Aberg" <re***********@matematik.su.se wrote:

>
> See you in comp.std.d. :-)

Unforunately, you'll find the above attitude extremely prevalent in this and
the comp.std.c newsgroups. There's a lot of "C is a systems language" and "use
the right tool for the right job" nonsense commonly spouted here.

It makes better sense to use the wrong tool for the job? If you mean
to say that C should be improved to handle new jobs, then say that.

The people who were previously in the position of detesting C and C++ have long
since left and created their own pet languages (Java, Perl, Python, etc.) And
all those who remain here either don't care or don't realize realize that this
has happened.
Or we are happy that new languages have filled needs C and C++ did not
meet well. If you look at the goals of those languages, and
compare them to the goals of C++ (as described in D&E by
Stroustrup) or the goals of C, you will find they aim at very
different areas.

In particular, D&E makes it clear that Stroustrup has always believed
there are places for languages other than C++; he says 'use the
right tool for the right job' many different times in many
different ways.
There is also no way to communicate to the C/C++ faithful here (or other
similar newsgroups) that a more progressive stance on the evolution of the
standard (based on lessons learned from *those* languages) could significantly
revitalize the C/C++ languages.

[snip]

I do not know about the C community, but some of the C++ community is
still smarting from the too fast and too poorly communicated evolution
of the current standard - yes, I do mean the evolution that took
place in the early to mid 1990s, almost a decade ago. For whatever
reason, good information spreads slowly in the C++ community.

[Ioannis Vranos]

"dbtid" <db***@dev-null.us> wrote in message
news:36******************************@free.teranew s.com...

Then why are you here?

Basically "i am" in c.l.c++.

I see it's true that leopards don't change their stripes, even
after all these years.

Hrrrr (as cats purr).

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Paul Hsieh]

Alan Balmer <al******@att.net> wrote in message

On Wed, 09 Jul 2003 06:41:51 GMT, qe*@pobox.com (Paul Hsieh) wrote:

iv*@nothis.emails.ru says:

There is no need to create a new language which has nothing more to offer
than the existing ones. Also C++ evolution iis based on providing superior
alternatives which you can use in place of the legacy ones."Hans Aberg" <re***********@matematik.su.se wrote:

> See you in comp.std.d. :-)

<snip>

There is also no way to communicate to the C/C++ faithful here (or other
similar newsgroups) that a more progressive stance on the evolution of the
standard (based on lessons learned from *those* languages) could
significantly revitalize the C/C++ languages.

I didn't know they needed "revitalizing."

I'm sure you don't. I think the COBOL people probably still feel that
way.

Just look at the C99 standard to see where the future of C is. They added
complex numbers to lure away all those hordes of Fortran programmers ...
*sigh*.

Gosh, I didn't even know there was a contest! Do the members of the
standards committee get bonuses if enough programmers use C? Like many
programmers, I use the tool which is best for the job, considering all
relevant factors, and often that's C.

You must live in an extremely skewed world -- there are very few
projects left today where you can justify simply starting in the C
language. About the only places where this makes sense is where you
have no other compilers available, and its either that or assembly.

You'd probably be better off trying to work on Python, Ruby, LUA, or a
language of your own creation than trying to motivate anyone here to
*improve* the C standard.

That's what jvr said - there's no need to radically change C if there
are other languages to do the job. And no need to invent another
language if what you need already exists.

And this is what I said that you and others would say.

Look, my point of view is simple: C/C++ is clearly *faster* than just
about every other language, but its also clearly far less safe,
difficult to learn, extremely lacking features, etc., etc. Why do the
two have to go hand in hand?!?! In particular why can't I be *even
faster*, and *safer* at the same time? It is you people who say
things like "right tool for the right job" that implicitely ignore
this as a possibility!

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me! The thing is, there is no *technical*
reason why C cannot be modified in small ways in the core language,
and rather more serious (and badly needed) ways in the library to
provide this. I do not need the 100% safety of Java, but I could use
a little more than the 0% provided by C. And why am I resorting to
inline assembly any time I want real performance out of my state of
the art C compiler? Why am I constantly re-implementing standard data
structures, debug wrappers, and various other things that are well
known practice? At least the C++ people had the good sense to create
STL ...

For example, there is almost no C standard library function that I
cannot rewrite, or respecify to improve both performance and program
safety. Almost the entire stdlib is of a "first hack" quality,
practically enforced by the standard.
It seems that you are advocating that C/C++ evolve into the perfect
programming language.

I am? Can you please supply the relevant quote where I either say or
imply this? What I am saying is that the C (89, 99 whatever) standard
as it is is severely flawed. Why not at least bring it up to the
level of not being so flawed?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[pete]

Paul Hsieh wrote:

What I am saying is that the C (89, 99 whatever) standard
as it is is severely flawed. Why not at least bring it up to the
level of not being so flawed?

Seems more like a topic for
news:comp.std.c

--
pete

[Paul Hsieh]

"Ioannis Vranos" <iv*@nothis.emails.ru> wrote:

"Paul Hsieh" <qe*@pobox.com> wrote:

There is also no way to communicate to the C/C++ faithful here (or other
similar newsgroups) that a more progressive stance on the evolution of the
standard (based on lessons learned from *those* languages) could
significantly revitalize the C/C++ languages.
Check this: http://www.research.att.com/~bs/C++0x_keynote.pdf

I had not seen this before. He raises a lot of good and important
points, lots of them that I have tried to make. His most important
one, the one about safety, is something that I've become seriously
obsessed with over the past year or so.
If you have new ideas why don't you submit them in the committee or at least
at comp.std.c++ ? :-)
Well, he's asking for libraries and safety, and has pointed out the
buffer overflow problem related to safety -- that's an obvious queue
my "better string library":

http://bstring.sourceforge.net/

Its implemented in both C and C++. Now, I am far from an expert in
C++, and had some assistance in creating the C++ portion. If there
are fundamental design flaws with it, let me know, or modify it
yourselves or whatever.

The point of the bstring library, especially in comparison to the
numerous other string libraries out there, is that its high
performance, it carries absolutely no extra baggage with it, while
remaining totally interoperable with the char * buffer style strings.
It brings up the functionality level to nearly that of Python/Perl
(though I'm obviously missing regex's) with no dramatic compromises.

As to his comment about GC, I have thought about it, but I can't think
of a way to implement it properly with high performance *and* support
the typical malloc/free paradigm at the same time. Even if you could
make it work, the fact that C/C++ still cannot *guarantee* prevention
of buffer overflows leading to undefined behavior, add a GC background
thread and this is likely to manifest itself in programing errors that
are *truly* impossible to debug. Some C/C++ programmers are also used
to the idea that "encoded pointers" shouldn't lead to unexpected
behavior (though most C-based GC solutions fail when you do things
like this.)

The real goal of GC is eliminate the memory leaks, and simplify code
somewhat. So as an alternative to GC, why not just significantly
extend the heap management semantics? So many programmers write their
own "debug wrappers" for malloc/realloc/free anyhow, why not just
decide on a one useful set of very general extensions, provide sample
code for the vendors to use, and add it to the language standard. I
have some ideas here that have worked very well for me in practice, if
the C++ people are truly open to these ideas.

Just look at the C99 standard to see where the future of C is. They added
complex numbers to lure away all those hordes of Fortran programmers ...
*sigh*.

Yes i agree with you. C99 is a dead language.

Not just me! Ask the compiler vendors ... they seem to agree as well!

This calls to question one point in the slides above -- Bjarne
Stroustrup seems to be lamenting this inevitable split between C and
C++ that has been caused by C99. Perhaps he has to consider the
possibility that backward compatibility with C is no longer worth it.
There is no way to sufficiently mutate C++ to be acceptable for C89,
C99, and old C++. I think its fair to assume that C99 will not pick
up a sufficient audience at all. Simply dropping sufficient C99
compatibility is probably unavoidable anyway, so I'd say just pick up
whatever useful things from C99 (obviously "restrict", and perhaps the
vararrays, VARARG preprocessor stuff, etc) and move forward.

I.e., pining on about it isn't going to help. Make the cut as clean
as possible, and don't let yourselves be trapped by it.
[...] Instead of providing complex
and stuff as part of new header files only, they made them built in and with
ugly names!

Yeah, that too. Not to put too much of a political spin on this, but
I see the C99 spec as analogous to Saddam's 11K+ page declaration of
all his weapons program prior to the US ignoring it and crushing his
regime like a bug anyway. A technicality, a distraction, destined to
be forgotten, and ultimately irrelevant. (I emphasize again, I'm
*not* making a political statement about what I think about the whole
Iraq thing, just noting this one interesting aspect of it.)

You'd probably be better off trying to work on Python, Ruby, LUA, or a
language of your own creation than trying to motivate anyone here to
*improve* the C standard. Nobody cares anymore.

I disagree with you regarding C++!

Well, I was unaware of C++'s openess to suggestions. My previous
interaction with Mr. Stroustrup was not very productive, as we clearly
seemed to be talking past each other.

Anyhow, lets start with my string and heap suggestions above and see
what people think. Is there some more formal way that I should be
making these suggestions?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Mirek Fidler]

> The point of the bstring library, especially in comparison to the

numerous other string libraries out there, is that its high
performance, it carries absolutely no extra baggage with it, while
remaining totally interoperable with the char * buffer style strings.
It brings up the functionality level to nearly that of Python/Perl
(though I'm obviously missing regex's) with no dramatic compromises.

Is there anything that makes bstring superior to usual C++
interface/implementation, like std::string ?

Mirek

[Andrew Edwards]

In following a previous thread on the so called flawed state of the C99
standard and inadequacies of the C++ language, Richard Bos wrote:

"It has been that time several times now, if the people
shouting from the wings are to be believed. In fact,
several such languages exist, beginning with C++, but
somehow none of them has replaced C. Tell you what, though:
you do the drudge work (a couple of years' hard work should
be enough), and we'll tell you whether we like it or not.
Now all you have to do is make sure that you don't create
yet another C-with-classes."

This made me curious as to the community's approval rating of the current
effort to replace both the C and C++ languages. D was concocted in 1999 by
Walter Bright (www.walterbright.com) of Digital Mars (www.digitalmars.com),
and continues to evolve with helpful suggestions and critiques. It was
publicly revealed it in a heated debate on slashdot.com in August 2001
(http://slashdot.org/article.pl?sid=01/08/15/234223). Walter followed this
with a cover story (http://www.ddj.com/articles/2002/0202/) in the February
2002 issue of Dr. Dobbs.

Here is an overview of D the language:
http://www.digitalmars.com/d/overview.html

The entire language specification is located here:
http://www.digitalmars.com/d/

Their newsgroup is located here:
news://news.digitalmars.com/D

You may download a copy of the compiler (which is available in two flavors:
Win32 and x86 Linux) here:
http://www.digitalmars.com/d/changelog.html

Regards,
Andrew

[Mark McIntyre]

On 9 Jul 2003 19:35:40 -0700, in comp.lang.c , qe*@pobox.com (Paul
Hsieh) wrote:

You must live in an extremely skewed world -- there are very few
projects left today where you can justify simply starting in the C
language.
ahahahahahahah. Thats a funny joke, that is.
About the only places where this makes sense is where you
have no other compilers available, and its either that or assembly.
I wonder, out of idle interest, how many embedded systems there are
out there. ISTR that many games are written in C too.

That's what jvr said - there's no need to radically change C if there
are other languages to do the job. And no need to invent another
language if what you need already exists.

And this is what I said that you and others would say.

So someone states the bleeding obvious, and you agree. So why did you
ask teh question in the first place? Clue: you're a large stone
creature that is allergic to sunlight.
Look, my point of view is simple: C/C++ is clearly *faster* than just
about every other language, but its also clearly far less safe,
Nope.
difficult to learn,
only for people who find it hard counting to eleven without using
their toes.
extremely lacking features, etc., etc.
Nope.
Why do the
two have to go hand in hand?!?! In particular why can't I be *even
faster*, and *safer* at the same time?
you can. Please feel free to write a new langage, distribute it, and
if it takes off, well done.
It is you people who say
things like "right tool for the right job" that implicitely ignore
this as a possibility!
Actually thats what "the right tool for the right job" means, but
you're too argumentative to realise that.
*I* want features, more safety, and I want a heck of a lot more
performance than C gives me! The thing is, there is no *technical*
reason why C cannot be modified in small ways in the core language,
and rather more serious (and badly needed) ways in the library to
provide this.
Please do submit this to teh committee, along with demostration that
you won't lose portability to the currently supported platforms.
I do not need the 100% safety of Java, but I could use
a little more than the 0% provided by C. And why am I resorting to
inline assembly any time I want real performance out of my state of
the art C compiler?
Because you're a bad programmer? I've no idea.
For example, there is almost no C standard library function that I
cannot rewrite, or respecify to improve both performance and program
safety.
Then why aren't you working for MS or Borland, raking in megabucks
improving their std lib implementations.
Almost the entire stdlib is of a "first hack" quality,
practically enforced by the standard.

Only if you have a crapola version of the standard library. Its a poor
workman who blames his tools.

*Threadplonk*
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mirek Fidler]

> *I* want features, more safety, and I want a heck of a lot more

performance than C gives me! The thing is, there is no *technical*

May I ask you a humble question why you are not using C++ instead ?
I agree there is no technical reason and that is what C++ is about....

Mirek

[Ioannis Vranos]

"Paul Hsieh" <qe*@pobox.com> wrote in message
news:79**************************@posting.google.c om...

Well, he's asking for libraries and safety, and has pointed out the
buffer overflow problem related to safety -- that's an obvious queue
my "better string library":

http://bstring.sourceforge.net/

The point of the bstring library, especially in comparison to the
numerous other string libraries out there, is that its high
performance, it carries absolutely no extra baggage with it, while
remaining totally interoperable with the char * buffer style strings.

There is no buffer overflow problem in the C++ standard library and
std::string is also interoperable with char *.
As to his comment about GC, I have thought about it, but I can't think
of a way to implement it properly with high performance *and* support
the typical malloc/free paradigm at the same time.

Check .NET. It has interesting GC mechanisms.

Even if you could
make it work, the fact that C/C++ still cannot *guarantee* prevention
of buffer overflows leading to undefined behavior, add a GC background
thread and this is likely to manifest itself in programing errors that
are *truly* impossible to debug.

C & C++ are different languages. In C++ code you can guarantee buffer
overlofw protection by using the standard library facilities. I suggest you
read "The C++ Programming Language" 3rd Edition or Special Edition by Bjarne
Stroustrup (the creator of C++), *cover to cover*.


Some C/C++ programmers are also used
to the idea that "encoded pointers" shouldn't lead to unexpected
behavior (though most C-based GC solutions fail when you do things
like this.)

The real goal of GC is eliminate the memory leaks, and simplify code
somewhat. So as an alternative to GC, why not just significantly
extend the heap management semantics? So many programmers write their
own "debug wrappers" for malloc/realloc/free anyhow, why not just
decide on a one useful set of very general extensions, provide sample
code for the vendors to use, and add it to the language standard. I
have some ideas here that have worked very well for me in practice, if
the C++ people are truly open to these ideas.

You need a slow, thoroughh read of TC++PL 3 (see above). :-)



--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Finny Merrill]

This is off-topic in comp.lang.c

[Paul Hsieh]

"Mirek Fidler" <cx*@volny.cz> wrote in message news:<be************@ID-198693.news.dfncis.de>...

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me! The thing is, there is no *technical*

May I ask you a humble question why you are not using C++ instead ?
I agree there is no technical reason and that is what C++ is about....

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C. C++ has a certain set of additional features that, frankly, I just
don't have any interest in. Its just a personal preference kind of
thing.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on), a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking), a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

I don't just want more features, I want features that from the lessons
that *I* have learned.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Paul Hsieh]

"Ioannis Vranos" <iv*@nothis.emails.ru> wrote:

"Paul Hsieh" <qe*@pobox.com> wrote:

Well, he's asking for libraries and safety, and has pointed out the
buffer overflow problem related to safety -- that's an obvious queue
my "better string library":

http://bstring.sourceforge.net/

The point of the bstring library, especially in comparison to the
numerous other string libraries out there, is that its high
performance, it carries absolutely no extra baggage with it, while
remaining totally interoperable with the char * buffer style strings.
There is no buffer overflow problem in the C++ standard library and
std::string is also interoperable with char *.

I have it on good authority that std::string is slow, lacking in
features and has been happily replaced by my CBString library in at
least one instance. I am not a C++ expert, so I don't know the
details, but apparently my CBString is a necessary and valuable
replacement for MFC's CString (most notably, because my library is
portable to something outside of MFC) which itself is a well motivated
replacement for std::string. I don't know the technical details as to
what is really wrong with std::string, but apparently its just not
acceptable.

As to his comment about GC, I have thought about it, but I can't think
of a way to implement it properly with high performance *and* support
the typical malloc/free paradigm at the same time.

Check .NET. It has interesting GC mechanisms.

..NET's primary assumption is the existences of the CLI platform. This
allows them to make certain assumptions about all memory utilization
which cannot be made in more ordinary native C/C++ implementations.

Even if you could
make it work, the fact that C/C++ still cannot *guarantee* prevention
of buffer overflows leading to undefined behavior, add a GC background
thread and this is likely to manifest itself in programing errors that
are *truly* impossible to debug.

C & C++ are different languages. In C++ code you can guarantee buffer
overflow protection by using the standard library facilities.

Yes, I know, if you look at my bstrlib library above you will see that
I have done exactly this. But in the end both languages still rely on
programmer competence to avoid buffer overflows. Don't get trapped
into the same nonsense that the C people have fallen into by simply
saying that spec *ALLOWS* for safe implementations -- that's
ridiculous. I am concerned with *real world* safety, not theoretical
safety.

Security flaw and just software instability in general comes from this
inattention to real world safety issues, and the features of C++ do
not guarantee any such way
[...] I suggest you
read "The C++ Programming Language" 3rd Edition or Special Edition by Bjarne
Stroustrup (the creator of C++), *cover to cover*.

Well, I'm afraid that's way too much of an investement just to find
out why implementing more sophisticated memory management
functionality is a bad idea for C++. Is there any way you can provide
some kind idea as to why this is?

I am aware of the whole constructor / destructor paradigm in C++, and
yes of course that mitigates some kinds of memory leaks quite
substantially. But it doesn't remove the existence of "new" or
"malloc" which are still useful, yet are the source for memory leaks
and other corruptions (double freeing, for example) in the first
place.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Paul Hsieh]

"Mirek Fidler" <cx*@volny.cz> wrote in message news:<be************@ID-198693.news.dfncis.de>...

The point of the bstring library, especially in comparison to the
numerous other string libraries out there, is that its high
performance, it carries absolutely no extra baggage with it, while
remaining totally interoperable with the char * buffer style strings.
It brings up the functionality level to nearly that of Python/Perl
(though I'm obviously missing regex's) with no dramatic compromises.

Is there anything that makes bstring superior to usual C++
interface/implementation, like std::string ?

Apparently there is, but I am not a C++ expert (a C++ person who was
very dissatistfied with std::string and/or MFC's CString wrote the
interface for me, I just filled in the implementation based on my C
library), so I don't know exactly what it is. Likely its performance
and functionality (but functionality is not a likely reason -- can't
you just build a super-class and add in whatever functionality you
like?). I will go investigate this further.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Ioannis Vranos]

"Paul Hsieh" <qe*@pobox.com> wrote in message
news:79**************************@posting.google.c om...

[...] I suggest you
read "The C++ Programming Language" 3rd Edition or Special Edition by Bjarne Stroustrup (the creator of C++), *cover to cover*.

Well, I'm afraid that's way too much of an investement just to find
out why implementing more sophisticated memory management
functionality is a bad idea for C++. Is there any way you can provide
some kind idea as to why this is?

I am aware of the whole constructor / destructor paradigm in C++, and
yes of course that mitigates some kinds of memory leaks quite
substantially. But it doesn't remove the existence of "new" or
"malloc" which are still useful, yet are the source for memory leaks
and other corruptions (double freeing, for example) in the first
place.

Well lets better move to c.l.c++ to discuss this kind of things because
c.l.c. is inhabited by dragons and other nasty creatures waiting for some
innocent passers to attack them. :-)

In regular programs you can almost completely avoid the explicit memory
allocation and deallocation on the free store by using the standard library
containers (use them for objects in the stack too).
Example:
#include <vector>

// ...

using std::vector;

vector<int> vec;
vec.push_back(7);
for (vector<int>::size_type i=0; i<vec.size(); ++i)
// do whatever with vec[i];
// At the end of the scope or when an exception is thrown, vec
// is cleaned along with its contents automatically.
But hurry lets leave from clc, i am hearing them approaching!


--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Randy Howard]

In article <79**************************@posting.google.com >,
qe*@pobox.com says...

You must live in an extremely skewed world -- there are very few
projects left today where you can justify simply starting in the C
language. About the only places where this makes sense is where you
have no other compilers available, and its either that or assembly.
I thought you were making some good points, right up until the part
where you said the above, and then I became convinced you had simply
had some sort of brain-ECC error. You *must* be joking.

If you want C++ and have the memory and processor to spare, go for
it. If you like Python or Ruby better, they're also readily
available. At this point, it seems like your "mission" is to form
a line of converts heading down the hall for the other languages.
If so, that's rather OT for clc.
*I* want features, more safety, and I want a heck of a lot more
performance than C gives me!
C runs screamingly fast on most hardware, and the only places I've
ever had to tweak it for better performance is when standard library
functions have been the bottleneck. That's not the language, that's
the "libc" implementors' fault. Writing around such bottlenecks if/
when the become a factor is no big deal if you are even moderately
competent. Going to Python or one of your other alterative
languages certainly isn't going to help with performance.
And why am I resorting to inline assembly any time I want real
performance out of my state of the art C compiler?
Because it can't read your mind? Or because you haven't experimented
enough with how your compiler optimizes particular C constructs for
a given target CPU/OS combination? Maybe your target compiler isn't
as SOTA as you think it is. Real world example: VC++6 (used as a C
compiler) on Windows vs. gcc on Linux. The Windows implementation
(identical source code) ran 30% slower for a tight loop using a
particular standard library call. Looking at how code was generated
on both platforms, the gcc compiler was smart enough to resort to
the appropriate MMX instructions when compiled with the right arch
and cpu flags. The MS compiler simply did not. A little inline
assembly in my own replacement for the offending library call for
WIN32 and the program performed basically identically on both
platforms. I normally wouldn't care about maximum performance per
se if it required inline assembly because a lot of applications
simply don't need it. In this case, performance was THE thing so
it mattered above all else.
Why am I constantly re-implementing standard data
structures, debug wrappers, and various other things that are well
known practice? At least the C++ people had the good sense to create
STL ...
Because you never started building your own library of ADTs, or
didn't want to obtain one elsewhere? I can't read your mind.
For example, there is almost no C standard library function that I
cannot rewrite, or respecify to improve both performance and program
safety. Almost the entire stdlib is of a "first hack" quality,
practically enforced by the standard.

Then don't use it. There are a lot of standard lib functions that I
won't use either. As you say, it's not hard to implement similar
functionality on your own, or obtain it from a freely available or
commercial library.
--
Randy Howard
remove the obvious bits from my address to reply.

[Kevin Easton]

In comp.lang.c Randy Howard <ra**********@foomegapathdslbar.net> wrote:

In article <79**************************@posting.google.com >,
qe*@pobox.com says...

[...]

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me!

C runs screamingly fast on most hardware, and the only places I've
ever had to tweak it for better performance is when standard library
functions have been the bottleneck. That's not the language, that's
the "libc" implementors' fault.

In some cases, it is a problem with the language, because the problem
lies in the way the standard library is defined. For example, functions
like strcat and strcpy should really be returning a pointer to the end of
the resulting string - they've already calculated it, but then they throw
it away, so if the caller needs it they have to calculate it again,
which can be time-consuming (relatively speaking) for long strings.

- Kevin.

[Frank Schmitt]

qe*@pobox.com (Paul Hsieh) writes:

"Mirek Fidler" <cx*@volny.cz> wrote in message
news:<be************@ID-198693.news.dfncis.de>...

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me! The thing is, there is no *technical*

May I ask you a humble question why you are not using C++ instead ?
I agree there is no technical reason and that is what C++ is about....

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C.

IMHO, this statement is wrong - how about expression templates ?

regards
frank

--
Frank Schmitt
4SC AG phone: [phone]
e-mail: frank DOT schmitt AT 4sc DOT com

[Wolfgang Riedel]

Paul Hsieh wrote:

"Mirek Fidler" <cx*@volny.cz> wrote in message news:<be************@ID-198693.news.dfncis.de>...

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me! The thing is, there is no *technical*

May I ask you a humble question why you are not using C++ instead ?
I agree there is no technical reason and that is what C++ is about....

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C. C++ has a certain set of additional features that, frankly, I just
don't have any interest in. Its just a personal preference kind of
thing.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on), a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking), a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

I don't just want more features, I want features that from the lessons
that *I* have learned.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

use PL/1

Wolfgang

[Mirek Fidler]

> I'm not as familliar with C++, and, its feature set is not really what

I want. C++ also has absolutely no opportunity to be any faster than
C.
Well, I think you are completely wrong on this, at least if you take
into consideration time spend to implement an application. Templates
provide much more effective way w.r.t. runtime performance.
When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on),
OTOH, I agree that most of above issues are missing both from C and
C++.
a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking),
Yeah. That is what C++ and templates are about too.
a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.
Library stuff.
I don't just want more features, I want features that from the lessons
that *I* have learned.

I am learning C/C++ for more than 15 years now and what I have
learned during first 5 years is fact that C++ is way better tool than C
:)

Mirek

[Mirek Fidler]

I am aware of the whole constructor / destructor paradigm in C++, and
yes of course that mitigates some kinds of memory leaks quite
substantially. But it doesn't remove the existence of "new" or
"malloc" which are still useful, yet are the source for memory leaks

Yes, but I think that most important is fact that
construtor/destructor paradigm removes almost any need of "delete" or
"free", at least at interface level.

In out C++ code there is hardly one "delete", usually well hidden in
implementation, per 10000 lines of code. I can show e.g. complete
sources of Win32/X11 wordprocessor without single "delete" or "free"
call.

Mirek

[Greg Comeau]

In article <79**************************@posting.google.com >,
Paul Hsieh <qe*@pobox.com> wrote:

I'm not as familliar with C++, and, its feature set is not really what
I want.
Of course, you may prefer C, but it's sort of hard to believe
that there is *nothing* in C++ that you'd want. Perhaps this
is indicative that indeed you are not as familiar with C++.
C++ also has absolutely no opportunity to be any faster than
C.
If you are not familiar with something, then how can
you make that claim? Certainly C++ has many such opportunities.
Frankly, both language could do with some improvement here.
C++ has a certain set of additional features that, frankly, I just
don't have any interest in. Its just a personal preference kind of
thing.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on), a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking), a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.
This is confusing, because C has some of these same problems.
I don't just want more features, I want features that from the lessons
that *I* have learned.

This make sense. On this same note, it's important to keep
open-minded about featured derived from what others have learned
too. Many features in many languages are easy to misunderstand,
including in C, and do sometimes require a closer look. An
issue is that it's easy for syntax to become a focus when
things such as the underlying modeling, design, abstraction,
and techniques should be the focus.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Thomas Stegen]

Ioannis Vranos wrote:

Well lets better move to c.l.c++ to discuss this kind of things because
c.l.c. is inhabited by dragons and other nasty creatures waiting for some
innocent passers to attack them. :-)

This is like going into a Rangers pub wearing celtic shirt. It is
not only dangerous, it is also stupid.

And by the way, if the "innocent passer[sic]" attacks he is no longer
innocent... Or am I missing something.

--
Thomas.
"What is the future c existence which does not do in all languages"

[Thomas Stegen]

Paul Hsieh wrote:

[SNIP]

How dare you? Haven't you learned by know that this type of discussion
is useless here at clc. C is the safest and fastest language on the
planet. Why on earth do you want additional libraries when you can
write them yourself? And if, against all odds, there is something bad
about C we don't want to know about it. We want to continue living in
the belief that C is the superior of all languages and has no flaws
whatsoever.

If you have a complaint submit it to the committee, we do not want these
kind of constructive and educational discussions here. Quite frankly,
such discussions offend us in ways you cannot even imagine.

That the drone-like predictability of responses to posts such as yours
from the regulars around here haven't deterred your attempts yet surely
marks you as a troll.

Pathetic.

--
Thomas.
"What is the future c existence which does not do in all languages"

[Malcolm]

"Mirek Fidler" <cx*@volny.cz> wrote in message

I am learning C/C++ for more than 15 years now and what I have
learned during first 5 years is fact that C++ is way better tool than C
:)

It's a different tool. To extent that a C++ compiler is more complicated and
more expensive to write than a C compiler it is also "better".
However there are many situations where it is actually an advantage not to
have C++ features. An obvious one is where code has to be maintained by an
electronic engineer who isn't a full time programmer. Another one is where
the program is quite simple and it is much easier to do a procedural rather
than an object-oriented design - use of C++ in this situation often leads to
a horrible hybrid that is hard to understand and debug.

[Mirek Fidler]

> > I am learning C/C++ for more than 15 years now and what I have

learned during first 5 years is fact that C++ is way better tool than C :)
It's a different tool. To extent that a C++ compiler is more

complicated and more expensive to write than a C compiler it is also "better".
I agree with this, but I do not see as reason.
However there are many situations where it is actually an advantage not to have C++ features. An obvious one is where code has to be maintained by an electronic engineer who isn't a full time programmer.
Well, perhaps.
Another one is where
the program is quite simple and it is much easier to do a procedural rather than an object-oriented design - use of C++ in this situation often leads to a horrible hybrid that is hard to understand and debug.

I do not understand this. If it is procedural, write is as
procedural. C++ does not require you to put 'classes' where you do not
need them.

Mirek

[Jerry Coffin]

In article <79**************************@posting.google.com >,
qe*@pobox.com says...

[ ... ]

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C.
Rather the opposite: C has virtually no opportunities to be faster than
C++, but there are quite a few situations in which C++ not only can be,
but more importantly, typically WILL be faster than C. Just for an
obvious example, templates offer quite a few opportunities for
generating code in-line that would normally involve calling functions
through pointers in C. In many cases, you can expect the C++ version to
be twice as fast as a bare minimum.
When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on),
C++ doesn't make a lot of fundamental improvements in these areas, but
it does provide a few things that make them substantially less
problematical. In C, you end up with some non-portable bits of code to
do the bottom levels of these sorts of manipulations, and C++ doesn't
really help in that area at all. C++ does, however, typically make a it
a whole lot easier to integrate those non-portable bits into the rest of
the code in a much more natural way. To use one of your examples, C++
doesn't directly support expanding multiplies -- you need to write some
functions to do that. The difference is that in C, you end up with code
something like:

your_type x, y, z;

set_val(&y, something);
set_val(&z, something_else);
ex_mul(&x, &y, &z);

Whereas in C++, you can overload operators, to at least keep the rest of
the code a bit more readable, so your multiplication looks like:

your_type x, y = something, z = something_else;

x = y * z;
a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking),
C++ provides basically that, but doesn't call it "a more capable
preprocessor" -- instead, it calls it "templates".
a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

Depending on what exactly you mean by "complete abstracted" (for
example) C++ may provide quite a bit more of what you want. Then again,
it may not either -- for better or worse, your description is incomplete
enough that it's almost impossible to give a definitive answer.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[JustBoo]

On 11 Jul 2003 11:00:54 -0400, co****@panix.com (Greg Comeau) wrote:

An
issue is that it's easy for syntax to become a focus when
things such as the underlying modeling, design, abstraction,
and techniques should be the focus.

Oh man, I fight this all the time, in myself and with younger
engineers.

We start a meeting about a "subject," and before you know it, it's
become a debate about syntax and coding style. Hmmm... kinda'
reminds me of certain usenet newsgroups. :-p I'm far too eager to
jump in myself and add fuel to the fire. I have to force myself to get
back to the subject at hand. It's way too much fun... it wastes an
incredible amount of time. :-) Sometimes I say we could solve
world-hunger if we spent as time and energy on that. I'm just as
guilty though.

"One night I walked home very late and fell asleep in somebody's
satellite dish. My dreams showed up on TVs all over the world."-sw

Get your stinking advertisement off my post you striped bastards!
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[JustBoo]

On Fri, 11 Jul 2003 18:09:37 +0000, Thomas Stegen
<ts*****@cis.strath.ac.uk> wrote:

How dare you? [snippy] And if, against all odds, there is something bad
about C we don't want to know about it. We want to continue living in
the belief that C is the superior of all languages and has no flaws
whatsoever.
Damn, that made me laugh out loud. You go sister! :-p
If you have a complaint submit it to the committee, we do not want these
kind of constructive and educational discussions here. Quite frankly,
such discussions offend us in ways you cannot even imagine.
I feel your pain, baby.
That the drone-like predictability of responses to posts such as yours
from the regulars around here haven't deterred your attempts yet surely
marks you as a troll.
What is the wind speed of a... :-)
Pathetic.

"Major Strasser has been shot!... Round up the usual suspects!"
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[Greg Comeau]

In article <3f***************@news.dakotacom.net>,
<Ju*****@BooHoo.gone> wrote:

On 11 Jul 2003 11:00:54 -0400, co****@panix.com (Greg Comeau) wrote:

An
issue is that it's easy for syntax to become a focus when
things such as the underlying modeling, design, abstraction,
and techniques should be the focus.

Oh man, I fight this all the time, in myself and with younger
engineers.

We start a meeting about a "subject," and before you know it, it's
become a debate about syntax and coding style. Hmmm... kinda'
reminds me of certain usenet newsgroups. :-p I'm far too eager to
jump in myself and add fuel to the fire. I have to force myself to get
back to the subject at hand. It's way too much fun... it wastes an
incredible amount of time. :-) Sometimes I say we could solve
world-hunger if we spent as time and energy on that. I'm just as
guilty though.

This may sound like I'm contradicting myself, but I think
there is room for discussions about syntax and style too.
But I think it's important, as in all discussions, to prioritize,
and to give things time constraints. It's often good when
somebody can offer rationales, no matter what the discussion,
rather than mandates, or because it sounds good. Last but
not least, over the years I've come to appreciate things
such as "lunch time", or a discussion over a beer.
So there is a time and place for everything. Sometimes
it is just recreational fish-story'ing, other times
you can actually learn something from it.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Louis-Philippe Huberdeau]

A language specification for D is already availible along with a compiler.

http://www.digitalmars.com/d/
Greg Comeau wrote:

In article <3f***************@news.dakotacom.net>,
<Ju*****@BooHoo.gone> wrote:

On 11 Jul 2003 11:00:54 -0400, co****@panix.com (Greg Comeau) wrote:

An
issue is that it's easy for syntax to become a focus when
things such as the underlying modeling, design, abstraction,
and techniques should be the focus.

Oh man, I fight this all the time, in myself and with younger
engineers.

We start a meeting about a "subject," and before you know it, it's
become a debate about syntax and coding style. Hmmm... kinda'
reminds me of certain usenet newsgroups. :-p I'm far too eager to
jump in myself and add fuel to the fire. I have to force myself to get
back to the subject at hand. It's way too much fun... it wastes an
incredible amount of time. :-) Sometimes I say we could solve
world-hunger if we spent as time and energy on that. I'm just as
guilty though.

This may sound like I'm contradicting myself, but I think
there is room for discussions about syntax and style too.
But I think it's important, as in all discussions, to prioritize,
and to give things time constraints. It's often good when
somebody can offer rationales, no matter what the discussion,
rather than mandates, or because it sounds good. Last but
not least, over the years I've come to appreciate things
such as "lunch time", or a discussion over a beer.
So there is a time and place for everything. Sometimes
it is just recreational fish-story'ing, other times
you can actually learn something from it.

[David Rasmussen]

Walter wrote:

"Hans Aberg" <re***********@matematik.su.se> wrote in message
news:re****************************@du130-86.ppp.su-anst.tninet.se...

Is it not time to make a new language D drawing on the experiences from C
and C++?

Yes, it is. It's been done and there's a compiler for D. See
www.digitalmars.com/d/ and www.digitalmars.com/d/comparison.html for a
language comparison.

D won't lift off until there is a gcc front end for it. When that
happens, it's use will explode.

/David

[Mirek Fidler]

> D won't lift off until there is a gcc front end for it. When that

happens, it's use will explode.

With all respect to Walters efforts, I strongly doubt it. There is
only a little that D offers over existing alternatives, aside from much
simpler compiler.

BTW, if I can comment a list presented at

http://www.digitalmars.com/d/comparison.html

w.r.t. C++, that following issues, noted in list as not present in
C++, I am using every day (implemented as a library based solution):

Function delegates
Lightweight arrays
Resizeable arrays
Arrays of bits
Built-in strings (of course, not builtin in C++, but there is only a
little difference)
Array bounds checking

Other than that, I do not believe that there is a place for another
C based GC language....

Mirek

[Walter]

"David Rasmussen" <da*************@gmx.net> wrote in message
news:be**********@news.net.uni-c.dk...

Walter wrote:

"Hans Aberg" <re***********@matematik.su.se> wrote in message
news:re****************************@du130-86.ppp.su-anst.tninet.se...

Is it not time to make a new language D drawing on the experiences from Cand C++?

Yes, it is. It's been done and there's a compiler for D. See
www.digitalmars.com/d/ and www.digitalmars.com/d/comparison.html for a
language comparison.

D won't lift off until there is a gcc front end for it. When that
happens, it's use will explode.

D's front end is GPL'd open source. Anyone is free to connect it to gcc's
optimizer and back end. The current compilers are for Win32 and Linux 86.

[David Rasmussen]

Walter wrote:

D's front end is GPL'd open source. Anyone is free to connect it to gcc's
optimizer and back end. The current compilers are for Win32 and Linux 86.

I know, but I'm not going to do it :)

/David

[Walter]

"Mirek Fidler" <cx*@volny.cz> wrote in message
news:be************@ID-198693.news.uni-berlin.de...

D won't lift off until there is a gcc front end for it. When that
happens, it's use will explode. With all respect to Walters efforts, I strongly doubt it. There is
only a little that D offers over existing alternatives, aside from much
simpler compiler.

D offers a great deal of improvement, although that may not be obvious
without writing programs in it to see. For some examples, see:

www.digitalmars.com/d/cpptod.html
www.digitalmars.com/d/ctod.html
www.digitalmars.com/d/pretod.html

BTW, if I can comment a list presented at

http://www.digitalmars.com/d/comparison.html

w.r.t. C++, that following issues, noted in list as not present in
C++, I am using every day (implemented as a library based solution):

Function delegates
Lightweight arrays
Resizeable arrays
Arrays of bits
Built-in strings (of course, not builtin in C++, but there is only a
little difference)
Array bounds checking
I agree that you can do all these things with an appropriate library. I will
also point out that you can do object oriented programming in C (see
Microsoft's C com library), and, of course, anything can be done in
assembler. The more interesting issue is how easilly these things are done,
how hard it is to learn how to use the features properly, how maintainable
they are once done, and how brittle they are.

Other than that, I do not believe that there is a place for another
C based GC language....

I agree that D does not currently have the backing of a mega-corporation.
But it does have quite a following of enthusiasts now, as 13,000 messages in
the D newsgroup will attest. The compiler is supported and constantly
improves. Stay tuned!

[Malcolm]

"Mirek Fidler" <cx*@volny.cz> wrote in message

Use of C++ in this situation often leads to
a horrible hybrid that is hard to understand and debug.

I do not understand this. If it is procedural, write is as
procedural. C++ does not require you to put 'classes' where you do not
need them.

If you are self-disciplined and have complete control of the source then of
course you can use C++ as a "better C" - maybe with inline functions and
overloading and // comments but no class inheritance.

However you often don't have that sort of control. C++ is such a big
language that there is plenty of scope for other programmers to mess up your
nice logical design. Insisting that all source files are C is a simple,
obeyable instruction, and automatically prevents use of classes, mixtures of
new and malloc, and cout and stdout, inconsistent use of the stl, and all
the other horrors that can come from undisciplined C++ procedural/object
hybrids.

[Paul Hsieh]

"Mirek Fidler" <cx*@volny.cz> wrote:

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C.

Well, I think you are completely wrong on this, at least if you take
into consideration time spend to implement an application. Templates
provide much more effective way w.r.t. runtime performance.

I don't buy this. Templates are just a safer way of doing what I do
in C with macros. Explain to me where exactly you see the performance
advantage. (And remember its C++ which has introduced the idea of
*runtime* type checking ideas, not C.)

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on),

OTOH, I agree that most of above issues are missing both from C and
C++.

Try telling that to someone in comp.lang.c or comp.c.std. They just
don't believe that these thigs are even missing. Or just choose not
see or care.

a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking),

Yeah. That is what C++ and templates are about too.

You can automatically unroll loops with templates?!?! Pray, tell me
how! Can you declare functions with exactly n-number of parameters
for a large range of n's?

a way to debug and manipulate the memory heap, completely abstracted stream
I/O and so on.

Library stuff.

Yes, of course! No criticism of C or C++ would be complete without a
stab at the pitful libraries they come with.

I don't just want more features, I want features that from the lessons
that *I* have learned.

I am learning C/C++ for more than 15 years now and what I have
learned during first 5 years is fact that C++ is way better tool than C
:)

This seem non-sequitor. A formula-1 racer is a much better car than a
Geo Metro, but its not going to be a better vehicle for typical
commuting now is it? Look, I don't fault C++'s for its OO or other
features. I just don't *CARE* about them.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Paul Hsieh]

co****@panix.com (Greg Comeau) wrote in message news:<be**********@panix5.panix.com>...

In article <79**************************@posting.google.com >,
Paul Hsieh <qe*@pobox.com> wrote:

I'm not as familliar with C++, and, its feature set is not really what
I want.
Of course, you may prefer C, but it's sort of hard to believe
that there is *nothing* in C++ that you'd want. Perhaps this
is indicative that indeed you are not as familiar with C++.

C++ also has absolutely no opportunity to be any faster than
C.

If you are not familiar with something, then how can
you make that claim?

I disassemble C++ code written by others? I have a bootcamp level of
understanding of the C++ primitives, and when challenged to do so, no
one has ever been able provide me an example of such a case?
[...] Certainly C++ has many such opportunities.
Like?
Frankly, both language could do with some improvement here.
Yes, this is my *real* point.

Its just so pathetic that Fortran, of all obsolete boondongle
languages that there are, has been able to thumb its nose at C and C++
for so long. Only now that C has introduced "restrict" is it
*possible* for C to catch up with Fortran (and even then you need an
auto-vectorizing compiler to match the latest Fortran standard's
built-in SIMD support), and thats only if enough people implement C99
for restrict to be a truly portable concept (not likely.) Actually,
its likely that only if the *C++* community adopts restrict (which I
*assume* is a forgone conclusion) will there be a chance of it being
usable as a portable concept.

But there are plenty of other opportunites here.

C++ has a certain set of additional features that, frankly, I just
don't have any interest in. Its just a personal preference kind of
thing.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on), a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking), a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

This is confusing, because C has some of these same problems.

Yes. I'm not here to criticize C++ versus C. To my mind I see them
as basically the same thing. Its just someone else pointed out that
the C++ communnity is probably far more open minded.

I don't just want more features, I want features that from the lessons
that *I* have learned.

This make sense. On this same note, it's important to keep
open-minded about featured derived from what others have learned
too.

Of course, its just that I have been met with such a ridiculous amount
of resistance on this. When I look at the bizzarro changes that
*were* put into C99, its obvious that they listen to *someone* ...
someone with a very sick and twisted sense of humor, I think. I can't
speak for everyone else, I only know what *I* see as fatally flawed
about these languages.
[...] Many features in many languages are easy to misunderstand,
including in C, and do sometimes require a closer look.
You're right -- I'm sure there's a primitive rotate instruction in
there somewhere that I'm just not seeing. And walking the list of
entries allocated from the heap? Oh I'm sure I'm just not
*understanding* how to do that.
[...] An issue is that it's easy for syntax to become a focus
What? When did I suggest anything about syntax ... what are you
talking about?
[...] when things such as the underlying modeling, design, abstraction,
and techniques should be the focus.

Admittedly, I'm a little bit light on the abstraction part, as I think
C++ has more than enough abstraction for anyone (so I don't think
there's much point to comment there), but if you go back and look
carefully at what I've said, I think you'll find that I am
fundamentally very concerned about the other things.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sourceforge.net/

[Chris Torek]

In article <79*************************@posting.google.com>
Paul Hsieh <qe*@pobox.com> writes:

You can automatically unroll loops with templates?!?! Pray, tell me
how!

Templates appear to be a Turing-complete programming language
in themselves.

I recall hearing a tale of someone writing integer arithmetic in
templates, then using that to implement rational numbers, then
using that in turn to write a program that "templated out" the
value of pi to however many digits you like at compile time. I
also remember hearing that this program caused most C++ compilers
to explode, and that G++ was run on it for weeks without terminating.
:-)

Along the same lines, a quick Google search turned up
<http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html>.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Mirek Fidler]

> > Well, I think you are completely wrong on this, at least if you
take

into consideration time spend to implement an application. Templates
provide much more effective way w.r.t. runtime performance.
I don't buy this. Templates are just a safer way of doing what I do
in C with macros. Explain to me where exactly you see the performance
advantage.

Well, try to implement generic associative container as C library
(using macros if you wish) and then as C++ templates library (or use
e.g. Index from www.ntllib.org). I bet you will realize that C++ version
is significantly faster.

OTOH, I agree that most of above issues are missing both from C and C++.

Try telling that to someone in comp.lang.c or comp.c.std. They just
don't believe that these thigs are even missing. Or just choose not
see or care.

Yes, that is sad. OTOH, I seldom miss these features in practice.

And then there is always that problem that non every CPU in the
world supports all features you want...

Yeah. That is what C++ and templates are about too.

You can automatically unroll loops with templates?!?!

Well, I do know know what exactly you mean by loop unrolling. Give
me an example.
how! Can you declare functions with exactly n-number of parameters
for a large range of n's?

Yes. Overloading. (Again, if I can understand what you mean). I do
this quite often. No problem to e.g. implement Sum or Max function (or
function template) that works for up to say 20 parameters (for more than
20 it does not have sense anyway).

Library stuff.

Yes, of course! No criticism of C or C++ would be complete without a
stab at the pitful libraries they come with.

With this regard, I agree that both C and C++ standard libraries can
be considered "pitful". But you are not required to use them. That said,
rather than inventing new language, let us concentrate on new
libraries....

I am learning C/C++ for more than 15 years now and what I have
learned during first 5 years is fact that C++ is way better tool than C :)

This seem non-sequitor. A formula-1 racer is a much better car than a
Geo Metro, but its not going to be a better vehicle for typical
commuting now is it?

Can I retiterate this as "better tool for everydays job" ? :)

Mirek

[Alan Balmer]

On 9 Jul 2003 19:35:40 -0700, qe*@pobox.com (Paul Hsieh) wrote:

no need to invent another
language if what you need already exists.

And this is what I said that you and others would say.

Well, when it comes to the point where you are disagreeing with a
tautology, further discussion is obviously pointless.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Kevin Easton]

In comp.lang.c Paul Hsieh <qe*@pobox.com> wrote:

co****@panix.com (Greg Comeau) wrote in message news:<be**********@panix5.panix.com>...

[...]

[...] Many features in many languages are easy to misunderstand,
including in C, and do sometimes require a closer look.

You're right -- I'm sure there's a primitive rotate instruction in
there somewhere that I'm just not seeing.

Yes, it's quite cunningly hidden:

unsigned rot(unsigned n, int m)
{
return n >> (32-m) | n << m;
}

gcc -S foo.c
cat foo.s

rot:
pushl %ebp
movl %esp,%ebp
movl 12(%ebp),%ecx
movl 8(%ebp),%edx
roll %cl,%edx
movl %edx,%eax
jmp .L2
.p2align 4,,7
..L2:
leave
ret

Have a bit more faith in the optimiser!

- Kevin.