On 4/12/11, Jesse Phillips wrote:
> On Tue, 12 Apr 2011 01:55:24 +0200, Andrej Mitrovic wrote:
>
>> On 4/12/11, Jesse Phillips wrote:
>>> Andrej Mitrovic Wrote:
>>>
%s doesn't stand for string in D.
>>>
>>> Yes it does.
>>
>> I was quoting bearophile's "it should error" post, you know that.
On 12/04/11 07:36, Simon wrote:
On 11/04/2011 22:15, Stewart Gordon wrote:
On 11/04/2011 02:37, Jonathan M Davis wrote:
I don't know the background of how static variables really work, so is
there a good reason why the first function can't work like the one
below
it?
They have to be calculat
On Tue, 12 Apr 2011 01:55:24 +0200, Andrej Mitrovic wrote:
> On 4/12/11, Jesse Phillips wrote:
>> Andrej Mitrovic Wrote:
>>
>>> %s doesn't stand for string in D.
>>
>> Yes it does.
>
> I was quoting bearophile's "it should error" post, you know that.
I do now. Though it still stands for string
Jesse Phillips:
> Two complaints:
>
> fprintf? A leading f is for file.
> %s means format as a string not the type is a string.
Sorry, you are right, I am silly.
Bye,
bearophile
On 4/12/11, Jesse Phillips wrote:
> Andrej Mitrovic Wrote:
>
>> %s doesn't stand for string in D.
>
> Yes it does.
I was quoting bearophile's "it should error" post, you know that.
bearophile Wrote:
> So a solution is to build a fwrite/fwriteln that uses a compile-time string
> for formatting, that performs compile-time tests using the more efficient
> CTFE of DMD 2.053:
>
> int foo, bar;
> fwriteln!"%d %s"(foo, bar); // compile-time error: bar isn't a string!
Two compla
Andrej Mitrovic Wrote:
> %s doesn't stand for string in D.
Yes it does.
> My issue is that the arguments don't get printed out due to missing
> specifiers. That is clearly a bug. But maybe it's not a huge bug since
> it's just printing that is involved.
I think it should do what it use to do w
On 11/04/2011 22:15, Stewart Gordon wrote:
On 11/04/2011 02:37, Jonathan M Davis wrote:
I don't know the background of how static variables really work, so is
there a good reason why the first function can't work like the one below
it?
They have to be calculated at compile time so that orderi
%s doesn't stand for string in D.
My issue is that the arguments don't get printed out due to missing
specifiers. That is clearly a bug. But maybe it's not a huge bug since
it's just printing that is involved.
Andrej Mitrovic:
> I realize runtime checks would be out of the question, but I'm looking for
> compile-time checks when it's possible to do so.
GCC is often able to catch such bugs, but Walter has recently closed my
enhancement request about this :-(
http://d.puremagic.com/issues/show_bug.cgi?
On 11/04/2011 02:37, Jonathan M Davis wrote:
I don't know the background of how static variables really work, so is
there a good reason why the first function can't work like the one below
it?
They have to be calculated at compile time so that ordering doesn't matter. If
the order mattered, th
On 10/04/2011 21:51, Jonathan M Davis wrote:
If that had been `something instead of 'something, _then_ the delimited string
becomes useful, but given how rarely backticks are needed, it does seem rather
odd to have delimited strings just for that. So, I definitely have to wonder
why they exist.
There is a bug here:
import std.stdio;
void main()
{
int index;
writef("The index is", index);
}
Actually I found this bug in some example code:
http://d.puremagic.com/issues/show_bug.cgi?id=5836
writef is missing a format specifier. But it still accepts this code.
Is it possible fo
On 04/11/2011 09:18 PM, bearophile wrote:
spir:
Contracts, like any software tool, do not correctly match all possibly needs.
This is true in general, but this isn't true in this case: here they don't
match a basic need because D DbC misses a significant feature (prestate). If
you take a lo
spir:
> Contracts, like any software tool, do not correctly match all possibly needs.
This is true in general, but this isn't true in this case: here they don't
match a basic need because D DbC misses a significant feature (prestate). If
you take a look at other implementations of DbC in Eiffel
On 04/11/2011 04:36 PM, Magnus Lie Hetland wrote:
I guess I could just use a local variable (guarded by version()) and then have
an assert() near the end of the function. Probably a better solution...
If you mean coding your checking "by habd" inside the func's "normal" body,
this seems to me
On 4/11/11, Dan Olson wrote:
> I'm exploring more and found there is also std.traits.EnumMembers. It's
> a little simpler:
>
> foreach (m; EnumMembers!Metrics))
> {
> foo(m);
> }
>
> And for number of members in enum Metrics
>
> EnumMembers!Metrics.length
>
Nice find, tha
Magnus Lie Hetland:
> Yeah, that's what I've got right now. Just seems odd to need to use
> attributes for this sort of thing. Also, it's rather brittle -- for
> example, if the function (directly or indirectly) calls itself. Then
> two (or more) pairs of in/out blocks will manipulate the same
Kagamin:
> bearophile Wrote:
>
> > - C# uses sbytes, and ubytes. Enough said.
>
> there's no ubyte in C#
> It has byte, and it's unsigned.
>
> http://msdn.microsoft.com/en-us/library/exx3b86w.aspx
I was partially wrong, thank you. If you take a look it has int/unt,
short/ushort, etc, but it d
bearophile Wrote:
> - C# uses sbytes, and ubytes. Enough said.
there's no ubyte in C#
It has byte, and it's unsigned.
http://msdn.microsoft.com/en-us/library/exx3b86w.aspx
On 2011-04-11 16:32:36 +0200, Kai Meyer said:
I don't know if I can speak to the philosophical points here, but you
can put your attribute declarations in a version block, and as long as
the usage of that attribute is only used when that version is used, you
should be fine.
Yeah, that's what
On 04/11/2011 06:05 AM, Magnus Lie Hetland wrote:
I'd like to write a contract for a method to ensure that a given
attribute does not decrease when calling the method. In order to do
that, I need to store the "before" value, and compare it to the after
value.
My first intuition was to declare a
There are some aliases in std.stdint
No reason. Sometimes I find a new feature in D and I like to try it
out in my code in various places, to see how it looks, how it works,
etc. In this case a simple struct would do. :)
I'd like to write a contract for a method to ensure that a given
attribute does not decrease when calling the method. In order to do
that, I need to store the "before" value, and compare it to the after
value.
My first intuition was to declare a variable in the in-block, and then
access that
On 04/11/2011 10:10 AM, SimonM wrote:
On 2011/04/11 09:31 AM, spir wrote:
On 04/11/2011 02:42 AM, bearophile wrote:
I and Don have asked (in Bugzilla and elsewhere) to change the
built-in names into sbyte and ubyte, to avoid the common confusions
between signed and unsigned bytes in D, but Walt
spir:
> I'm trying to understand why people use tuples (outside multiple return
> values
> and variadic typetuples). Why do you prefere the above to:
Tuples are also sortable and printable on default, I think.
Bye,
bearophile
You could try looking at the Juno or DWin projects on dsource.
I've done a bit of COM stuff (both implementing com objects and using others) in
Juno and it worked ok, though unfortunately it needs some changes to get it to
work with the current D2.
I need some insight into how COM objects interoperate with D, as well as
some advice on how to manage them properly.
I've seen posts that IUnknown is treated specialy by the compiler, what
is the nature of this behavior? Does this include any kind of
AddRef/Release behavior integration with
On 2011/04/11 09:31 AM, spir wrote:
On 04/11/2011 02:42 AM, bearophile wrote:
I and Don have asked (in Bugzilla and elsewhere) to change the
built-in names into sbyte and ubyte, to avoid the common confusions
between signed and unsigned bytes in D, but Walter was deaf to this.
I think a good n
On Sun, Apr 10, 2011 at 7:57 PM, Jonathan M Davis wrote:
>> Andrej Mitrovic:
>> > I just had a little bug in my code. In the WindowsAPI, there's this
>> > alias:
>> >
>> > alias ubyte BYTE;
>> >
>> > Unfortunately I didn't check for this, and I erroneously assumed BYTE was
>> > a signed value (bla
On 04/11/2011 06:45 AM, bearophile wrote:
- For me, and for Don and from other people that have had bugs in D caused by this, it
seems they think of "bytes" as unsigned things.
True for me as well. I was very surprised to discover 'byte' is /not/ unsigned
(this was actually the cause of my fi
On 04/11/2011 02:42 AM, bearophile wrote:
I and Don have asked (in Bugzilla and elsewhere) to change the built-in names
into sbyte and ubyte, to avoid the common confusions between signed and
unsigned bytes in D, but Walter was deaf to this.
I think a good naming scheme would be:
* signed
On 04/11/2011 01:47 AM, Andrej Mitrovic wrote:
alias Tuple!(byte, "red", byte, "green", byte, "blue") RGBTuple;
RGBTuple GetRGB(COLORREF cref)
{
RGBTuple rgb;
rgb.red = GetRValue(cref);
rgb.green = GetGValue(cref);
rgb.blue = GetBValue(cref);
return rgb;
}
[O your
34 matches
Mail list logo
