www.digitalmars.com         C & C++   DMDScript  

D - More comments...

reply Peter Curran <pcurran acm.gov> writes:
Here are a few more comments on D:


1. The "->" operator is unnecessary, and IMHO should be discarded.
Replace all uses of it with "." (dot). "->" was necessary in the very
early days of C, when the type system was incomplete. Today it is
unnecessary.


Furthermore, it is an inconvenience in many situations, at least in C. I
have encountered many times where, for example, a structure was declared
statically, and then for some reason, was changed to be dynamically
allocated.  In principle, all that should be required to do this is to
change the declaration "aStruct x" to "aStruct *x," and add the
allocation code. However, this also requires changing all occurrences of
"x.name" to "x->name." This is not just a minor nuisance - it inhibits
refactoring and experimentation and code reuse. The distinction between
structure-dereference and pointer-dereference serves no useful purpose,
IMHO, and should be discarded.


2. IMHO, a major flaw in C, and its successors, is the absence of nested
functions. People who have never worked in languages that support them
always belittle them, but IMHO they are extremely valuable tools.
Obviously, like any tool, they can be abused, but when used effectively
they can greatly simplify and clarify code. Nested functions are simply
about scope. By providing a tool for managing scope more effectively,
they can often eliminate the need for some global variables, or long,
awkward parameter sequences and they can replace uses of macros that are
often used as stand-ins for nested functions. They can eliminate a lot
of code duplication that occurs in C simply because there is no
convenient tool for encapsulating such code.


There is no significant difficulty in compiling nested functions. An
early paper on C claimed that the reason C does not have nested
functions is that it does not support compiling onto the stack. This
was, of course, nonsense. Nested functions are compiled exactly the same
way other functions are compiled. Nesting only affects scope. Nested
functions can only be called from the function in which they are nested,
or other functions nested later in the same function, and nested
functions can access variables that are declared before them in the
function(s) in which they are nested. (Such uses can be viewed as a form
of the "global variable" problem, but because of the limited scope, the
concern is far less serious.)


3. IMHO, the "asm" statement should be eliminated from the language
definition. A language standard of this sort, intended for widespread
use, should not define such a machine- and environment-specific feature.
Obviously any specific compiler could support it as an extension, but it
should not be part of the pure language definition.
Aug 23 2001
next sibling parent Russ Lewis <russ deming-os.org> writes:
Peter Curran wrote:


 Here are a few more comments on D:

 1. The "->" operator is unnecessary, and IMHO should be discarded.
 Replace all uses of it with "." (dot). "->" was necessary in the very
 early days of C, when the type system was incomplete. Today it is
 unnecessary.


Amen.


 2. IMHO, a major flaw in C, and its successors, is the absence of nested
 functions.


Personally, I like this idea.  Just today I was coding something like:

bool func(char *string)
{
    if(special_condition)
        return algorithm(string);

    char *cur;
    for(cur = string; *cur != '\0'; cur++)
        if(algorithm(string))
            return true;

   return false;
};

I had to put algorithm() in a separate function...it would have made a lot
of sense for it to just be defined *inside* the current function.


 3. IMHO, the "asm" statement should be eliminated from the language
 definition. A language standard of this sort, intended for widespread
 use, should not define such a machine- and environment-specific feature.
 Obviously any specific compiler could support it as an extension, but it
 should not be part of the pure language definition.


Not sure what to think here.  My first thought is that asm *should* be part
of the language, or it will not be useful for very low-level stuff like
kernels and such...but maybe asm code should be relegated to special "asm
modules" or some such.
Aug 23 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Peter Curran" <pcurran acm.gov> wrote in message
news:3B857C48.64D774DB acm.gov...

 Here are a few more comments on D:
 1. The "->" operator is unnecessary, and IMHO should be discarded.
 Replace all uses of it with "." (dot). "->" was necessary in the very
 early days of C, when the type system was incomplete. Today it is
 unnecessary.


I agree. It's on its way out.



 2. IMHO, a major flaw in C, and its successors, is the absence of nested
 functions. People who have never worked in languages that support them
 always belittle them, but IMHO they are extremely valuable tools.
 Obviously, like any tool, they can be abused, but when used effectively
 they can greatly simplify and clarify code. Nested functions are simply
 about scope. By providing a tool for managing scope more effectively,
 they can often eliminate the need for some global variables, or long,
 awkward parameter sequences and they can replace uses of macros that are
 often used as stand-ins for nested functions. They can eliminate a lot
 of code duplication that occurs in C simply because there is no
 convenient tool for encapsulating such code.


I like nested functions too, and the reason they're not in the language is
simply time.




 3. IMHO, the "asm" statement should be eliminated from the language
 definition. A language standard of this sort, intended for widespread
 use, should not define such a machine- and environment-specific feature.
 Obviously any specific compiler could support it as an extension, but it
 should not be part of the pure language definition.


