Rajiv Bhagwat wrote in message <9lte82$2297$1@digitaldaemon.com>...
>Also, no one has commented about the use of macros to init data structures as presented in the second part. Maybe the use is not common enough. Oh, I think MFC does something similar all the time to declare the message map data structures.


I use macros to initialize data structures in C all the time. That's why D has specifiable defaults for member initializers, and named initializers for structs.

Walter wrote:
> 
> Russell Bornschlegel wrote in message <3B814102.B41B493E@estarcion.com>...
> >I don't see the above example as being any uglier than the traditional argc/argv mess.
> 
> The D way of doing command lines:
> 
>     import stdio;
> 
>     int main(char[][] args)
>     {
>         for (int i = 0; i < args.length; i++)
>         {
>             printf("Argument %d = '%.*s'\n", i, args[i]);
>         }
>     }
> 
> The .*s is a hack to get C printf to print D strings that don't have a terminating 0. The char[][] is an array of strings.

Hm, I don't know what you have in mind for the internal representation of a string, but I'd recommend allocating one more character than the length of the string and keeping it zero-terminated, even if you're tracking the length separately -- it could save a lot of trouble in compatibility. Is it out of the question to support an automatic conversion from D strings to zero-terminated (w)char* in parameter lists of functions declared with C calling conventions?

-RB

Russell Bornschlegel wrote in message <3B828FB7.9821FE49@estarcion.com>...
>Walter wrote:
>> Russell Bornschlegel wrote in message
<3B814102.B41B493E@estarcion.com>...
>> >I don't see the above example as being any uglier than the traditional argc/argv mess.
>>
>> The D way of doing command lines:
>>
>>     import stdio;
>>
>>     int main(char[][] args)
>>     {
>>         for (int i = 0; i < args.length; i++)
>>         {
>>             printf("Argument %d = '%.*s'\n", i, args[i]);
>>         }
>>     }
>>
>> The .*s is a hack to get C printf to print D strings that don't have a terminating 0. The char[][] is an array of strings.
>
>Hm, I don't know what you have in mind for the internal representation of a string, but I'd recommend allocating one more character than the length of the string and keeping it zero-terminated, even if you're tracking the length separately -- it could save a lot of trouble in compatibility. Is it out of the question to support an automatic conversion from D strings to zero-terminated (w)char* in parameter lists of functions declared with C calling conventions?


Arrays are implemented as:

    int length;
    void *data;

There is a (char*) cast supported. I toyed with the idea of always making them 0 terminated anyway, but it would up requiring lots of array copying.

Richard Krehbiel a écrit :

> I personally have wished for *more* macro processing power.
>

I agree.

The most powerfull macros i know are MASM assembly langage macro. I used it two much in my young time but it is very very powerfull.

well i can understand it is not really what walter have in mind creating a simpler and safer langage..

Congratulations

Roland

In article <9lgk0b$243j$1@digitaldaemon.com>, "Richard Krehbiel" <rich@kastle.com> wrote:

> Okay, why is it that everybody thinks the C preprocessor is terrible and needs to be avoided?  C++ only has it for compatability; Java and C# and D don't have one.  I just don't get this one.
> 
> I personally have wished for *more* macro processing power.
> 
> Not for typedefs.  Not for constant definitions.  Not for #include files or guards.  For *macros*.

Here is an example of a use of macros which I don't think has been mentioned here or in the spec.  (If it did, I missed it, anyway.)

Suppose you want a macro which uses a variable local to the function in which you call it.  You can do this in D by simply defining a function and passing the variable as a parameter (as suggested in the spec).

E.g.:

int X(int i) { return i + i / 3; }

int my_function(int v)  {
    return X(v) * X(v);
}


For some reason you don't want to pass the parameter each time -- perhaps because you want to use several parameters and the macro will be called lots of times.  This can be solved by using nested functions.  (I'm not sure whether D supports these.)

E.g.:

void my_function(int v, int w)  {
    int X() {return v + w/3; }

    return X() * X();
}


Now suppose you have several functions which each want to call the nested function.  You could redefine the nested function each time, but this would duplicate effort and might make errors more likely.  Perhaps there should be a macro construct, similar to that of functions, which can only be called within a function (and where the variable names used in the macro must be in scope wherever the macro is used).

