View mode: basic / threaded / horizontal-split · Log in · Help
October 22, 2004
initialization of new'd primitive types
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
Re: initialization of new'd primitive types
"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
Re: initialization of new'd primitive types
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
Re: initialization of new'd primitive types
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
Top | Discussion index | About this forum | D home