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 <[email protected]>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>

 

[Victor Bazarov]

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]

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]

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]

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]

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]

(e-mail address removed) says:

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.

 

[llewelly]

(e-mail address removed) says:



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]

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]

I didn't know they needed "revitalizing."

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

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.

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?

 

[pete]

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

 

[Paul Hsieh]

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.

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.)

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?

 

[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]

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.

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*

 

[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]

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]

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]

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.

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.

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.