Jesse Phillips jessekphillip...@gmail.com wrote:
simendsjo Wrote:
On 04.03.2011 23:10, Jesse Phillips wrote:
Remember that const/immutable, and other attributes/properties aren't
going to change the ABI so dropping them will be safer then leaving
them.
Thanks. Does this apply to all
On 05.03.2011 08:58, Jérôme M. Berger wrote:
simendsjo wrote:
On 04.03.2011 22:42, Jérôme M. Berger wrote:
int main(string[] args) {
auto s1 =(); // MH MH
auto s2 =(); // OK
s2.c =ull; // OK
return 0;
}
Is part of your message gone?
Uh, I did not write that.
On 03/05/2011 04:02 AM, Peter Lundgren wrote:
I have a function that I think should look something like this:
MyStruct!T myFunc(T)(MyStruct!T x, ...) {
...
return MyStruct!T(...);
}
and the closest I can get to is:
T myFunc(T)(T x, ...) {
...
return T(...);
}
Jonathan M Davis:
Asserts are for
debugging, testing, and verifying code when developing, not for code which is
released.
If you take a look at the dmd compiler, it's released with asserts in, and they
give all those nice error messages I put in Bugzilla :-)
Bye,
bearophile
On 03/05/2011 01:58 PM, bearophile wrote:
Jonathan M Davis:
Asserts are for
debugging, testing, and verifying code when developing, not for code which is
released.
If you take a look at the dmd compiler, it's released with asserts in, and they
give all those nice error messages I put in
Kai Meyer Wrote:
I can't seem to get this to work right:
gcc -m32 -shared -fPIC Test.cpp -o libTest.so
g++ -m32 test_c.cpp -L. -lTest -o test_c
wine htod.exe Test.h Test.d
dmd test_d.d Test.d -L-L. -L-lTest -oftest_d
test_d.o: In function `_Dmain':
Test.d:(.text._Dmain+0x20): undefined
On 3/5/11, bearophile bearophileh...@lycos.com wrote:
Jonathan M Davis:
Asserts are for
debugging, testing, and verifying code when developing, not for code which
is
released.
If you take a look at the dmd compiler, it's released with asserts in, and
they give all those nice error
simendsjo wrote:
On 05.03.2011 08:58, Jérôme M. Berger wrote:
simendsjo wrote:
On 04.03.2011 22:42, Jérôme M. Berger wrote:
int main(string[] args) {
auto s1 =(); // MH MH
auto s2 =(); // OK
s2.c =ull; // OK
return 0;
}
Is part of your message gone?
Uh, I did
On 28.02.2011 18:52, simendsjo wrote:
I'm trying to wrap the newest mysql c connector, but I get some weird
bugs. I don't know any assembly, so I don't even know if I've included
enough info.. I hope this is a small enough test case so someone can
understand the issue.
I've used implib on the
Simen kjaeraas Wrote:
Hopefully I'm not wrong on this, but you should even be able to change
the type as long as the size is the same. So instead of int you could
use uint or byte[8]... granted the library will still interpret it as
int. And of course that is assuming you are on a
On Sat, 05 Mar 2011 18:12:30 +, Lars T. Kyllingstad wrote:
On Sat, 05 Mar 2011 10:15:48 -0700, user wrote:
On 03/04/2011 09:22 PM, Jonathan M Davis wrote:
On Friday 04 March 2011 20:14:32 Kai Meyer wrote:
I have an 'enforce' function call in an 'in' block for a function.
When I compile
On 05.03.2011 20:04, Bekenn wrote:
On 3/4/2011 3:31 PM, simendsjo wrote:
The htod page, http://www.digitalmars.com/d/2.0/htod.html, says that
system files will be included using the -hs option.
htod mysql.h -hs
Fatal error: unable to open input file 'sys/types.h'
Does it try to find these
On Saturday 05 March 2011 05:30:23 Andrej Mitrovic wrote:
On 3/5/11, bearophile bearophileh...@lycos.com wrote:
Jonathan M Davis:
Asserts are for
debugging, testing, and verifying code when developing, not for code
which is
released.
If you take a look at the dmd compiler, it's
On Saturday 05 March 2011 13:54:08 Jonathan M Davis wrote:
On Saturday 05 March 2011 05:30:23 Andrej Mitrovic wrote:
On 3/5/11, bearophile bearophileh...@lycos.com wrote:
Jonathan M Davis:
Asserts are for
debugging, testing, and verifying code when developing, not for code
which is
On Saturday 05 March 2011 09:15:48 user@domain.invalid wrote:
On 03/04/2011 09:22 PM, Jonathan M Davis wrote:
On Friday 04 March 2011 20:14:32 Kai Meyer wrote:
I have an 'enforce' function call in an 'in' block for a function. When
I compile with -release -O -inline, the in/out blocks
El 05/03/2011 20:56, Jonathan M Davis escribió:
On Saturday 05 March 2011 15:37:15 Tom wrote:
I have some kind of a middle-size project written in D2. I've been
compiling always with -debug -unittest switches and, despite having to
workaround two or three bugs since the beginning, I could
On Saturday 05 March 2011 16:40:02 Tom wrote:
Well, I did what you suggested with success (thanks).
Okay. I created a bug report for it:
http://d.puremagic.com/issues/show_bug.cgi?id=5708
In the meantime, I would suggest that you simply not compile with -
noboundscheck. It's likely that it
El 05/03/2011 22:05, Jonathan M Davis escribió:
On Saturday 05 March 2011 16:40:02 Tom wrote:
Well, I did what you suggested with success (thanks).
Okay. I created a bug report for it:
http://d.puremagic.com/issues/show_bug.cgi?id=5708
In the meantime, I would suggest that you simply not
Greetings
Why is it necessary to use synchronized functions when passing shared
variables? I get error even when I am not modifying the shared variable in
the function.
Kindly look at the following code. I get a compile error unless I declare
the functions parent and root synchronized.
The
== Quote from spir (denis.s...@gmail.com)'s article
On 03/05/2011 04:02 AM, Peter Lundgren wrote:
I have a function that I think should look something like this:
MyStruct!T myFunc(T)(MyStruct!T x, ...) {
...
return MyStruct!T(...);
}
and the closest I can get to is:
T
On Saturday 05 March 2011 20:00:07 d coder wrote:
Greetings
Why is it necessary to use synchronized functions when passing shared
variables? I get error even when I am not modifying the shared variable in
the function.
Kindly look at the following code. I get a compile error unless I
21 matches
Mail list logo