Using asm is obviously inherently non-portable, but since D is for systems
apps, those apps will need asm from time to time. I specified the form it
should take primarilly because I detest the way it's done in gcc.

I'll put a fuller answer to this in the FAQ.
Aug 23 2001
next sibling parent reply "Jim Eberle" <jeberle1 my-deja.com> writes:
 3. IMHO, the "asm" statement should be eliminated from the language
 definition. A language standard of this sort, intended for widespread
 use, should not define such a machine- and environment-specific feature.
 Obviously any specific compiler could support it as an extension, but it
 should not be part of the pure language definition.


 Using asm is obviously inherently non-portable, but since D is for systems
 apps, those apps will need asm from time to time. I specified the form it
 should take primarilly because I detest the way it's done in gcc.

 I'll put a fuller answer to this in the FAQ.


This would eliminate the #define brackets:

asm(x86) {
}

asm(ppc) {
}

asm(sparc) {
}

You could then keep your asm blurbs together in the same file, and emit the
right code based on the target hw.

Jim
Aug 23 2001
parent reply "Walter" <walter digitalmars.com> writes:
Jim Eberle wrote in message <9m48up$1t4$1 digitaldaemon.com>...

This would eliminate the #define brackets:
asm(x86) {
}

asm(ppc) {
}

asm(sparc) {
}

You could then keep your asm blurbs together in the same file, and emit the
right code based on the target hw.



That is an interesting idea!
Aug 24 2001
parent reply "Nathan Matthews" <nedthefed nospam.hotmail.com> writes:
Just a little thought, I've used both inline asm and external asm, I have to
say I think external asm with linkage is preferable.

I assume the reasoning for inline asm is speed, but on very small routines
this may actually cause a slowdown.  All registers used must be pushed only
the stack and then popped, people have no idea about what the compiler has
been doing such as instruction pairing, using inline asm forces the compiler
to abandon any optimisation it may have been doing.  You effectively lose
the benefits of 'inlining' in which case why not make it a function call and
write an external asm function thats linked in anyway.

I have a feeling allowing inline asm may lead to an equivalent horrible
mightmare of #ifdefs we have today.

Just a few thoughts.

"Walter" <walter digitalmars.com> wrote in message
news:9m4rfe$1d5c$3 digitaldaemon.com...

 Jim Eberle wrote in message <9m48up$1t4$1 digitaldaemon.com>...

This would eliminate the #define brackets:
asm(x86) {
}

asm(ppc) {
}

asm(sparc) {
}

You could then keep your asm blurbs together in the same file, and emit




the

right code based on the target hw.



 That is an interesting idea!
Aug 24 2001
next sibling parent nicO <nicolas.boulay ifrance.com> writes:
Nathan Matthews a écrit :

 
 Just a little thought, I've used both inline asm and external asm, I have to
 say I think external asm with linkage is preferable.
 
 I assume the reasoning for inline asm is speed, but on very small routines
 this may actually cause a slowdown.  All registers used must be pushed only
 the stack and then popped, people have no idea about what the compiler has


That's not true for gcc, where you just give the register type that you
want to use and gcc manage to find a good register.


 been doing such as instruction pairing, using inline asm forces the compiler
 to abandon any optimisation it may have been doing.  You effectively lose
 the benefits of 'inlining' in which case why not make it a function call and
 write an external asm function thats linked in anyway.
 
 I have a feeling allowing inline asm may lead to an equivalent horrible
 mightmare of #ifdefs we have today.
 
 Just a few thoughts.
 
 "Walter" <walter digitalmars.com> wrote in message
 news:9m4rfe$1d5c$3 digitaldaemon.com...

 Jim Eberle wrote in message <9m48up$1t4$1 digitaldaemon.com>...

This would eliminate the #define brackets:
asm(x86) {
}

asm(ppc) {
}

asm(sparc) {
}

You could then keep your asm blurbs together in the same file, and emit




 the

right code based on the target hw.



 That is an interesting idea!
Aug 24 2001
prev sibling next sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
Nathan Matthews wrote:

 
 Just a little thought, I've used both inline asm and external asm, I have to
 say I think external asm with linkage is preferable.
 
 I assume the reasoning for inline asm is speed, but on very small routines
 this may actually cause a slowdown.  All registers used must be pushed only
 the stack and then popped, people have no idea about what the compiler has
 been doing such as instruction pairing, using inline asm forces the compiler
 to abandon any optimisation it may have been doing.  You effectively lose
 the benefits of 'inlining' in which case why not make it a function call and
 write an external asm function thats linked in anyway.


