Jump to page: 1 2
Thread overview
Interesting GCC extensions
Sep 28, 2009
bearophile
Sep 28, 2009
bearophile
Sep 28, 2009
language_fan
Sep 28, 2009
Lutger
Sep 28, 2009
bearophile
Sep 28, 2009
Lutger
Sep 28, 2009
Lutger
Sep 28, 2009
Adam D. Ruppe
Sep 28, 2009
bearophile
Sep 28, 2009
Adam D. Ruppe
Sep 29, 2009
Rainer Deyke
Sep 29, 2009
Adam D. Ruppe
Half-open versus closed ranges, was Re: Interesting GCC extensions
Sep 29, 2009
Rainer Deyke
September 28, 2009
Beside the known ones, like computed gotos and __builtin_expect(), GCC has other less known extensions, you can find some of them here:
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/

They are used by Linux. If D wants to be a system language, such small things may be useful if you want to build a kernel with D.

One of them is the Range extension, it seems GCC devs think that 3 points are better after all:

	switch (major_idx) {
	case 0:
		return SCSI_DISK0_MAJOR;
	case 1 ... 7:
		return SCSI_DISK1_MAJOR + major_idx - 1;
	case 8 ... 15:
		return SCSI_DISK8_MAJOR + major_idx - 8;
	default:
		BUG();
		return 0;
	}


Triple points can be used for initializations too:
int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };


The __builtin_return_address() looks interesting, but I don't understand where it can be useful.


The Constant detection done with __builtin_constant_p(exp) is what I was asking for in one of my recent posts here. It seems I was "right" again.


The article also shows some of the function attributes, in truth in GCC there are many other of such attributes. Some of them are useful for D too.

The good thing of adding some of those things to D is that they can be put in the specs, so they don't become nonstandard extensions as in GCC, this avoids several troubles.

Bye,
bearophile
September 28, 2009
On Mon, Sep 28, 2009 at 12:35 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Beside the known ones, like computed gotos and __builtin_expect(), GCC has other less known extensions, you can find some of them here:
> http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
>
> They are used by Linux. If D wants to be a system language, such small things may be useful if you want to build a kernel with D.
>
> One of them is the Range extension, it seems GCC devs think that 3 points are better after all:
>
>        switch (major_idx) {
>        case 0:
>                return SCSI_DISK0_MAJOR;
>        case 1 ... 7:
>                return SCSI_DISK1_MAJOR + major_idx - 1;
>        case 8 ... 15:
>                return SCSI_DISK8_MAJOR + major_idx - 8;
>        default:
>                BUG();
>                return 0;
>        }
>
>
> Triple points can be used for initializations too:
> int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
>
>
> The __builtin_return_address() looks interesting, but I don't understand where it can be useful.
>
>
> The Constant detection done with __builtin_constant_p(exp) is what I was asking for in one of my recent posts here. It seems I was "right" again.
>
>
> The article also shows some of the function attributes, in truth in GCC there are many other of such attributes. Some of them are useful for D too.
>
> The good thing of adding some of those things to D is that they can be put in the specs, so they don't become nonstandard extensions as in GCC, this avoids several troubles.

I think it's kind of silly that you constantly whine to Walter whenever he adds new features saying "why don't we fix the problems that already exist in D like the module system," and then turn around suggesting we add a bunch of features.

Which do you want? Do you want new features, or do you want things to be fixed?
September 28, 2009
Jarrett Billingsley:

>Which do you want? Do you want new features, or do you want things to be fixed?<

The ideas shown in that post are low priority, so they can wait. But things can be planned for the future too, you can start thinking/planning about them even years before they are implemented (see vector operations of D).
(The triple point syntax is probably out of time).

Bye,
bearophile
September 28, 2009
bearophile wrote:

> Beside the known ones, like computed gotos and __builtin_expect(), GCC has other less known extensions, you can find some of them here: http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
> 
> They are used by Linux. If D wants to be a system language, such small things may be useful if you want to build a kernel with D.
> 
> One of them is the Range extension, it seems GCC devs think that 3 points are better after all:
> 
> switch (major_idx) {
> case 0:
> return SCSI_DISK0_MAJOR;
> case 1 ... 7:
> return SCSI_DISK1_MAJOR + major_idx - 1;
> case 8 ... 15:
> return SCSI_DISK8_MAJOR + major_idx - 8;
> default:
> BUG();
> return 0;
> }
> 
> 
> Triple points can be used for initializations too:
> int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };

That's cool, but the triple point syntax was shot down by Andrei on grounds of it complicating the parsing iirc. D already has .., I don't remember this being in C++.

> 
> The __builtin_return_address() looks interesting, but I don't understand
> where it can be useful.
> 
> 
> The Constant detection done with __builtin_constant_p(exp) is what I was asking for in one of my recent posts here. It seems I was "right" again.

We don't need an extension for this! Look:

template Eval(string exp)
{
    enum Eval = mixin(exp);
}

template IsConstant(string exp)
{
    enum IsConstant = __traits(compiles, Eval!exp);
}

> 
> The article also shows some of the function attributes, in truth in GCC there are many other of such attributes. Some of them are useful for D too.
> 
> The good thing of adding some of those things to D is that they can be put in the specs, so they don't become nonstandard extensions as in GCC, this avoids several troubles.
> 
> Bye,
> bearophile

