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

[Ioannis Vranos]

"Paul Hsieh" <qe*@pobox.co m> wrote in message
news:79******** *************** ***@posting.goo gle.com...

[...] 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>::s ize_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**********@f oomegapathdslba r.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.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.

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

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.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? 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"