On 20.08.2011 12:39, Rainer Schuetze wrote:
Hi,
I recently updated to the latest revision from github and tried to
compile my main project visuald with it. Here are some complications
that have hit me:
1. My Windows SDK conversion tool converts C macros to templates, e.g.
#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
is converted to
auto MAKEINTRESOURCEW(ARG)(ARG i)() { return ( cast(LPWSTR)(
cast(ULONG_PTR)( cast(WORD)(i)))); }
This no longer works for CTFE, because casts to pointers are no longer
allowed. Making the argument a template parameter still works, though:
auto MAKEINTRESOURCEW(int i)() { return ( cast(LPWSTR)(
cast(ULONG_PTR)( cast(WORD)(i)))); }
Also, casting to a pointer is still allowed when initializing a global
variable at compile time.
Is this by design or a regression?
2. std.regexp is deprecated now, which is good, because there is no
reason to have two different implementations of regular expressions.
Unfortunately, std.regex seems to have some problems with rather
simple regular expressions like r"^(.*)\(([0-9]+)\):(.*)$" that is
supposed to match error messages like "file.d(37): huhu". std.regexp
worked for this expression.
That's most likely my fault, since there is a special casing for .* in
std.regex which very well might be at fault here. Honestly, at a certain
point I just gave up on trying to fix current std.regex, apparently a
bit early. A quick test on this would be
r"^([\x00-\x80]*)\(([0-9]+)\):([\x00-\x80]*)$".
Dmitry Olshansky's new std.regex also works, but it does not compile
with warnings enabled (even not with -wi) (
http://d.puremagic.com/issues/show_bug.cgi?id=6518 ).
Btw I thought -wi is supposed to just list it as warning. The
embarrassing part comes from the fact that I actually picked up this
foreach trick from original std.regex.
Maybe it would be better to wait with deprecating std.regexp until
there is a working alternative.
Given this fresh bug in std.regex I'd naturally agree.
3. I tried to remove some more (currently soft) deprecation messages
regarding std.ctype, and it turned out that it was a bit of a hassle
to get it to compile because I had to mix both std.ascii and std.uni.
This is happening because I'd like to use the isAlpha from std.uni,
but there are other functions missing from std.uni (like isDigit,
isHexDigit, etc.).
I think this was discussed before, but I'm not sure what the
conclusion was. I suggest adding some forwarding aliases to std.uni
for function that have identical implementation, and ensure that the
compiler does not complain about ambiguities if these are just aliases
to the same symbol.
Recalling last discussion on this, the users have to solve this on their
own. Be it use unicode everywhere or full std.ascii.xxx/std.uni.xxx or
whatever. I ended up using renamed imports.
Otherwise, it seems the generated executable works fine.
Rainer
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
--
Dmitry Olshansky
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
