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/>

[Paul Hsieh]

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

"Paul Hsieh" <qe*@pobox.co m> 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.c om/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.co m> wrote in message
news:79******** *************** ***@posting.goo gle.com...

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.dfn cis.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.ema ils.ru> wrote:

"Paul Hsieh" <qe*@pobox.co m> 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.dfn cis.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/