Re: string vs. w/char*
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
On Tue, 01 Mar 2011 02:08:48 +0300, Tyro[a.c.edwards]
nos...@home.com
wrote:
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
On Mon, 28 Feb 2011 19:35:47 +0300, Tyro[a.c.edwards]
nos...@home.com
wrote:
On 2/28/2011 11:08 PM, J Chapman wrote:
== Quote from Tyro[a.c.edwards] (nos...@home.com)'s article
Both implementations results in error code 1812 being
returned from
GetLastError. explanation of the code reads:
ERROR_RESOURCE_DATA_NOT_FOUND
1812 (0x714)
The specified image file did not contain a resource
section.
The code I'm porting initially consisted of a resource.h
file, a
generic.rc file and two icons. I have not tried to include
the icons
and
generic.rc file in the compilation because I do not know
how
to as yet
and I've only used half of the resource.h file: didn't
think
I need the
whole thing. Could this be the reason for the error? If so
could you
direct me to the explanation of how to prepare these files
for
inclusion
in the compilation process?
Thanks,
Andrew
You need to compile the .rc file (see
http://www.digitalmars.com/ctg/rcc.html), then add the
resulting .res
file
to dmd's command line.
Awesome, this does the trick. However I get get a GP
Fault?
during
execution. Using windbg, I tracked it down to this piece of
code:
void Create()
{
_hwnd = CreateWindowExA(
_exStyle,
cast(const(char*))_wc.GetName(), // returns string
cast(const(char*))_windowName, // string variable
_style,
_x,
_y,
_width,
_height,
_hWndParent,
_hMenu,
_wc.GetInstance(),
_data);
assert(_hwnd, Internal error: Window Creation
Failed.);
}
The program craps at assert() but the error is generated. It
just
displays a dialog box with the message: test.exe has
stopped
working,
Windows is checking for a solution to the problem...
I'm thinking that _hwnd was never initialized and that
assert
is access
a null pointer but I cannot be sure. Any suggestions or
ideas?
The
cast(const(char*))_wc.GetName()
line look *very* suspicious. You can't get a string and just
cast it to
const(char)*. Most importantly, the string (most likely) is
not
null-terminated.
What you need to do here is the following:
auto className = toStringz(_ws.GetName());
auto caption = toStringz(_windowName);
and pass those 2 to the function.
Actually I've already tried that, it has no effect on the
outcome.
From your suggestion though, I've gone back and replace all the
cast(const(char*)) usage throughout the program. Final verdict:
the program still crashes it the same location. It actually
never
returns from CreateWindowExA().
Alternatively, you could make sure your strings are null-
terminated and
pass the pointer directly (e.g. _windowName.ptr):
string _windowName = foo; // null-terminated automatically
string _caption = (Hello, World ~ \0)[0..$-1]; // append
trailing zero
to an existing string but exclude it from result (so that it's
not
included in _caption.length)
This is indeed strange, but it has nothing to do with the
function itself.
I still think the parameters you are passing might be invalid.
Try setting
them to default values and see if that helps. Also try wrapping
the call
with a try/catch block and output an exception you are getting
(if any).
The problem occurs at the site of the assertion. I wrapped the
function in a try/catch block and placed a call to MessageBoxA()
on either end of the the try block. Both calls to MessageBox fires
and the appropriate messages displayed. No exception is thrown:
made evident my the fact that the third call to MessageBox,
embeded in catch{}, is not fired. Nevertheless, execution haults
at the very next line following/catch and Create() never returns.
Re: string vs. w/char*
On 3/1/2011 12:25 AM, Tyro[a.c.edwards] wrote: Nevertheless, execution haults at the very next line following/catch and Create() never returns. CreateWindow sends a few messages to your window proc; anything interesting happening there?
Re: Mixins: to!string cannot be interpreted at compile time
On 03/01/2011 07:58 AM, Peter Lundgren wrote:
I'm trying to use mixins to generate an array of numbers that are coprime to a
statically known value. I've tried the following, but I receive the error:
Error: to(i) ~ , cannot be interpreted at compile time
string makePossibleAValues(string name, byte m) {
string result = immutable byte[] ~name~ = [;
foreach (i; 0 .. m) {
if (coprime(i, m)) {
result ~= to!string(i) ~ , ;
}
}
return result ~ ];;
}
bool coprime(ulong a, ulong b) {
return gcd(a, b) == 1;
}
ulong gcd(ulong a, ulong b) {
while (b) {
auto t = b;
b = a % b;
a = t;
}
return a;
}
mixin(makePossibleAValues(aValues, 26));
makePossibleAValues(aValues, 26) produces the correct result, immutable
byte[] aValues = [1, 3, 5, 7, 9, 11, 15, 17, 19, 21, 23, 25, ];, at runtime
and I know to!string can be used in mixins. Any idea as to why this particular
code is having trouble with to!string?
Not sure because I never use string mixins, but I guess the answer is precisely
what the error says. Why don't you believe it?
makePossibleAValues() obviously returns a runtime value, so mixin() cannot
evaluate it, I guess.
Denis
--
_
vita es estrany
spir.wikidot.com
Doubt about Synchronized Code Clocks
Greetings I have a doubt about synchronized code blocks. I learnt that in Java the synchronized keyword has two fold effect. Firstly it locks the code to make sure that only a single thread gets access to the code block at a given time. Secondly, it makes sure that the data elements accessed inside the code block are not stale. As a result Java programming practice is to synchronize even access functions that access shared data elements. How about D? Does D synchronized keyword just result in mutex locking of the code block? Or does it also ensure that the accessed shared data elements are not stale? Thanks and Regards - Puneet
Re: Problem with std.regex: *+? not allowed in atom
On 27.02.2011 13:41, Jacob Carlborg wrote:
On 2011-02-26 19:49, Dmitry Olshansky wrote:
On 26.02.2011 19:52, Jacob Carlborg wrote:
On 2011-02-26 12:29, Dmitry Olshansky wrote:
On 26.02.2011 14:10, Jacob Carlborg wrote:
I'm trying to use the std.regex module but when I run my
application I
get an exception. The exception message says:
*+? not allowed in atom
The code I have is:
import std.regex;
void main ()
{
regex(`\.(?=(?:[^\]*\[^\]*\)*(?![^\]*\))`, m);
}
Well the thing is, std.regex is not quite ECMA complaint (as vaguely
stated in docs). To the best of my knowledge not a single one
variant of
the forms (?:...) ... (?=...) is supported . Also see
http://d.puremagic.com/issues/show_bug.cgi?id=5169, you may try out my
patch there to support (?:...). It's a slightly outdated, but
std.regex
wasn't in very active development.
I tried the patch but with no success. I still get the same error.
The patch fixes only (?: ) form and not the lookahead and others. Sorry,
it was the only one I needed back then.
I'll check if I can make a patch for them as well when I have some spare
time. That's would be around monday if, of course, nobody else wishes to
rush into the depths of std.regex.
Ok.
So here it is, hot and bobbling. For now no lookbehind.
I added it into another Bugzilla
requesthttp://d.puremagic.com/issues/show_bug.cgi?id=5673
--
Dmitry Olshansky
Re: Is std.regex.match completely broken?
On 2011-03-01 14:03, Dmitry Olshansky wrote:
On 28.02.2011 22:37, Jacob Carlborg wrote:
The following code will result in an AssertError or RangeError when run.
import std.regex;
import std.stdio;
void main ()
{
auto m = abc.match(`a(\w)b`);
writeln(m.hit); // AssertError in regex.d:1795
writeln(m.captures); // RangeError in regex.d:1719
}
Should I report this as a bug?
Well, there won't be a match.
If you meant abc.match(`a(\w)c`) then it works for me.
At the bottom of it all, I also was sort of surprised to get an Assert
and not an Exception, but it's the way it works with ranges in Phobos.
So you should check m.empty before use.
That seems quite strange, to design an API like that. Why doesn't hit
just returns an empty string and captures an empty range.
P.S. I'm in the process of patching in lookahead regexes, I think I can
get them fairly soon. As for lookbehind, well, that's would be somewhat
harder it seems.
Sounds good.
--
/Jacob Carlborg
Re: Problem with std.regex: *+? not allowed in atom
On 2011-03-01 16:54, Dmitry Olshansky wrote:
On 27.02.2011 13:41, Jacob Carlborg wrote:
On 2011-02-26 19:49, Dmitry Olshansky wrote:
On 26.02.2011 19:52, Jacob Carlborg wrote:
On 2011-02-26 12:29, Dmitry Olshansky wrote:
On 26.02.2011 14:10, Jacob Carlborg wrote:
I'm trying to use the std.regex module but when I run my
application I
get an exception. The exception message says:
*+? not allowed in atom
The code I have is:
import std.regex;
void main ()
{
regex(`\.(?=(?:[^\]*\[^\]*\)*(?![^\]*\))`, m);
}
Well the thing is, std.regex is not quite ECMA complaint (as vaguely
stated in docs). To the best of my knowledge not a single one
variant of
the forms (?:...) ... (?=...) is supported . Also see
http://d.puremagic.com/issues/show_bug.cgi?id=5169, you may try out my
patch there to support (?:...). It's a slightly outdated, but
std.regex
wasn't in very active development.
I tried the patch but with no success. I still get the same error.
The patch fixes only (?: ) form and not the lookahead and others. Sorry,
it was the only one I needed back then.
I'll check if I can make a patch for them as well when I have some spare
time. That's would be around monday if, of course, nobody else wishes to
rush into the depths of std.regex.
Ok.
So here it is, hot and bobbling. For now no lookbehind.
I added it into another Bugzilla
requesthttp://d.puremagic.com/issues/show_bug.cgi?id=5673
Ok, thanks.
--
/Jacob Carlborg
Re: Doubt about Synchronized Code Clocks
On Tuesday 01 March 2011 06:40:31 d coder wrote: Greetings I have a doubt about synchronized code blocks. I learnt that in Java the synchronized keyword has two fold effect. Firstly it locks the code to make sure that only a single thread gets access to the code block at a given time. Secondly, it makes sure that the data elements accessed inside the code block are not stale. As a result Java programming practice is to synchronize even access functions that access shared data elements. How about D? Does D synchronized keyword just result in mutex locking of the code block? Or does it also ensure that the accessed shared data elements are not stale? I'm afraid that I have no idea what would be stale about a shared variable. sychronized uses a mutex, and if you want to avoid race conditions, you need to use mutexes or something similar when dealing with shared variables. But I don't know what would be stale about a variable. - Jonathan M Davis
Re: Doubt about Synchronized Code Clocks
I'm afraid that I have no idea what would be stale about a shared variable. sychronized uses a mutex, and if you want to avoid race conditions, you need to use mutexes or something similar when dealing with shared variables. But I don't know what would be stale about a variable. One thread modifies a shared variable and the other thread still gets an old value. I do not know if this is applicable to D at all. Just wanted to get a clarification after I read an article in Java Concurrency in Practice book. I quote a relevant paragraph: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing must synchronize on a common lock. Regards
comparing pointers passed to and returned from funcs
Hello,
It seems to be the kind of stupid issue that will make you laugh about me. But
I cannot grasp and want to move forward anyway; so, let us be bold and take the
risk ;-)
I'm modeling a little dynamic language. Elements (values, objects) are pointers
to structs (actually tagged unions) allocated on the heap. I have a problem in
passing and returning those pointers to and from primitive procedures.
Precisely, unlike in D, Logical (boolean) operations only accept Logical
elements true/false (called TRUE/FALSE on implementation side for obvious reason):
enum TRUE = new DElement(true);
enum FALSE = new DElement(false);
So, I thought I could write those operations by comparing pointers directly,
eg:
Element not (Element operand) {
// checks type
operand.checkLogical()
return (operand == TRUE) ? FALSE : TRUE;
}
...
assert ( not(TRUE) == FALSE );
This fails! It even fails doubly...
When I call not(TRUE), TRUE (the pointer) inside the func is not equal to the
global constant. Thus, not always returns FALSE. And in fact this is also
wrong, because I have the same problem on the return value as well: the FALSE
returned is not equal to the global FALSE.
But the pointed structs are ok. Each one holds a D boolean of the correct value
(a member called 'logical'). Thus, the following succeeds:
Element not (Element operand) {
// checks type returns the 'logical' member
auto log = operand.checkLogical();
return (log) ? FALSE : TRUE;
}
...
assert ( not(TRUE).logical == false );
Here, I operate on the structs instead of on the pointers, both to perform the
operation and in the assert. What I understand is: all happens like if D would
copy the pointed structs on parameter passing and on return. I thought D would
only copy the pointers (in both directions), which would let me compare said
pointers directly.
What do I miss?
It is not a serious problem since the workaround is easy and not very costly.
But I wish to understand why I cannot operate on constant 'identity'. As said
above, this must a trivial issue I simply cannot guess...
Thank you,
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Template argument deduction
On 02/28/2011 07:39 PM, Tom wrote:
foo([[1,2],[3,4],[5,6]]); // ERROR [1]
bar([[1,2],[3,4],[5,6]]); // OK
foo!int([[1,2],[3,4],[5,6]]); // OK
...
void foo(T)(T[2][] t) {
writeln(typeid(t));
}
void bar(T)(T[][] t) {
writeln(typeid(t));
}
On 03/01/2011 04:30 AM, bearophile wrote:
Ali Çehreli:
That's because the type of literals like [1, 2] are slices (dynamic
arrays), not fixed-sized arrays.
Then why is this accepted?
foo!int([[1,2],[3,4],[5,6]]); // OK
If I have to guess, I think supplying T as int now becomes a problem of
matching [1,2] with int[2] and it already works:
int[2] a = [1, 2];
int[2][] b = [ [1, 2] ];
I don't know whether the compiler should go the extra mile and help Tom
in the original case. :-/
Ali
Re: Mixins: to!string cannot be interpreted at compile time
That worked, thanks. This is interesting because the example used in The D Programming Language on page 83 gets away with it just fine. I had no problem running this: result ~= to!string(bitsSet(b)) ~ , ;
Re: Some weird crashes
On 28.02.2011 20:24, Denis Koroskin wrote: On Mon, 28 Feb 2011 22:04:44 +0300, simendsjo simen.end...@pandavre.com wrote: On 28.02.2011 18:52, simendsjo wrote: // ERROR auto res = mysql_library_init(0, null, null); auto cn = mysql_init(null); auto oldcn = cn; writeln(mysql_errno(cn)); assert(cn == oldcn); // when the last assert is active, the above line changes cn and thus fails. auto err = mysql_errno(cn); assert(cn == oldcn); Btw, if I don't use writeln it doesn't fail.. I think you have a bug at line 42. On a serious note, it might have helped if you'd attached source code, or at least binaries. Hmmm.. Seems my post last night didn't get through.. Here's the code and necessary libraries: http://share1t.com/4xgt2l
About const and C functions
Do you know why DMD doesn't give a compilation error here?
import core.stdc.stdio: sscanf;
immutable int value = 5;
void main() {
sscanf(10.ptr, %d.ptr, value);
}
Bye,
bearophile
Re: comparing pointers passed to and returned from funcs
spir:
It seems to be the kind of stupid issue that will make you laugh about me.
But
I cannot grasp and want to move forward anyway; so, let us be bold and take
the
risk ;-)
Be bold. Understanding things is much more important. I've being wrong hundreds
of times on D newsgroups, but I'm getting better.
This fails! It even fails doubly...
Reduced program (and Walter thinks that avoiding printf-related bugs is not
important. He's wrong. I use printf often enough in D):
import core.stdc.stdio: printf;
struct Foo {
bool b;
this(bool b_) { this.b = b_; }
}
enum Foo* TRUE = new Foo(true);
enum Foo* FALSE = new Foo(false);
Foo* not(Foo* op) {
return (op == TRUE) ? FALSE : TRUE;
}
void main() {
//assert(not(TRUE) == FALSE);
printf(%x\n, TRUE);
printf(%x\n, FALSE);
printf(%x\n, not(TRUE));
printf(%x\n, not(not(TRUE)));
}
Here, I operate on the structs instead of on the pointers, both to perform
the
operation and in the assert. What I understand is: all happens like if D
would
copy the pointed structs on parameter passing and on return. I thought D
would
only copy the pointers (in both directions), which would let me compare said
pointers directly.
What do I miss?
DMD is not copying the structs, just pointers.
I think it's happening something like with enum associative arrays. Pointers
are run-time things. You are asking for a new at compile-time. This is the asm
produced by that program (-O -release):
_D4test3Foo6__ctorMFNcbZS4test3Foo comdat
pushEAX
mov CL,8[ESP]
mov [EAX],CL
pop ECX
ret 4
_D4test3notFPS4test3FooZPS4test3Foo comdat
L0: pushEAX
mov ECX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ
pushEAX
pushEBX
push1
pushECX
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
push1
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
cmp EAX,8[ESP]
jne L3D
mov EDX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ
push1
pushEDX
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
push0
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
jmp short L56
L3D:mov EBX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ
push1
pushEBX
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
push1
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
L56:pop EBX
add ESP,8
ret
__Dmain comdat
L0: pushEAX
mov EAX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ
pushEBX
pushESI
push1
push1
pushEAX
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
mov ECX,offset FLAT:_DATA
pushEAX
pushECX
callnear ptr _printf
mov EDX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ
push0
push1
pushEDX
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
mov EBX,offset FLAT:_DATA
pushEAX
pushEBX
callnear ptr _printf
mov ESI,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ
push1
push1
pushESI
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
callnear ptr _D4test3notFPS4test3FooZPS4test3Foo
pushEAX
pushEBX
callnear ptr _printf
push1
push1
pushESI
callnear ptr __d_newarrayT
add ESP,8
mov EAX,EDX
callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo
callnear ptr _D4test3notFPS4test3FooZPS4test3Foo
callnear ptr _D4test3notFPS4test3FooZPS4test3Foo
pushEAX
pushEBX
call
Re: Doubt about Synchronized Code Clocks
On 01/03/2011 16:59, d coder wrote: I'm afraid that I have no idea what would be stale about a shared variable. sychronized uses a mutex, and if you want to avoid race conditions, you need to use mutexes or something similar when dealing with shared variables. But I don't know what would be stale about a variable. One thread modifies a shared variable and the other thread still gets an old value. I do not know if this is applicable to D at all. Just wanted to get a clarification after I read an article in Java Concurrency in Practice book. I quote a relevant paragraph: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing must synchronize on a common lock. Regards Perhaps what you mean is synchronising a function vs shared data object. If you have one Function A and some data D, then so long as ONLY function A (and it's callees) change or read D, then everything should work fine. Hence you're synchronising function A (or putting it in a critical section) However, if you have two functions A and B, and data D. If function A and B can read and or write to the data D, then thread 1 can execute in A (but no other if it's synchronised) But, it may be pre-empted and another thread can then start executing in function B that is also synchronised. The problem here is that function A is half way though execution when B starts, hence you could likely have data in D that has been partially changed, old other otherwise inconsistent, which can cause problems, or even proper disasters. The answer in this case is to have a mutex to protect D, so function A or B must obtain this and hold it while is modifies data D. Any other function will then have to wait for the mutex to be unlocked before reading or writing.
Re: comparing pointers passed to and returned from funcs
This seems to work:
import core.stdc.stdio: printf;
struct Foo {
bool b;
this(bool b_) { this.b = b_; }
}
const(Foo)* TRUE, FALSE;
static this() {
TRUE = new const(Foo)(true);
FALSE = new const(Foo)(false);
}
const(Foo)* not(const(Foo)* op) {
return (op == TRUE) ? FALSE : TRUE;
}
void main() {
assert(not(TRUE) == FALSE);
printf(%x\n, TRUE);
printf(%x\n, FALSE);
printf(%x\n, not(TRUE));
printf(%x\n, not(not(TRUE)));
}
Bye,
bearophile
Re: Doubt about Synchronized Code Clocks
On 01/03/2011 22:52, Spacen Jasset wrote: On 01/03/2011 16:59, d coder wrote: I'm afraid that I have no idea what would be stale about a shared variable. sychronized uses a mutex, and if you want to avoid race conditions, you need to use mutexes or something similar when dealing with shared variables. But I don't know what would be stale about a variable. One thread modifies a shared variable and the other thread still gets an old value. I do not know if this is applicable to D at all. Just wanted to get a clarification after I read an article in Java Concurrency in Practice book. I quote a relevant paragraph: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing must synchronize on a common lock. Regards Perhaps what you mean is synchronising a function vs shared data object. If you have one Function A and some data D, then so long as ONLY function A (and it's callees) change or read D, then everything should work fine. Hence you're synchronising function A (or putting it in a critical section) However, if you have two functions A and B, and data D. If function A and B can read and or write to the data D, then thread 1 can execute in A (but no other if it's synchronised) But, it may be pre-empted and another thread can then start executing in function B that is also synchronised. The problem here is that function A is half way though execution when B starts, hence you could likely have data in D that has been partially changed, old other otherwise inconsistent, which can cause problems, or even proper disasters. The answer in this case is to have a mutex to protect D, so function A or B must obtain this and hold it while is modifies data D. Any other function will then have to wait for the mutex to be unlocked before reading or writing. See: http://www.digitalmars.com/d/2.0/statement.html#SynchronizedStatement So you can EITHER use synchronised to mark a block of code for execution by one thread only. OR if you provide it with an expression, you mark the block to be run only if an object is unlocked, therin only one thread may accesses a bit shared of data. AFAIK this very similar to java http://www.herongyang.com/Java/Synchronization-Support-in-Java-synchronized.html
Win7 64-bit
I am running the dmd2 compiler on my Win7 64 bit machine and everything appears to work except the -cov switch. i cannot seem to generate a .lst file. any ideas? thanks dan mcleran
Re: Win7 64-bit
never mind, i got it. i had to pass the switches: -D -unittest -cov life is hard. it's even harder when you're dumb.
Re: comparing pointers passed to and returned from funcs
On 3/1/11 3:00 PM, bearophile wrote: const(Foo)* TRUE, FALSE; I'd remove those parens; you don't want people modifying TRUE or FALSE.
Re: comparing pointers passed to and returned from funcs
Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Bye, bearophile
Re: comparing pointers passed to and returned from funcs
On 3/1/11 4:12 PM, bearophile wrote: Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Touche. I'll have to test that out once I get back from work...
Re: comparing pointers passed to and returned from funcs
On 3/1/11 5:31 PM, bearophile wrote: Bekenn: Touche. I'll have to test that out once I get back from work... Sorry for that answer of mine, we are here to learn and cooperate, not to fight :-) It's just I sometimes have problems with const things in D, and sometimes DMD has problems with const things. Hey, no problem; I thought it was funny...
Re: comparing pointers passed to and returned from funcs
On 3/1/2011 4:12 PM, bearophile wrote: Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Bye, bearophile Here you go; I only changed the one line. Compiles and works just fine in dmd 2.051. const Foo* TRUE, FALSE; instead of const(Foo)* TRUE, FALSE;
Re: Constructor template -- bug?
On Tuesday 01 March 2011 23:43:27 Jonathan M Davis wrote:
On Tuesday 01 March 2011 22:18:49 Bekenn wrote:
Code:
class MyException : Exception
{
this(string message, string file, size_t line, Throwable next =
null)
{
super(message, file, line, next);
}
this(string file = __FILE__, size_t line = __LINE__)(string
message,
Throwable next = null)
{
this(message, file, line, next);
}
}
void main()
{
throw new MyException(Bluh!);
}
Error message:
test.d(8): Error: template test.MyException.__ctor(string file =
__FILE__,size_t line = __LINE__) conflicts with constructor
test.MyException.this at test.d(3)
If I remove the normal constructor and call super instead of this from
the constructor template, then I get this slightly different error message:
test.d(1): Error: constructor test.MyException.this conflicts with
template test.MyException.__ctor(string file = __FILE__,uint line =
__LINE__) at test.d(3)
Is this a compiler bug, or am I Doing It Wrong?
You cannot currently templatize class constructors:
http://d.puremagic.com/issues/show_bug.cgi?id=435
And currently if one overload of a function is templatized, _all_ overloads
of that function must templatized:
http://d.puremagic.com/issues/show_bug.cgi?id=2972
http://d.puremagic.com/issues/show_bug.cgi?id=4749
I should also point out that there is absolutely no need to use template for
what you're trying to do. Just declare the constructor like so:
this(string message, string file = __FILE__, size_t line = __LINE__ Throwable
next = null) { ... }
- Jonathan M Davis
Re: Constructor template -- bug?
On 2011-03-02 08:47, Jonathan M Davis wrote:
On Tuesday 01 March 2011 23:43:27 Jonathan M Davis wrote:
On Tuesday 01 March 2011 22:18:49 Bekenn wrote:
Code:
class MyException : Exception
{
this(string message, string file, size_t line, Throwable next =
null)
{
super(message, file, line, next);
}
this(string file = __FILE__, size_t line = __LINE__)(string
message,
Throwable next = null)
{
this(message, file, line, next);
}
}
void main()
{
throw new MyException(Bluh!);
}
Error message:
test.d(8): Error: template test.MyException.__ctor(string file =
__FILE__,size_t line = __LINE__) conflicts with constructor
test.MyException.this at test.d(3)
If I remove the normal constructor and call super instead of this from
the constructor template, then I get this slightly different error message:
test.d(1): Error: constructor test.MyException.this conflicts with
template test.MyException.__ctor(string file = __FILE__,uint line =
__LINE__) at test.d(3)
Is this a compiler bug, or am I Doing It Wrong?
You cannot currently templatize class constructors:
http://d.puremagic.com/issues/show_bug.cgi?id=435
And currently if one overload of a function is templatized, _all_ overloads
of that function must templatized:
http://d.puremagic.com/issues/show_bug.cgi?id=2972
http://d.puremagic.com/issues/show_bug.cgi?id=4749
I should also point out that there is absolutely no need to use template for
what you're trying to do. Just declare the constructor like so:
this(string message, string file = __FILE__, size_t line = __LINE__ Throwable
next = null) { ... }
- Jonathan M Davis
I guess the reason why he would do that is to catch the file and line
number where the constructor is called.
--
/Jacob Carlborg
