Thread overview
initialization of new'd primitive types
Oct 22, 2004
tetsuya
Oct 22, 2004
Ivan Senji
Oct 25, 2004
tetsuya
Oct 25, 2004
tetsuya
October 22, 2004
tested on windows XP, dmd 1.04

I don't know if you call it a bug, but i think
this should be implemented to make sense.


since dmd 0.98, one can 'new' primitive types like

int* p = new int;

but cannot at once initialize it just like in c++ way

int* p = new int(5);   // this doesn't work


i believe this should work because, for example,
one may sometimes wish to program like this:

<code>
uint fact(uint n, inout uint a = *(new uint(1))) // wants a to be 1, but a is 0
in the current dmd
{
if (n <= 1) return a;
else
{
a *= n;
return fact(n - 1, a);
}
}
</code>

although the following same kind code works fine:

<code>
typedef uint UINT = 1u;
uint fact(uint n, inout uint a = *(new UINT))
{
if (n <= 1) return a;
else
{
a *= n;
return fact(n - 1, a);
}
}
</code>


tetsuya


October 22, 2004
"tetsuya" <tetsuya_member@pathlink.com> wrote in message news:clb7e0$7eg$1@digitaldaemon.com...
> tested on windows XP, dmd 1.04
>
> I don't know if you call it a bug, but i think
> this should be implemented to make sense.
>
>
> since dmd 0.98, one can 'new' primitive types like
>
> int* p = new int;
>
> but cannot at once initialize it just like in c++ way
>
> int* p = new int(5);   // this doesn't work
>
>
> i believe this should work because, for example,

I agree with this 100%.

> one may sometimes wish to program like this:
>
> <code>
> uint fact(uint n, inout uint a = *(new uint(1))) // wants a to be 1, but a
is 0

But i don't see a benefit this code has over:
uint fact(uint n, inout uint a = 1)

?

> ...


October 25, 2004
In article <clbv0n$12td$1@digitaldaemon.com>, Ivan Senji says...
(snip)
>But i don't see a benefit this code has over:
>uint fact(uint n, inout uint a = 1)
>
>?
>
>> ...
>
>

uint fact(uint n, inout uint a = 1)...

won't be successfully compiled, dmd says:

cast(uint)(1) is not an lvalue

that is, inout & out arguments have to be
"a variable on the real memory" because it requires
a space to indirectly return its value.

i was thinking that the idea could complement inout & out expressions to be sufficiently comparable to the pointer argument in C/C++, for example, null-initial pointer argument in C++ could also be replaced with inout & out expressions even if the argument type is primitive or a structure, i.e. not a reference.

but i guess making the lines like the one you wrote correct is also a good idea :)

tetsuya


October 25, 2004
In article <cljtm0$bu9$1@digitaldaemon.com>, i said...
>
>
>i was thinking that the idea could complement inout & out expressions to be sufficiently comparable to the pointer argument in C/C++, for example, null-initial pointer argument in C++ could also be replaced with inout & out expressions even if the argument type is primitive or a structure, i.e. not a reference.
>

more descriptively,
a C++ function declaration

class Foo;
void bar(Foo* foo = 0);
// btw, 0 is the preferred way to express NULL in C++

is to be replaced in D way by

class Foo;
void bar(Foo foo = null);


and, another C++ function like

void foo(int& n);

is to be replaced in D way by

void foo(inout int n);


but, the following C++ pointer function

void foo(int* n = 0);

cannot be replaced in D way because

void foo(inout int n = /* what should come here?? */);


tetsuya