E.g.:

int w = 24;

macro int X() {return v + w/3;}

int my_function(int v) {
    return X() * X();
}

int another_function() {
    int v;
    return X();
}

int yuk() {
    return X();    /* This isn't allowed because
                                        there is no v in scope.*/
}

This is a reasonably common use of macros, and one of their powers.  Of course, it is arguably a Bad Thing because it could be used unwisely, but it would also be handy.

Do you think this would be useful in the language?  If not, then the example should probably be added to the spec with an explanation.

What about if the macro has side-effects, e.g.:

macro int X() {v++;  return v + w/3;}

In article <9lgk0b$243j$1@digitaldaemon.com>, "Richard Krehbiel" <rich@kastle.com> wrote:

> Okay, why is it that everybody thinks the C preprocessor is terrible and needs to be avoided?  C++ only has it for compatability; Java and C# and D don't have one.  I just don't get this one.
> 
> I personally have wished for *more* macro processing power.
> 
> Not for typedefs.  Not for constant definitions.  Not for #include files or guards.  For *macros*.

Another thing:  This is what the spec says about inlining macros/lightweight functions:

    8. Macros as lightweight inline functions:
        #define X(i)    ((i) = (i) / 3)
               In D:
        int X(int i) { return i = i / 3; }
               The compiler optimizer will inline it; no efficiency is
       lost.

What happens if the macro is in another package or module?

Say X() is defined in module A.  I write module B which includes/imports
module A; a function F() in module B calls X().

If you do this in C, the function X() will be expanded and hence inlined
(from the header file) in the function F().  What happens in D?

It still gets inlined. The function body gets imported along with its declaration. -Walter

Ben Cohen wrote in message <9p1eei$1k5t$1@digitaldaemon.com>...
>In article <9lgk0b$243j$1@digitaldaemon.com>, "Richard Krehbiel" <rich@kastle.com> wrote:
>
>> Okay, why is it that everybody thinks the C preprocessor is terrible and needs to be avoided?  C++ only has it for compatability; Java and C# and D don't have one.  I just don't get this one.
>>
>> I personally have wished for *more* macro processing power.
>>
>> Not for typedefs.  Not for constant definitions.  Not for #include files or guards.  For *macros*.
>
>Another thing:  This is what the spec says about inlining macros/lightweight functions:
>
>    8. Macros as lightweight inline functions:
>        #define X(i)    ((i) = (i) / 3)
>               In D:
>        int X(int i) { return i = i / 3; }
>               The compiler optimizer will inline it; no efficiency is
>       lost.
>
>What happens if the macro is in another package or module?
>
>Say X() is defined in module A.  I write module B which includes/imports
>module A; a function F() in module B calls X().
>
>If you do this in C, the function X() will be expanded and hence inlined
>(from the header file) in the function F().  What happens in D?

"Tim Sweeney" <tim@epicgames.com> wrote in message news:9lkf0r$2nh0$1@digitaldaemon.com...

> 2. To comment out large blocks of code.  Would be unnecessary if /*...*/ comments could be nested.

Yeah... why on earth did they ever decide that /* */ comments shouldn't
nest?
Since we may end up having to block comment out huge chunks of code since
conditional compilation will require grammatically correct code, if your
code isn't (yet) grammatically correct, you can't even get rid of it.  If it
contains any C block comments, you can't even comment it out properly.  So
I'd have to vote for nesting of C block comments.

Sean

"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B81647C.25270C5A@estarcion.com...
> Eeek!
>
> I'm gonna say it one more time: the One True Way to comment out large blocks of code is with // at the beginning of the line. You can even tag and nest these:
>...
> If your editor (or hard copy) isn't syntax-highlighted, this is also clearer than commenting out a large block with /* ... */.
>
> -Russell B

If your editor supports syntax highlighting, there isn't a problem with /* */ style comments.

Sean

> If your editor supports syntax highlighting, there isn't a problem with /* */ style comments.

first /* */ comments are not nestable in normal C, are very bad attribute. If you make them nestable it's still not easy to see where a comment really ends.

second I've no idea why the original C authors thought that /* is an
available token sequence, whats with devided by content of?
a = b/*c;   // that should be a valid operation.

- Axel
-- 
|D) http://www.dtone.org