If you can accomplish your objective any other way, you don't use 
inline asm. However, there are a few idioms I see inline asm used
for:

- Accessing high performance timer/counter registers in the CPU.
Can't be done portably. Calling out to the OS is more of a 
time hit than you want when you're trying to instrument speed-
critical code (like a game's rendering system) to figure out 
where the slowdowns are. 

- Inserting a break instruction in debugging code. Performance 
isn't important here, and many OSes have a DebugBreak() or 
equivalent, but in an embedded system without an OS, you have
to write your own break(). Performance isn't important at 
all in this case, so outline asm is usually okay here, but 
for some reason it's often done inline. 

-Russell B
Aug 24 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
It isn't as bad as that. The DMC inline asm, for example, tracks register
usage, and so doesn't push/pop all the registers. It is also integrated with
the optimizer which means that worst case code isn't always
generated. -Walter

Nathan Matthews wrote in message <9m5dhv$1ohv$1 digitaldaemon.com>...

Just a little thought, I've used both inline asm and external asm, I have


to

say I think external asm with linkage is preferable.

I assume the reasoning for inline asm is speed, but on very small routines
this may actually cause a slowdown.  All registers used must be pushed only
the stack and then popped, people have no idea about what the compiler has
been doing such as instruction pairing, using inline asm forces the


compiler

to abandon any optimisation it may have been doing.  You effectively lose
the benefits of 'inlining' in which case why not make it a function call


and

write an external asm function thats linked in anyway.

I have a feeling allowing inline asm may lead to an equivalent horrible
mightmare of #ifdefs we have today.

Just a few thoughts.

"Walter" <walter digitalmars.com> wrote in message
news:9m4rfe$1d5c$3 digitaldaemon.com...

 Jim Eberle wrote in message <9m48up$1t4$1 digitaldaemon.com>...

This would eliminate the #define brackets:
asm(x86) {
}

asm(ppc) {
}

asm(sparc) {
}

You could then keep your asm blurbs together in the same file, and emit




the

right code based on the target hw.



 That is an interesting idea!
Aug 25 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
Walter wrote:

 
 It isn't as bad as that. The DMC inline asm, for example, tracks register
 usage, and so doesn't push/pop all the registers. It is also integrated with
 the optimizer which means that worst case code isn't always
 generated. -Walter


	btw, what did gcc get wrong?  Just curious.

Dan
Aug 26 2001
parent "Walter" <walter digitalmars.com> writes:
Dan Hursh wrote in message <3B88A6DB.FD1D001D infonet.isl.net>...

Walter wrote:

 It isn't as bad as that. The DMC inline asm, for example, tracks register
 usage, and so doesn't push/pop all the registers. It is also integrated




with

 the optimizer which means that worst case code isn't always
 generated. -Walter


 btw, what did gcc get wrong?  Just curious.



From my brief look at it, gcc doesn't actually implement an inline
assembler. It just collects random strings and blindly passes them to the
assembler.
Aug 26 2001
prev sibling next sibling parent reply "jacob navia" <jacob jacob.remcomp.fr> writes:
 Using asm is obviously inherently non-portable,


What?
X86 assembly is more portable than C :-)

It will run in:
Windows
Linux
Solaris
Be
FreeBSD

And ALL SYSTEMS that use an X86 processor! This includes even the Macintosh
with its emulator.


ASSEMBLY LIVES!
:-)
Aug 24 2001
parent reply "Nathan Matthews" <nedthefed nospam.hotmail.com> writes:
Wrong, depends on what flavour of x86

i386, i486, pentium, pentiumII pentiumIII athlon cyrix etc

There are even subtle differences between 486s and pentiums RTDSC register
for instance,
Even if the processors share the same instruction set the way you optimise
for them may be different, instruction pairing for pipelines etc.

The Pentium has extra instructions than a 486.

These days processors are so complex and compilers so advanced you have to
'really'  know what you are doing to beat the compiler unless you want to
access processor specific functions, (SSE for the Pentium III for example).

"jacob navia" <jacob jacob.remcomp.fr> wrote in message
news:9m5cff$1o6g$1 digitaldaemon.com...

 Using asm is obviously inherently non-portable,


 What?
 X86 assembly is more portable than C :-)

 It will run in:
 Windows
 Linux
 Solaris
 Be
 FreeBSD

 And ALL SYSTEMS that use an X86 processor! This includes even the


Macintosh

 with its emulator.


 ASSEMBLY LIVES!
 :-)
