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

[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.co m (Greg Comeau) wrote in message news:<be******* ***@panix5.pani x.com>...

In article <79************ **************@ posting.google. com>,
Paul Hsieh <qe*@pobox.co m> 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************ *************@p osting.google.c om>
Paul Hsieh <qe*@pobox.co m> 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.co m> wrote:

co****@panix.co m (Greg Comeau) wrote in message news:<be******* ***@panix5.pani x.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.