hi!
could you advice me, please, what techniques should be used
while working with D wchar[] and C wchar* (e.g. Windows unicode API named
...W()).
how to pass wchar[] to FuncW(wchar*) and back?
thanks!
Qian Xu wrote:
> Adam Burton wrote:
>> I wouldn't think so, cos LinkSeq!(Apple) does not inherit
>> LinkSeq!(Fruit), they are 2 separate types. However your apples
>> automatically downcast (or up, depending which way you like to draw
>> your diagrams :-) ) so unless you intend to pass the LinkS
Thank you for your prompt replies, that helps a lot. I'll combine both ideas
so I can keep the functions for one variant together. Much appreciated.
On Tue, 07 Apr 2009 00:33:04 +0400, Doctor J wrote:
I'm new to template programming and I have a problem for which I think
it would be a good match, but I'd like to get some advice on how to go
about it.
I have a family of algorithms with the same looping structure, but
different particu
Reply to Doctor,
I'm new to template programming and I have a problem for which I think
it would be a good match, but I'd like to get some advice on how to go
about it.
I have a family of algorithms with the same looping structure, but
different particulars:
state_t st
I'm new to template programming and I have a problem for which I think it would
be a good match, but I'd like to get some advice on how to go about it.
I have a family of algorithms with the same looping structure, but different
particulars:
state_t state ;
for (int i =
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 09:50:35 -0400, Don wrote:
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the
built-in type of i-type?
Regards,
Sam
It's a v
Adam Burton wrote:
I wouldn't think so, cos LinkSeq!(Apple) does not inherit LinkSeq!(Fruit),
they are 2 separate types. However your apples automatically downcast (or
up, depending which way you like to draw your diagrams :-) ) so unless you
intend to pass the LinkSeq!(Apple) into a function
I wouldn't think so, cos LinkSeq!(Apple) does not inherit LinkSeq!(Fruit),
they are 2 separate types. However your apples automatically downcast (or
up, depending which way you like to draw your diagrams :-) ) so unless you
intend to pass the LinkSeq!(Apple) into a function expecting LinkSeq!(F
bearophile wrote:
> A better question can be: "What's the advantage of having a built-in
> imaginary type?" :-)
> You can find an answer here, from page 11:
> http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
> But maybe those ideas aren't much true anymore today.
Why could you not make a struct
Hi All,
can I cast a LinkSeq from inherited type to base type?
code --
class Fruit {}
class Apple: Fruit {}
auto apples = new LinkSeq!(Apple);
apples.append(new Apple);
assert(apples !is null);
assert(apples.length == 1);
On Mon, 06 Apr 2009 09:50:35 -0400, Don wrote:
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the
built-in type of i-type?
Regards,
Sam
It's a very nasty type. It supports
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the
built-in type of i-type?
Regards,
Sam
It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoyi
Steven Schveighoffer wrote:
> On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
>
>> Sam Hu wrote:
>>> Thank you!
>>> Anothe silly question then:What's the disadvantage to have the
>>> built-in type of i-type?
>>> Regards,
>>> Sam
>>
>> It's a very nasty type. It supports *, but isn't closed unde
Is it valid for this to compile:
---
ushort a(ushort b) pure nothrow
{ return b<<10|b; }
---
And for this to not compile:
---
ushort a(ushort b) pure nothrow
{ return b<<10; }
---
?
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in
type of i-type?
Regards,
Sam
It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoying for generic programming.
torhu wrote:
>
> If you mean short-circuit evalutation, I'm pretty sure that's always
> what the compiler does.
Thanks. Somebody posted this link:
http://digitalmars.com/d/1.0/expression.html#OrOrExpression
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in type of
i-type?
Regards,
Sam
It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoying for generic programming.
idouble x = 2i;
x *= x; // oops, this isn't imagina
On 06.04.2009 13:30, Qian Xu wrote:
Hi All,
Is minimal evaluation always enabled in D?
I want to write a function IsNull(), so that I can check the precondition as
follows:
if (isNull(foo) ||
isNull(foo.getBar) ||
isNull(foo.getBar.getBar2)
{
return false;
}
// n
grauzone wrote:
> mport tango.io.Stdout;
>
> void main() {
>
> int v = 55;
> int *pv = &v;
>
> //pv (an int pointer) can be exchanged with v (an int),
> //and it still works
> auto i = pv;
>
> alias typeof(i) T;
> static if (is(T T2 : T2*)) {
> T2 i2 = *i;
> Stdout.formatln("{}", i2);
> } else
>
> if (isNull(foo) ||
> isNull(foo.getBar) ||
> isNull(foo.getBar.getBar2)
> {
> return false;
> }
Update: If minimal evaluation is not always enabled, and foo.getBar is NULL.
I will get a segfault when evaluating foo.getBar.getBar2.
Hi All,
Is minimal evaluation always enabled in D?
I want to write a function IsNull(), so that I can check the precondition as
follows:
if (isNull(foo) ||
isNull(foo.getBar) ||
isNull(foo.getBar.getBar2)
{
return false;
}
// normal code goes here
If an argument is null,
bearophile wrote:
Sam Hu:
Doesn't D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?
The intention is that cfloat, cdouble,... will be deprecated eventually.
I don't think std.complex should be part of Phobo
Sam Hu Wrote:
>What's the disadvantage to have the built-in type of i-type?<
I think the answer is: It's another type added to the language, with its
specific semantics, so it adds a bit of complexity to the language. And most
people today don't seem to use complex types in D1 much, so they thin
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in type of
i-type?
Regards,
Sam
Sam Hu:
> Doesn't D already has the built-in types cfloat, cdouble, creal, ifloat,
> idouble, and ireal?What's the advantage having complex class instead?
Some people have discussed/complained that complex types aren't worth being
built-ins, so the *struct* Complex of std.complex of D2 will rep
Hello everyone!
Doesn't D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?
Thanks and best regards,
Sam
Qian Xu wrote:
grauzone wrote:
Check if the variable is a pointer, and if yes, dereference it:
alias typeof(i) T;
static if (is(T T2 : T2*)) {
T2 i2 = *i;
Format.convert("{}", i2);
} else {
Format.convert("{}", i);
}
Hi again,
I cannot compile this code
What exactly are you doing? What d
grauzone wrote:
>
> Check if the variable is a pointer, and if yes, dereference it:
>
> alias typeof(i) T;
> static if (is(T T2 : T2*)) {
> T2 i2 = *i;
> Format.convert("{}", i2);
> } else {
> Format.convert("{}", i);
> }
Hi again,
I cannot compile this code
29 matches
Mail list logo
