Re: Why do the WindowsAPI bindings have pragma calls?
On 2011-04-08 21:18, Andrej Mitrovic wrote: Ok so if I compile the Winapi .d modules with my main file, the pragma statement is taken into account and I don't have to manually add the pragma again. But If I use an import switch (dmd -Iwin32\) and a precompiled library, then the pragma statement is skipped. Could this be considered a bug? http://d.puremagic.com/issues/show_bug.cgi?id=2776 -- /Jacob Carlborg
What are delimited strings good for?
Ref http://digitalmars.com/d/2.0/lex.html What are some possible use cases for delimited strings? What is solved by having this in the language?
"optional" func alias template param
Hello,
I need a trick to allow a function template parameter be optional.
The following (reduced case) fails because D wants to call f:
uint f(uint i) { return i; }
struct S (alias func=null) {
enum bool hasFunc = !(func == null);// *** error line ***
}
unittest {
// ok
auto s1 = S!()();
writeln(s1.hasFunc);
// not ok
auto s2 = S!(f)();
writeln(s2.hasFunc);
}
==>
Error: function ___.f (uint i) is not callable using argument types ()
(I consider that a bug due to "f" implicitely meaning "f()" --but this is
another story.)
The following also fails:
// not ok
auto s3 = S1!(&f)();
writeln(s3.hasFunc);
==>
Error: expression & f is not a valid template value argument
Denis
--
_
vita es estrany
spir.wikidot.com
Re: "optional" func alias template param
On 04/10/2011 04:10 PM, spir wrote:
Hello,
I need a trick to allow a function template parameter be optional.
The following (reduced case) fails because D wants to call f:
uint f(uint i) { return i; }
struct S (alias func=null) {
enum bool hasFunc = !(func == null); // *** error line ***
}
unittest {
// ok
auto s1 = S!()();
writeln(s1.hasFunc);
// not ok
auto s2 = S!(f)();
writeln(s2.hasFunc);
}
==>
Error: function ___.f (uint i) is not callable using argument types ()
(I consider that a bug due to "f" implicitely meaning "f()" --but this is
another story.)
The following also fails:
// not ok
auto s3 = S1!(&f)();
writeln(s3.hasFunc);
==>
Error: expression & f is not a valid template value argument
PS: I also cannot pass a typed func:
struct S (uint delegate (uint) func=null) {
enum bool hasFunc = !(func == null);
}
==>
Error: arithmetic/string type expected for value-parameter, not uint
delegate(uint)
--
_
vita es estrany
spir.wikidot.com
Re: "optional" func alias template param
On 04/10/2011 04:10 PM, spir wrote:
Hello,
I need a trick to allow a function template parameter be optional.
The following (reduced case) fails because D wants to call f:
uint f(uint i) { return i; }
struct S (alias func=null) {
enum bool hasFunc = !(func == null); // *** error line ***
}
unittest {
// ok
auto s1 = S!()();
writeln(s1.hasFunc);
// not ok
auto s2 = S!(f)();
writeln(s2.hasFunc);
}
==>
Error: function ___.f (uint i) is not callable using argument types ()
(I consider that a bug due to "f" implicitely meaning "f()" --but this is
another story.)
Found one solution using isCallable! Other tricks welcome...
uint f(uint i) { return i; }
struct S (alias func=null) {
enum bool hasFunc = isCallable!(typeof(func));
}
unittest {
auto s1 = S!()();
writeln(s1.hasFunc);
auto s2 = S!(f)();
writeln(s2.hasFunc);
}
I'd also like to know why pointer cannot be template *alias* parameters, like
in:
auto s2 = S!(&f)();
==>
Error: expression & f is not a valid template value argument
Denis
--
_
vita es estrany
spir.wikidot.com
Re: "optional" func alias template param
On 10/04/2011 15:31, spir wrote: I'd also like to know why pointer cannot be template *alias* parameters, like in: auto s2 = S!(&f)(); ==> Error: expression & f is not a valid template value argument Denis First of all, that error is useless, you should probably report a bug for that (particularly if it doesn't include a line number, I'm not sure if you've omitted that or not). Secondly, alias parameters are used to pass a symbol to a template, &f is not a symbol, it's a pointer to the value held in symbol f. -- Robert http://octarineparrot.com/
Specify bitwidth in D
in C++ we can specify the bitwidth in the declaration. So we can optimaze memory usage. unsigned int x: 30; unsigned int type : 2; How can we do that in D? °Matthias
Re: What are delimited strings good for?
> Ref http://digitalmars.com/d/2.0/lex.html > > What are some possible use cases for delimited strings? > What is solved by having this in the language? It's probably so that you can still use characters that require escaping in the string without having to escape " everywhere. WYSIWYGS don't allow for escaping characters, which can be annoying periodically. Still, delimited strings do seem a bit funny to me, and I don't think that I've ever used them. Presumably, they solved some problem fairly nicely, but the only thing that I can think of is that they still allow for characters that require escaping but don't force you to escape ", which could be very useful in strings with lots of "s and other characters that need escaping. - Jonathan M Davis
Re: Specify bitwidth in D
On 4/10/11 6:41 PM, Matthias Pleh wrote: in C++ we can specify the bitwidth in the declaration. So we can optimaze memory usage. unsigned int x : 30; unsigned int type : 2; How can we do that in D? You can't – if you need packed bit fields, have a look at std.bitmanip. David
Re: Why do the WindowsAPI bindings have pragma calls?
Damn, a two year old patch. Why wasn't this included already? Thanks for letting me know.
Re: What are delimited strings good for?
On 10/04/2011 17:51, Jonathan M Davis wrote: Ref http://digitalmars.com/d/2.0/lex.html What are some possible use cases for delimited strings? What is solved by having this in the language? It's probably so that you can still use characters that require escaping in the string without having to escape " everywhere. WYSIWYGS don't allow for escaping characters, which can be annoying periodically. Still, delimited strings do seem a bit funny to me, and I don't think that I've ever used them. Presumably, they solved some problem fairly nicely, but the only thing that I can think of is that they still allow for characters that require escaping but don't force you to escape ", which could be very useful in strings with lots of "s and other characters that need escaping. - Jonathan M Davis DelimitedString: q" Delimiter WysiwygCharacters MatchingDelimiter " Therefore you can choose you delimiter, which as you say might be " Also it looks like you can't use any escapes, because it says WysiwygCharacters above. and further down: Wysiwyg Strings Wysiwyg quoted strings are enclosed by r" and ". All characters between the r" and " are part of the string except for EndOfLine which is regarded as a single \n character. There are no escape sequences inside r" ": I take that to mean that you can't use escapes in DelimitedStrings, either. This would be quite useful for regex, for example.
Re: What are delimited strings good for?
> On 10/04/2011 17:51, Jonathan M Davis wrote: > >> Ref http://digitalmars.com/d/2.0/lex.html > >> > >> What are some possible use cases for delimited strings? > >> What is solved by having this in the language? > > > > It's probably so that you can still use characters that require escaping > > in the string without having to escape " everywhere. WYSIWYGS don't > > allow for escaping characters, which can be annoying periodically. > > Still, delimited strings do seem a bit funny to me, and I don't think > > that I've ever used them. Presumably, they solved some problem fairly > > nicely, but the only thing that I can think of is that they still allow > > for characters that require escaping but don't force you to escape ", > > which could be very useful in strings with lots of "s and other > > characters that need escaping. > > > > - Jonathan M Davis > > DelimitedString: > q" Delimiter WysiwygCharacters MatchingDelimiter " > > Therefore you can choose you delimiter, which as you say might be " Also > it looks like you can't use any escapes, because it says > WysiwygCharacters above. > > and further down: > > Wysiwyg Strings > > Wysiwyg quoted strings are enclosed by r" and ". All characters between > the r" and " are part of the string except for EndOfLine which is > regarded as a single \n character. There are no escape sequences inside > r" ": > > I take that to mean that you can't use escapes in DelimitedStrings, either. > > This would be quite useful for regex, for example. I didn't read carefully enough then. I thought that delimited strings allowed for escaped characters. If they don't, then I really don't understand why they exist. WYSIWYG strings already do that for you. All you have to do is use backticks instead of double quotes. Maybe backticks aren't on all types of keyboards? If so, that might explain the addition, but other than that, the only thing that I can think of is if you want a WYSIWYG string with lots of backticks in it. - Jonathan M Davis
Up to date documentation..?
Seems the documentation is lagging a bit behind.. It will be frustrating to rely on features that will be removed / vastly changed in the future. Not quite sure I can trust the wiki.. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel This is under "pending decision", but it's marked with a specific version. * [DMD 2.051] toString() needs to be improved (Eg, change signature to void toString(void delegate(const char[] s) put, const char[] formatstr)) The changelog doesn't mention anything though. Is my best bet to buy Andrei's book and learn from there? Not touching any features he doesn't mention?
Re: What are delimited strings good for?
Are we forgetting the fact that using delimited strings allows us to
have syntax highlighting in editors?
E.g.:
void stringParser(string str)()
{
mixin(str);
}
void main()
{
stringParser!(q{
int x = 1;
int y = 2;
writefln("%s %s", x, y);
});
}
This is a huge benefit over having everything highlighted in one solid
color as a string.
Re: What are delimited strings good for?
On 10.04.2011 21:17, Andrej Mitrovic wrote:
Are we forgetting the fact that using delimited strings allows us to
have syntax highlighting in editors?
E.g.:
void stringParser(string str)()
{
mixin(str);
}
void main()
{
stringParser!(q{
int x = 1;
int y = 2;
writefln("%s %s", x, y);
});
}
This is a huge benefit over having everything highlighted in one solid
color as a string.
That's token strings. This is delimited strings:
q"(foo(xxx))" // "foo(xxx)"
q"[foo{]" // "foo{"
Re: Up to date documentation..?
On Sun, 10 Apr 2011 21:04:04 +0200, simendsjo wrote: > Seems the documentation is lagging a bit behind.. It will be frustrating > to rely on features that will be removed / vastly changed in the future. > > Not quite sure I can trust the wiki.. > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel > > This is under "pending decision", but it's marked with a specific > version. * [DMD 2.051] toString() needs to be improved (Eg, change > signature to void toString(void delegate(const char[] s) put, const > char[] formatstr)) > > The changelog doesn't mention anything though. > > Is my best bet to buy Andrei's book and learn from there? Not touching > any features he doesn't mention? Well TDPL does have errors in itself. So while the Wiki may be wrong, it will at least give you the items that are changes and might be changing. I'm unsure why Don tagged that line, but I think the idea was approved and maybe it just didn't making in.
Re: Up to date documentation..?
On 10.04.2011 21:31, Jesse Phillips wrote: On Sun, 10 Apr 2011 21:04:04 +0200, simendsjo wrote: Seems the documentation is lagging a bit behind.. It will be frustrating to rely on features that will be removed / vastly changed in the future. Not quite sure I can trust the wiki.. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel This is under "pending decision", but it's marked with a specific version. * [DMD 2.051] toString() needs to be improved (Eg, change signature to void toString(void delegate(const char[] s) put, const char[] formatstr)) The changelog doesn't mention anything though. Is my best bet to buy Andrei's book and learn from there? Not touching any features he doesn't mention? Well TDPL does have errors in itself. So while the Wiki may be wrong, it will at least give you the items that are changes and might be changing. I'm unsure why Don tagged that line, but I think the idea was approved and maybe it just didn't making in. I've stumbled upon several documentation and implementation issues already. Guess tdpl also uses half-implemented features. But the documentation at digitalmars together with that wiki page should give enough info deprecated and unimplemented features?
Re: What are delimited strings good for?
Hmm.. Well then, those I've never seen used before. :)
Re: Up to date documentation..?
> On 10.04.2011 21:31, Jesse Phillips wrote: > > On Sun, 10 Apr 2011 21:04:04 +0200, simendsjo wrote: > >> Seems the documentation is lagging a bit behind.. It will be frustrating > >> to rely on features that will be removed / vastly changed in the future. > >> > >> Not quite sure I can trust the wiki.. > >> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel > >> > >> This is under "pending decision", but it's marked with a specific > >> version. * [DMD 2.051] toString() needs to be improved (Eg, change > >> signature to void toString(void delegate(const char[] s) put, const > >> char[] formatstr)) > >> > >> The changelog doesn't mention anything though. > >> > >> Is my best bet to buy Andrei's book and learn from there? Not touching > >> any features he doesn't mention? > > > > Well TDPL does have errors in itself. So while the Wiki may be wrong, it > > will at least give you the items that are changes and might be changing. > > > > I'm unsure why Don tagged that line, but I think the idea was approved > > and maybe it just didn't making in. > > I've stumbled upon several documentation and implementation issues > already. Guess tdpl also uses half-implemented features. > > But the documentation at digitalmars together with that wiki page should > give enough info deprecated and unimplemented features? Maybe, but I doubt it. The information on features that are intended to be deprecated and those not fully implemented is generally sparse. For instance, does anywhere in the online docs or wiki mention that scoped classes are going away? It might, but I doubt it. The documentation is generally fairly good, but it's not necessarily going to be up-to-date with regards to recent or likely changes. The developers - Walter included - are generally more concerned with implementing changes and fixing bugs than updating documentation. Fortunately, the language spec is fairly stable now, so there aren't many changes, and most that do happen aren't large, but changes are still happening. TDPL was supposed to be released after everything was finalized, but it couldn't be delayed any further, and it was published before everything in it was fully implemented. It is _mostly_ correct however. The errata can be found here: http://erdani.com/tdpl/errata/index.php?title=Main_Page As for the toString issue, there's a DIP for it: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 As far as I know, it hasn't gone anywhere yet though. There's enough interest in it that I would expect it to happen at some point, but I don't know what it'll take for it to happen. - Jonathan M Davis
Re: What are delimited strings good for?
On 4/10/11 11:03 AM, simendsjo wrote: Ref http://digitalmars.com/d/2.0/lex.html What are some possible use cases for delimited strings? What is solved by having this in the language? Readability. auto s = "This is 'something' that \"could\" have been made easier to read"; auto t = q"[This is 'something' that "could" have been made easier to read]"; (although I don't like that you have to type two chars after the q. In ruby you'd write %q(This is 'something' that "could have been made easier to read) )
Re: Specify bitwidth in D
Am 10.04.2011 18:54, schrieb David Nadlinger: On 4/10/11 6:41 PM, Matthias Pleh wrote: in C++ we can specify the bitwidth in the declaration. So we can optimaze memory usage. unsigned int x : 30; unsigned int type : 2; How can we do that in D? You can't – if you need packed bit fields, have a look at std.bitmanip. David Ah, thanks. That fits! °Matthias
Re: What are delimited strings good for?
> On 4/10/11 11:03 AM, simendsjo wrote: > > Ref http://digitalmars.com/d/2.0/lex.html > > > > What are some possible use cases for delimited strings? > > What is solved by having this in the language? > > Readability. > > auto s = "This is 'something' that \"could\" have been made easier to > read"; > > auto t = q"[This is 'something' that "could" have been made easier to > read]"; > > (although I don't like that you have to type two chars after the q. In > ruby you'd write > > %q(This is 'something' that "could have been made easier to read) > > ) WYSIWYG strings already give you that with everything but backticks. So, other than strings with both backticks and quotes in them, I don't see much point to delimited strings. The string that you gave could have been done with auto t = `This is 'something' that "could" have been made easier to read`; 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. - Jonathan M Davis
Re: What are delimited strings good for?
On 4/10/11 5:51 PM, Jonathan M Davis wrote: On 4/10/11 11:03 AM, simendsjo wrote: Ref http://digitalmars.com/d/2.0/lex.html What are some possible use cases for delimited strings? What is solved by having this in the language? Readability. auto s = "This is 'something' that \"could\" have been made easier to read"; auto t = q"[This is 'something' that "could" have been made easier to read]"; (although I don't like that you have to type two chars after the q. In ruby you'd write %q(This is 'something' that "could have been made easier to read) ) WYSIWYG strings already give you that with everything but backticks. So, other than strings with both backticks and quotes in them, I don't see much point to delimited strings. The string that you gave could have been done with auto t = `This is 'something' that "could" have been made easier to read`; 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. - Jonathan M Davis true
Re: The is expression
On 4/5/11 12:21 PM, enuhtac wrote: […] static if (is(int[10] W : W[V], int V)) what is the essential difference to: static if( is( A!(int, "xxx") T == A!(T, s), string s ) ) This is probably merely a bug, I just stumbled across something similar: http://d.puremagic.com/issues/show_bug.cgi?id=5830 David
Why are unsigned to signed conversions implicit and don't emit a warning?
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 (blame it on my lack of coffee). So when I used code like this:
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;
}
The rgb fields would often end up being -1 (Yes, I know all about how signed vs
unsigned representation works). My fault, yes.
But what really surprises me is that these unsigned to signed conversions
happen implicitly. I didn't even get a warning, even though I have all warning
switches turned on.
I'm pretty sure GCC would complain about this in C code. Visual Studio
certainly complains if I set the appropriate warnings, examples given:
warning C4365: '=' : conversion from 'unsigned int' to 'int', signed/unsigned
mismatch
warning C4365: '=' : conversion from 'unsigned short' to 'short',
signed/unsigned mismatch
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
And I just remembered Tuples can be constructed just like regular structs
(which they are underneath):
RGBTuple GetRGB(COLORREF cref)
{
return RGBTuple(GetRValue(cref), GetGValue(cref), GetBValue(cref));
}
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
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 (blame it on my lack of coffee). 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. > But what really surprises me is that these unsigned to signed conversions > happen implicitly. I didn't even get a warning, even though I have all > warning switches turned on. Add your vote here (I have voted this), a bug report from 07 2006, but Walter doesn't like this warning, and warnings in general too: http://d.puremagic.com/issues/show_bug.cgi?id=259 Bye, bearophile
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
> 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 (blame it on my lack of coffee). > > 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. > > > But what really surprises me is that these unsigned to signed conversions > > happen implicitly. I didn't even get a warning, even though I have all > > warning switches turned on. > > Add your vote here (I have voted this), a bug report from 07 2006, but > Walter doesn't like this warning, and warnings in general too: > http://d.puremagic.com/issues/show_bug.cgi?id=259 Personally, I see _zero_ value in renaming byte, int, etc. to sbyte, sint, etc. It's well-known that they're signed. I don't see how adding an extra s would make that any clearer. Their names are perfectly clear as they are. However, I also would have thought that converting between signed and unsigned values would be just as much of an error as narrowing conversions are - such as assigning an int to a byte. And arguably, assigning either an unsigned value to a signed value or vice versa is _also_ a narrowing conversion. So, I would have thought that it would be an error. Apparently not though. - Jonathan M Davis
static variables for non-constant expressions?
I was wondering why static variables can't have a run-time initializer.
For example this won't compile:
void foo(int input)
{
static x = input;
}
But you can do it manually:
void bar(int input)
{
static bool initted;
static typeof(input) x;
if (!initted) { x = input; initted = true; }
}
It's quite a bit more ugly. You also have to expand this for every new static
variable that you write.
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?
Re: static variables for non-constant expressions?
> I was wondering why static variables can't have a run-time initializer.
>
> For example this won't compile:
> void foo(int input)
> {
> static x = input;
> }
>
> But you can do it manually:
> void bar(int input)
> {
> static bool initted;
> static typeof(input) x;
> if (!initted) { x = input; initted = true; }
> }
>
> It's quite a bit more ugly. You also have to expand this for every new
> static variable that you write.
>
> 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, then you get into dependency problems or risk using
undefined variables. Languages like C++ and Java have problems with that. By
forcing all module level variables, member variables, and static variables (be
they class variables or local variables) to have their initializers be static,
it avoids the order problem completely. In all cases except for local static
variables, you can use the appropriate constructor if you need to do the
initialization at runtime. For static local variables, you'd have to use
another static local variable which indicated whether the first had been
initialized yet or not.
In any case, by forcing all variables other than non-static local variables to
have their direct initializers be determined at compile time avoids dependency
problems which often result in undefined behavior in other languages.
- Jonathan M Davis
Re: How do I iterate over enum members at runtime?
Jesse Phillips writes:
> On Sat, 09 Apr 2011 16:20:06 -0400, Andrej Mitrovic wrote:
>
>> I know there's traits to get strings at compile time, e.g.: auto b = [
>> __traits(allMembers, Metrics) ];
>>
>> but this doesn't help me try out those enum values at runtime. It could
>> almost work if I could use a mixin() in a foreach loop, but that's lucid
>> dreaming.
>>
>> Another alternative might be to create an array out of the enum, but I
>> don't know of any way of doing this.
>
> You have everything you need, just put them all together:
>
> enum Metrics : int
> {
> SM_CXSCREEN = 0,
> SM_CYSCREEN,
> SM_CXVSCROLL,
> SM_CYHSCROLL,
> SM_CYCAPTION,
> SM_CXBORDER,
> }
>
> void foo(int m)
> {
> }
>
> void main()
> {
> foreach (m; __traits(allMembers, Metrics))
> {
> foo(mixin("Metrics." ~ m));
> }
> }
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
--
Dan
Re: Why are unsigned to signed conversions implicit and don't emit a
Jonathan M Davis: > Personally, I see _zero_ value in renaming byte, int, etc. to sbyte, sint, > etc. It's well-known that they're signed. I don't see how adding an extra s > would make that any clearer. Their names are perfectly clear as they are. Discussing this here is probably useless, but: - Unfortunately what's "perfectly clear" for the computer is sometimes bug-prone anyway. - 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. - C# uses sbytes, and ubytes. Enough said. Bye, bearophile
Re: Why do the WindowsAPI bindings have pragma calls?
On 2011-04-10 20:24, Andrej Mitrovic wrote: Damn, a two year old patch. Why wasn't this included already? Thanks for letting me know. There are a lot of those in bugzilla. -- /Jacob Carlborg
