www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - initialization of new'd primitive types

reply tetsuya <tetsuya_member pathlink.com> writes:
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
Oct 22 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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

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

Oct 22 2004
parent reply tetsuya <tetsuya_member pathlink.com> writes:
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
Oct 25 2004
parent tetsuya <tetsuya_member pathlink.com> writes:
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
Oct 25 2004