Conditional compilation for non-release version
Hello all,
I've just been reading through this page: http://dlang.org/version.html
Is there a way to put in place a conditional segment of code that is included if
the code is _not_ compiled with the -release flag?
Of course I can put in a debug statement, but that would require me to compile
with -debug. I'd like the opposite, that unless I explicitly specify the code
as release-ready, the specified set of checks will be performed.
The reason I'm asking is because the checks I want to perform are of the form,
foreach(x; myVeryLargeArray) {
assert(/* ... some condition about x */);
}
... and I'm concerned that with the foreach() loop in place, it will slow down
the code even if the assert() statements are ignored at compile time. So I'd
like to be able to do something instead like,
version(!release)
{
foreach(x; myVeryLargeArray) {
assert(/* ... some condition about x */);
}
}
... is this possible?
Thanks best wishes,
-- Joe
Re: Conditional compilation for non-release version
Joseph Rushton Wakeling:
Is there a way to put in place a conditional segment of code
that is included if the code is _not_ compiled with the
-release flag?
Contract programming? D is designed to make it hard on purpose to
do what you want to do.
The reason I'm asking is because the checks I want to perform
are of the form,
foreach(x; myVeryLargeArray) {
assert(/* ... some condition about x */);
}
... and I'm concerned that with the foreach() loop in place, it
will slow down the code even if the assert() statements are
ignored at compile time. So I'd like to be able to do
something instead like,
version(!release)
{
foreach(x; myVeryLargeArray) {
assert(/* ... some condition about x */);
}
}
... is this possible?
My suggestion is to use a pure helper predicate, possibly nothrow
too (a pure lambda too is OK):
bool isGood(MyType x) pure {
...
}
foreach(x; myVeryLargeArray) {
assert(isGood(x));
}
The purity of the predicate is almost necessary, to be sure your
program behavior doesn't change between release and non-release
mode.
Bye,
bearophile
Re: Passing array as const slows down code?
Joseph Rushton Wakeling: ... because I found I got about a 2s speedup. It's exactly the speedup which was removed by adding const to the function input, so I presume it's as you say, that this was implicitly creating a local copy. I suggest to take a look at the asm in both cases, and compare. Adding const doesn't cause local copies. Bye, bearophile
Re: Conditional compilation for non-release version
On 04/28/2012 02:05 PM, Joseph Rushton Wakeling wrote:
Hello all,
I've just been reading through this page: http://dlang.org/version.html
Is there a way to put in place a conditional segment of code that is
included if the code is _not_ compiled with the -release flag?
Of course I can put in a debug statement, but that would require me to
compile with -debug. I'd like the opposite, that unless I explicitly
specify the code as release-ready, the specified set of checks will be
performed.
The reason I'm asking is because the checks I want to perform are of the
form,
foreach(x; myVeryLargeArray) {
assert(/* ... some condition about x */);
}
... and I'm concerned that with the foreach() loop in place, it will
slow down the code even if the assert() statements are ignored at
compile time. So I'd like to be able to do something instead like,
version(!release)
{
foreach(x; myVeryLargeArray) {
assert(/* ... some condition about x */);
}
}
... is this possible?
Thanks best wishes,
-- Joe
assert({
/* code you want to execute in non-release mode */
return true;
}());
Re: Passing array as const slows down code?
On 28/04/12 14:53, bearophile wrote: I suggest to take a look at the asm in both cases, and compare. Adding const doesn't cause local copies. I'm afraid I have no idea how to do that, or what to look for.
Re: Conditional compilation for non-release version
asserts aren't compiled into release builds (except
assert(false)). So, if the loop only contains asserts, the
compiler *should* be able to strip out the loop altogether. I
don't know if DMD actually does that, though.
Or you could use debug statements:
debug foreach (x; largeArray) {
...
}
you'll need to compile with -debug for the loop to be included.
Re: Conditional compilation for non-release version
On 28/04/12 15:03, F i L wrote: Or you could use debug statements: Yes, that was what I wanted to avoid -- I wanted the tests to be there by default, not only when debugging ... :-) AFAICS the foreach loop probably does get optimized out by the compiler (I'm using GDC); if anything is left, the time it adds is negligible compared to the natural variation in runtime of the program. In the end I decided to play ultra-safe and add assert() statements in every context where the array entries are used. Those extra checks don't actually add anything to the non-release runtime, so far as I can tell.
cannot cast
I finished my Ref/NotNull struct, but i've got a problem:
If i try to cast the class, which should implicit convert to
Ref!(Type) with alias this, i get the following error message:
cannot cast a1.getRef(Ref.d,72u) of type Ref!(A) to type
RefTest.Ref.__unittest1.B
Can someone explain that to me or help me with it?
It seems that alias this replacement isn't smart enough to
distinguish, if it has to convert.
[code]
import std.conv : to;
struct Ref(T : Object) {
private:
T _obj;
public:
@disable
this();// { }
@disable
this(typeof(null));// { }
this(T obj) {
assert(obj !is null, Object is null!);
this._obj = obj;
}
@property
inout(T) access() inout {
assert(this._obj !is null, Access: Object is null!);
return this._obj;
}
//alias access this; // print Stackoverflow or recursive
expansion
}
mixin template TRef(T : Object) {
final Ref!(T) getRef(string file = __FILE__, size_t line =
__LINE__) in {
assert(this !is null, Object is null! @ ~ file ~ in Line
~ to!(string)(line) ~ .);
} body {
return Ref!(T)(this);
}
final Ref!(const T) getRef(string file = __FILE__, size_t line =
__LINE__) const in {
assert(this !is null, Object is null! @ ~ file ~ in Line
~ to!(string)(line) ~ .);
} body {
return Ref!(const T)(this);
}
alias getRef this;
}
unittest {
class A {
mixin TRef!(A);
}
class B : A { }
class C : B { }
A a1 = new B();
A a2 = new C();
B b1 = cast(B) a1; // line 72
}
mysql binding/wrapper?
I guess there are several bindings lingering around. Has anyone experience with any of these? I found the following: https://github.com/britseye/mysqln https://github.com/britseye/mysqld https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/mysql.d http://my.opera.com/run3/blog/2012/03/13/d-mysql https://github.com/D-Programming-Deimos/libmysql - seems empty
Re: cannot cast
On Saturday, 28 April 2012 at 14:21:32 UTC, Namespace wrote:
I finished my Ref/NotNull struct, but i've got a problem:
If i try to cast the class, which should implicit convert to
Ref!(Type) with alias this, i get the following error message:
cannot cast a1.getRef(Ref.d,72u) of type Ref!(A) to type
RefTest.Ref.__unittest1.B
Can someone explain that to me or help me with it?
It seems that alias this replacement isn't smart enough to
distinguish, if it has to convert.
[code]
import std.conv : to;
struct Ref(T : Object) {
private:
T _obj;
public:
@disable
this();// { }
@disable
this(typeof(null));// { }
this(T obj) {
assert(obj !is null, Object is null!);
this._obj = obj;
}
@property
inout(T) access() inout {
assert(this._obj !is null, Access: Object is null!);
return this._obj;
}
//alias access this; // print Stackoverflow or recursive
expansion
}
mixin template TRef(T : Object) {
final Ref!(T) getRef(string file = __FILE__, size_t line =
__LINE__) in {
assert(this !is null, Object is null! @ ~ file ~ in Line
~ to!(string)(line) ~ .);
} body {
return Ref!(T)(this);
}
final Ref!(const T) getRef(string file = __FILE__, size_t line
= __LINE__) const in {
assert(this !is null, Object is null! @ ~ file ~ in Line
~ to!(string)(line) ~ .);
} body {
return Ref!(const T)(this);
}
alias getRef this;
}
unittest {
class A {
mixin TRef!(A);
}
class B : A { }
class C : B { }
A a1 = new B();
A a2 = new C();
B b1 = cast(B) a1; // line 72
}
Trying to fix it with an opCast in Ref ended in an infinity
loop...
Re: mysql binding/wrapper?
On Sat, 28 Apr 2012 17:54:49 +0200, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Saturday, 28 April 2012 at 15:30:13 UTC, simendsjo wrote:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/mysql.d
That's mine. I use it all the time; nothing super fancy, but
it gets the job done for me.
I didn't really document it... but the basic usage is simple:
auto mysql = new MySql(hostname, username, password,
database_name);
int userId = getMyUserId();
foreach(line; mysql.query(SELECT id, name FROM something WHERE user_id
= ?, userId)) {
line[id] == line[0]
line[name] == line[1]
}
The columns are returned as strings. The query returns a simple
range, so you can also check .empty, get .front, etc.
Hmm.. Seems my previous message was lost in the void.
As it resides in this big misc repository, does it have many dependecies?
Would you mind if the module was added to vibe, and thus relicensed to
MIT? No idea if the vibe folks would actually want that though :)
Should I wait for the new edition of TDPL ?
Hi all, Not owning TDPL right now, I feel I could learn the language much more quickly with it. But Andrei hinted somewhere that there would be a new edition of his book. Should I wait for it ?
Re: mysql binding/wrapper?
On Saturday, 28 April 2012 at 16:19:37 UTC, simendsjo wrote: As it resides in this big misc repository, does it have many dependecies? It depends on the database.d module in there too. (database.d provides the base interface and some common functions with other db providers.) That's it though, D wise. It also uses the mysql C library so you'll need libmysql on your system for it to link too. Would you mind if the module was added to vibe, and thus relicensed to MIT? No idea if the vibe folks would actually want that though :) My stuff is all free to take as far as I'm concerned, but since this uses libmysql it might technically be GPL. I don't really know. But if you're ok with that, you can have it.
Re: Should I wait for the new edition of TDPL ?
On Sat, Apr 28, 2012 at 06:27:52PM +0200, SomeDude wrote: Hi all, Not owning TDPL right now, I feel I could learn the language much more quickly with it. But Andrei hinted somewhere that there would be a new edition of his book. Should I wait for it ? I had known of D before I bought TDPL. I had a hard time getting started. OT1H I was attracted by the promising features, but OTOH the online documentation (at the time---and arguably even now) was not very newbie friendly. I wasn't getting the positive feedback from my initial attempts to learn it. So I gave it up. Then one day my wife made me go to a bookstore with her. While there, I offhandedly decided to look for TDPL, on the off-chance that it *might* be in the computer books section. And sure enough, I found it amid all the PHP, Javascript, how-to-build-a-sucky-website books. So I bought it. Finally, here was something that eased me into D syntax, pointed me to features of interest *and how to use them*. That's when I seriously began to write real D code, not just some half-hearted toy code attempt to play around with the language. And what can I say? Now I'm just loving every moment of D. (*cough*except for is() syntax*cough). So it's up to you whether you want to buy the current edition or wait for the next one (with the items in the errata fixed). But having the book will help you learn the language MUCH faster, and use it much more effectively instead of trying to shoehorn C/C++/Java mentality into D code (which often just leads to less-well implemented parts of the language, which leads to bugs/quirks, which leads to frustration with the language). T -- Computers shouldn't beep through the keyhole.
Re: Should I wait for the new edition of TDPL ?
On Sat, 28 Apr 2012 20:20:45 +0200, H. S. Teoh hst...@quickfur.ath.cx wrote: Then one day my wife made me go to a bookstore with her. While there, I offhandedly decided to look for TDPL, on the off-chance that it *might* be in the computer books section. And sure enough, I found it amid all the PHP, Javascript, how-to-build-a-sucky-website books. So I bought it. Having *real* computer books in the book shelf..?! You obviously don't live in Norway :) And it's actually cheaper for me to order the book from Amazon in the US rather than order it in the book-store...
Re: Hacking on Phobos
On Tuesday, 17 April 2012 at 19:28:05 UTC, Joseph Rushton Wakeling wrote: Oddly enough building rdmd with my newly-build dmd results in error: rdmd.d(197): Error: function std.path.rel2abs!().rel2abs is deprecated /usr/local/include/d2/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration /usr/local/include/d2/std/algorithm.d(4184): Error: template std.algorithm.endsWith cannot deduce template function from argument types !(a == b)(string,string,string,string,string) /usr/local/include/d2/std/algorithm.d(4226): Error: template instance endsWith!(a == b) errors instantiating template /usr/local/include/d2/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration /usr/local/include/d2/std/algorithm.d(4184): Error: template std.algorithm.endsWith cannot deduce template function from argument types !(a == b)(string,string,string,string,string) /usr/local/include/d2/std/algorithm.d(4226): Error: template instance endsWith!(a == b) errors instantiating template /usr/local/include/d2/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration /usr/local/include/d2/std/algorithm.d(4184): Error: template std.algorithm.endsWith cannot deduce template function from argument types !(a == b)(string,string,string,string,string) /usr/local/include/d2/std/algorithm.d(4226): Error: template instance endsWith!(a == b) errors instantiating template /usr/local/include/d2/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration /usr/local/include/d2/std/algorithm.d(4184): Error: template std.algorithm.endsWith cannot deduce template function from argument types !(a == b)(string,string,string,string,string) /usr/local/include/d2/std/algorithm.d(4226): Error: template instance endsWith!(a == b) errors instantiating template /usr/local/include/d2/std/algorithm.d(4226): Error: template std.algorithm.endsWith does not match any function template declaration /usr/local/include/d2/std/algorithm.d(4184): Error: template std.algorithm.endsWith cannot deduce template function from argument types !(a == b)(string,string,string,string,string) /usr/local/include/d2/std/algorithm.d(4226): Error: template instance endsWith!(a == b) errors instantiating template The same problem here. Who can help?
Re: Should I wait for the new edition of TDPL ?
On Saturday, 28 April 2012 at 16:27:53 UTC, SomeDude wrote: Hi all, Not owning TDPL right now, I feel I could learn the language much more quickly with it. But Andrei hinted somewhere that there would be a new edition of his book. Should I wait for it ? Andrei mentioned it may be time for a new Printing. This would mean that you won't know if you'd get the newest printing when it was done. I'd say buy it now, I don't know the odds of getting new printings.
Re: Should I wait for the new edition of TDPL ?
On Sat, Apr 28, 2012 at 08:23:54PM +0200, simendsjo wrote: On Sat, 28 Apr 2012 20:20:45 +0200, H. S. Teoh hst...@quickfur.ath.cx wrote: Then one day my wife made me go to a bookstore with her. While there, I offhandedly decided to look for TDPL, on the off-chance that it *might* be in the computer books section. And sure enough, I found it amid all the PHP, Javascript, how-to-build-a-sucky-website books. So I bought it. Having *real* computer books in the book shelf..?! You obviously don't live in Norway :) lol... apparently I don't! I have to say, though, that I very, very, VERY rarely buy computer related books. Before TDPL, the last computer-related book I bought was the Perl camel book. And that was, oh, ... 15 years ago? And it's actually cheaper for me to order the book from Amazon in the US rather than order it in the book-store... To be honest, I rarely find anything of value in my local bookstore's bookshelves. Mostly it's just fiction (novels, comics, and the like), reference books like the 201th edition of the Oxford, maps of outdated places in the world, get-rich-quick-without-doing-work books, and Javascript and PHP books. The fact that TDPL was buried in the midst of that mountain of chaff was probably a miracle in and of itself. T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous
Re: Passing array as const slows down code?
On Saturday, April 28, 2012 13:17:36 Joseph Rushton Wakeling wrote: On 27/04/12 20:26, Steven Schveighoffer wrote: No, it can't. There can easily be another non-const reference to the same data. Pure functions can make more assumptions, based on the types, but it would be a very complex determination in the type system to see if two parameters alias the same data. Real optimization benefits come into play when immutable is there. Question on the const/immutable distinction. Given that my function has inputs of (size_t, size_t, Rating[]), how come the size_t's can be made immutable, but the Rating[] can only be made const/const ref? Is it because the size_t's can't conceivably be changed from outside while the function is running, whereas the values in the array in principle can be? size_t is a value type. Arrays are reference types. So, when you pass a size_t, you get a copy, but when you pass an array, you get a slice of the array. You could make that slice const, but you can't make something immutable, because immutable stuff must _always_ be immutable. If you want an immutable array (or array of immutable elements), you must make a copy. If you call idup on an array, you'll get a copy of that array where each of its elements are immutable. And yes, because size_t is copied, it can't be changed from the outside, whereas because Rating[] is only sliced, it can be. const protects against it being altered within the function (for both of them), but doesn't protect the original array from being modified. immutable, on the other hand, is _always_ immutable and can never be mutated. But because of that, you can't convert something to immutable without making a copy (which happens automatically with value types but must be done explicitly with reference types). - Jonathan M Davis
alias this : cast turns into endless loop
Trying with
U opCast(U : Object)() {
return new U();
}
work fine. It isn't a solution, but i don't understand why this
works and the following not:
U opCast(U : Object)() {
return cast(U) this._obj;
}
I hope really some of you can explain that to me and help me to
fix it.
And forgive me the old senseless thread title. ;)