Aug 24 2001
parent nicO <nicolas.boulay ifrance.com> writes:
Nathan Matthews a écrit :

 
 Wrong, depends on what flavour of x86
 
 i386, i486, pentium, pentiumII pentiumIII athlon cyrix etc
 
 There are even subtle differences between 486s and pentiums RTDSC register
 for instance,
 Even if the processors share the same instruction set the way you optimise
 for them may be different, instruction pairing for pipelines etc.
 
 The Pentium has extra instructions than a 486.
 
 These days processors are so complex and compilers so advanced you have to
 'really'  know what you are doing to beat the compiler unless you want to
 access processor specific functions, (SSE for the Pentium III for example).
 


Hum, no in fact beat compiler is very easy ! I have use C to write
integer matrix multiplication (usual 3 loop algorithme compare to a
cpu-specific hand optimise code) my average gain was 4, the best was x25
(yes 25 it's not a typo !) on a 1.2 Ghz Athlon on 512*512 matrix.

I used gcc and in my asm statement, i didn't used any SIMD code (MMX
code for multiplication aren't useful at all), just prefetching.

nicO


 "jacob navia" <jacob jacob.remcomp.fr> wrote in message
 news:9m5cff$1o6g$1 digitaldaemon.com...

 Using asm is obviously inherently non-portable,


 What?
 X86 assembly is more portable than C :-)

 It will run in:
 Windows
 Linux
 Solaris
 Be
 FreeBSD

 And ALL SYSTEMS that use an X86 processor! This includes even the


 Macintosh

 with its emulator.


 ASSEMBLY LIVES!
 :-)
Aug 24 2001
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:

 "Peter Curran" <pcurran acm.gov> wrote in message
 news:3B857C48.64D774DB acm.gov...
 

Here are a few more comments on D:
1. The "->" operator is unnecessary, and IMHO should be discarded.




...

 I agree. It's on its way out.


...

3. IMHO, the "asm" statement should be eliminated from the language


...
 
 Using asm is obviously inherently non-portable, but since D is
 for systems apps, those apps will need asm from time to time. 
 I specified the form it should take primarilly because I detest
  the way it's done in gcc.
 


...
Including an inline asm encourages keeping non-portable code in small 
pieces.  It makes it easier to get back into the language level code. 
Even if there is a small performance penalty, this is well justifiec.
Aug 24 2001
prev sibling next sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
Peter Curran wrote:

 2. IMHO, a major flaw in C, and its successors, is the absence of nested
 functions. [...snip...] Nested functions are simply
 about scope. By providing a tool for managing scope more effectively,
 they can often eliminate the need for some global variables, or long,
 awkward parameter sequences and they can replace uses of macros that are
 often used as stand-ins for nested functions. They can eliminate a lot
 of code duplication that occurs in C simply because there is no
 convenient tool for encapsulating such code.


In C++, the class takes on this kind of encapsulation duty. Not to
say whether one or the other is better, but C++ programmers are 
likely to be more comfortable doing it way they're doing it now. 

Of course, member functions which call other member functions as 
helpers are using the exact same logical concept as nested functions,
just in a different shape.


 3. IMHO, the "asm" statement should be eliminated from the language
 definition. A language standard of this sort, intended for widespread
 use, should not define such a machine- and environment-specific feature.
 Obviously any specific compiler could support it as an extension, but it
 should not be part of the pure language definition.


Not even to the point of reserving the keyword "asm" and suggesting
a semantic for asm blocks? That seems to me to be taking purity a 
little too far. 

-RB
Aug 23 2001
prev sibling next sibling parent reply "John Carney" <john.carney pacific.net.au> writes:
 2. IMHO, a major flaw in C, and its successors, is the absence of nested
 functions. People who have never worked in languages that support them
 always belittle them, but IMHO they are extremely valuable tools.
 Obviously, like any tool, they can be abused, but when used effectively
 they can greatly simplify and clarify code. Nested functions are simply
 about scope. By providing a tool for managing scope more effectively,
 they can often eliminate the need for some global variables, or long,
 awkward parameter sequences and they can replace uses of macros that are
 often used as stand-ins for nested functions. They can eliminate a lot
 of code duplication that occurs in C simply because there is no
 convenient tool for encapsulating such code.


Actually I'd take nested classes over nested functions...

John.
Aug 24 2001
parent "Walter" <walter digitalmars.com> writes:
John Carney wrote in message <9m5khh$1sgl$1 digitaldaemon.com>...

Actually I'd take nested classes over nested functions...



D does have nested classes, but not "inner" classes ala Java.
Aug 24 2001
prev sibling parent "Richard Krehbiel" <rich kastle.com> writes:
"Peter Curran" <pcurran acm.gov> wrote in message
news:3B857C48.64D774DB acm.gov...

 Here are a few more comments on D:


 2. IMHO, a major flaw in C, and its successors, is the absence of nested
 functions.


You can have C with nested functions *today*.  They're a GCC feature.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Aug 24 2001