D

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

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]

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]

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]

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]

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

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.

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?

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

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


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.

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.

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.

 

[Chris Torek]

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

 

[Mirek Fidler]

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

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.

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

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

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

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]

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.

 

[Kevin Easton]

(e-mail address removed) (Greg Comeau) wrote in message news:<[email protected]>... [...]

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

 

[pete]

(e-mail address removed) (Greg Comeau) wrote in message

[...] 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;
}

If you can't write it portably, then you're making the point
that a primative rotate instruction is not part of C.
Is that what you're getting at ?

 

[Arthur J. O'Dwyer]

If you can't write it portably,

[Note that he *could* have made it portable by clever use of UINT_MAX.]

then you're making the point
that a primitive rotate instruction is not part of C.
Is that what you're getting at ?

Yes. His point, as I understand it, was two-fold: first, that since
the "rotate" opcode itself is not portable, it doesn't make sense to
include it in [portable] C; and second, that on platforms which have
a "rotate" opcode to use, any decent optimizer will take care of it
for you. So Paul's "efficiency" argument is bogus.

Tested on DJGPP and Linux gcc for Intel x86 (worked), and gcc for
Solaris 4.something (didn't). I don't know whether the Sun architecture
has 'rotate' or not, but it still compiled to three instructions (with
mnemonics 'srl', 'sll', and 'or').

The details of specific optimizers and machine architectures are obviously
OT here, but it's also pretty clear that gcc -O3 doesn't need any help
from Paul, thankyouverymuch. ;-)

-Arthur

 

[Kevin Easton]

(e-mail address removed) (Greg Comeau) wrote in message

[...] 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;
}

If you can't write it portably, then you're making the point
that a primative rotate instruction is not part of C.
Is that what you're getting at ?

It is portable, in that it gets the same mathematical result anywhere
(well, if I'd used unsigned long, or 16 instead of 32 there). It also
can (and commonly is) optimised down to a single "rotate" machine
instruction, on platforms where that will get the correct mathematical
result (what would be the point of a new operator that *didn't* get the
same result everywhere? It'd be like another signed-right-shift).

- Kevin.

 

[Paul Hsieh]

(e-mail address removed) says...

If you can't write it portably,

[Note that he *could* have made it portable by clever use of UINT_MAX.]

That's not what he's missing. He's missing a couple of "& 31"'s (%32 would be
incorrect since they might output negative numbers.)

then you're making the point
that a primitive rotate instruction is not part of C.
Is that what you're getting at ?

Yes. His point, as I understand it, was two-fold: first, that since
the "rotate" opcode itself is not portable, it doesn't make sense to
include it in [portable] C; and second, that on platforms which have
a "rotate" opcode to use, any decent optimizer will take care of it
for you. So Paul's "efficiency" argument is bogus.

That's not true because ...

Tested on DJGPP and Linux gcc for Intel x86 (worked), and gcc for
Solaris 4.something (didn't).

.... WATCOM, Intel, and Microsoft all fail to do it (I highly doubt that Borland
does it either, but optimization and Borland are oxymorons.) Of course I don't
blame them, the source given does not imply that a rotate instruction is the
necessary output.

The details of specific optimizers and machine architectures are obviously
OT here, but it's also pretty clear that gcc -O3 doesn't need any help
from Paul, thankyouverymuch. ;-)

Gcc's ability to translate undefined code and make it into something useful is
legendary. But even if by some tragedy gcc becomes the defacto standard
compiler that everyone uses, the performance problems will only get *WORSE*,
not better.

 

[Paul Hsieh]

(e-mail address removed) (Greg Comeau) wrote in message
news:<[email protected]>...

[...] 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;
}

If you can't write it portably, then you're making the point
that a primative rotate instruction is not part of C.
Is that what you're getting at ?

It is portable, in that it gets the same mathematical result anywhere
(well, if I'd used unsigned long, or 16 instead of 32 there).

The size is only one of your issues. The C standard does not guarantee
anything about shifting past the size of integer in bits. While you can make
an argument about not needing to shift an integer beyond its size in bits,
that's *NOT* true about rotates.

[...] It also can (and commonly is) [...]

Its not as common as you think.

 

[Chris Torek]

If I want a platform specific rotate then I'll just write:

int rot(int,char);
#pragma aux rot = "rol eax, cl" parm [eax] [cl] value [eax];

thank you very much.

But this does not work at all -- I wanted a 24-bit rotate!

Seriously, has no one yet noticed that "rotate" is inherently a
three-input operation? We have the bit mask to rotate, the number
of bits in that bit mask, and the number of bits by which the rotate
should happen.

Of course, all this "rotate" stuff is a red herring; the *correct*
primitive is "funnel shift", which is a *four*-input operation
(left side, right side, number of bits in each side, and position
of selector). Rotation is obtained by making the left and right
sides identical, and barrel-shifting is obtained by making one of
"left side" or "right side" all-zero-bits.

 

[Chris Dollin]

Seriously, has no one yet noticed that "rotate" is inherently a
three-input operation? We have the bit mask to rotate, the number
of bits in that bit mask, and the number of bits by which the rotate
should happen.

As soon as one wants to implement bignums, one notices this.

Of course, all this "rotate" stuff is a red herring; the *correct*
primitive is "funnel shift", which is a *four*-input operation
(left side, right side, number of bits in each side, and position
of selector). Rotation is obtained by making the left and right
sides identical, and barrel-shifting is obtained by making one of
"left side" or "right side" all-zero-bits.

Could you expand on this? I'm guessing the effect is something like:

(leftSide in numBits bits) concatenate (rightSide in numBits bits)
then extractBits [from selectorPosition width numBits]

?

 

[Kevin Easton]

(e-mail address removed) says...

(e-mail address removed) (Greg Comeau) wrote:
[...] 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;
}

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example. Shift on Intel processors happen to mod the shift value by the
size of the word so it actually works. However, according to the ANSI C
standard, there is no requirement for it to do that. Technically, this code is
not portable.

Well, I didn't state the domain of the function (... m should be in the
range 0 to 31 inclusive for this 32 bit left rotate). Replacing the ms
with (m & 0x1f) and the "unsigned" with "unsigned long" is easy enough,
though, if that's what you want.

But this is just a fluke. shifting beyond the size of the word in bits is not
well defined. So while its *legal* for GCC to output this code, there is no
guarantee that it, or any other compiler (even on machines with 32 bit
integers) will output code which performs a proper 32 bit rotate.

Since the expression, over the domain in which its behaviour *is*
defined, is completely simulated by this platform's hardware rol
instruction, we're entitled to expect that the optimiser should
recognize this. The behaviour of the hardware rol instruction outside
the domain in which the function has defined behaviour is of course of
no importance (to this optimisation).

If I want a platform specific rotate then I'll just write:

int rot(int,char);
#pragma aux rot = "rol eax, cl" parm [eax] [cl] value [eax];

The overarching point being, that if you did have a rotate left bitwise
operator in C (shift-expression |< additive-expression maybe?), then
it's mathematical behaviour would depend entirely on the width of the
type you're working in, which would in practice make it as useless as
signed right shifts.

On the other hand, the next revision of C should certainly include some
vector operations, which can be optimised easily to SIMD instructions on
platforms that have those.

- Kevin.

 

[Ron Natalie]

Odd ... this will not actually rotate the bits correctly. Consider rot(1, 80)
for example

Well, one might argue that rotates of values greater than the number of bits
are undefined behavior just as shifts are in C and C++.