I think most of the stuff that could be in the spec is covered by __traits. __traits is also easily extended without breaking anything else. Some things mentioned in the article are very implementation specific though.

September 28, 2009
On Mon, 28 Sep 2009 12:58:57 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Jarrett Billingsley:
>
>> Which do you want? Do you want new features, or do you want things to be fixed?<
>
> The ideas shown in that post are low priority, so they can wait. But things can be planned for the future too, you can start thinking/planning about them even years before they are implemented (see vector operations of D).
> (The triple point syntax is probably out of time).

Just so you know.  In 5 months, (i.e. the future) nobody is going to remember that you posted this.  I've noticed you replied to many a thread with "well, that's exactly what I suggested X months ago, but nobody listened to me."  When you make 2 posts a week suggesting changes, you can't expect them all to be considered, most are lost in the noise.

If you want something to be considered to be an enhancement, go through the proper channel -- bugzilla.  Then it won't get lost.

Mark it as an enhancement if necessary.

-Steve
September 28, 2009
On Mon, Sep 28, 2009 at 1:27 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Mon, 28 Sep 2009 12:58:57 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Jarrett Billingsley:
>>
>>> Which do you want? Do you want new features, or do you want things to be fixed?<
>>
>> The ideas shown in that post are low priority, so they can wait. But
>> things can be planned for the future too, you can start thinking/planning
>> about them even years before they are implemented (see vector operations of
>> D).
>> (The triple point syntax is probably out of time).
>
> Just so you know.  In 5 months, (i.e. the future) nobody is going to remember that you posted this.  I've noticed you replied to many a thread with "well, that's exactly what I suggested X months ago, but nobody listened to me."  When you make 2 posts a week suggesting changes, you can't expect them all to be considered, most are lost in the noise.
>
> If you want something to be considered to be an enhancement, go through the proper channel -- bugzilla.  Then it won't get lost.
>
> Mark it as an enhancement if necessary.

Hahahahaha.  Hahahahahaha!

You really think he's gonna do it? He won't. He won't even explain *why* he won't.
September 28, 2009
On Mon, Sep 28, 2009 at 12:35:05PM -0400, bearophile wrote:
> Beside the known ones, like computed gotos and __builtin_expect(), GCC has other less known extensions, you can find some of them here:
> http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/

I remember this page... did you post it here many months ago?

Anyway:

# define __must_check            __attribute__((warn_unused_result))

That one looks kinda cool, though is mostly redundant since we have throw exceptions.

> One of them is the Range extension, it seems GCC devs think that 3 points are better after all:

They are fools. What D has kicks ass. I actually used the case .. case in a program and it was just fantastic.

> Triple points can be used for initializations too:
> int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };

D's slicing can already do this I believe.

> The Constant detection done with __builtin_constant_p(exp) is what I was asking for in one of my recent posts here. It seems I was "right" again.

Aye, that is cool. We should try to get some traits code together and make a std.reflection or something to do this stuff.


-- 
Adam D. Ruppe
http://arsdnet.net
September 28, 2009
Adam D. Ruppe:
> > Triple points can be used for initializations too:
> > int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
> 
> D's slicing can already do this I believe.

How?

Bye,
bearophile
September 28, 2009
Lutger:

> We don't need an extension for this! Look:
> 
> template Eval(string exp)
> {
>     enum Eval = mixin(exp);
> }
> 
> template IsConstant(string exp)
> {
>     enum IsConstant = __traits(compiles, Eval!exp);
> }


From what I see I think your code is useless for my purposes:

// D2 code
import std.stdio: writeln;

template Eval(string exp) {
    enum Eval = mixin(exp);
}

template IsConstant(string exp) {
    enum IsConstant = __traits(compiles, Eval!exp);
}

template Tuple(T...) { alias T Tuple; }

template Range(int stop) {
    static if (stop <= 0)
        alias Tuple!() Range;
    else
        alias Tuple!(Range!(stop-1), stop-1) Range;
}

long ipow(long x, int n) {
    long result = 1;

    static if (IsConstant!("n")) {
        pragma(msg, "constant");
        static if (n < 5) {
            foreach (i; Range!(n))
                result *= x;
        } else {
            for (int i; i < n; i++)
                result *= x;
        }
    } else {
        pragma(msg, "not constant");
        for (int i; i < n; i++)
            result *= x;
    }

    return result;
}

enum int w = 5;
void main() {
    int x = 2;
    const int y = 3;
    enum int z = 4;
    writeln(IsConstant!("x"), " ", IsConstant!("y"),
            " ", IsConstant!("z"), " ", IsConstant!("w"));
    // prints: false false false true

    ipow(10, x);
    ipow(10, y);
    ipow(10, z);
}

Even "z" is seen as not constant?

Bye,
bearophile
September 28, 2009
On Mon, Sep 28, 2009 at 03:45:16PM -0400, bearophile wrote:
> Adam D. Ruppe:
> > > Triple points can be used for initializations too:
> > > int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
> > 
> > D's slicing can already do this I believe.
> 
> How?

Trying it, I see it doesn't actually work in initialization, but you can do it after the fact easily enough:

	int[101] a;
	a[0..9] = 1;
	a[10..99] = 2;
	a[100] = 3;

Compiles fine on D2 and D1, and it uses memset() to set the array. Not quite the same, but pretty close.


-- 
Adam D. Ruppe
http://arsdnet.net
« First   ‹ Prev
1 2