Bob Cowdery Wrote:
> Now I've tried this with just D code and it writes the output and runs
> so I know something works. Does anyone know where to look, is it
> Code::Blocks, compiler, stupidity (probably).
On windows dmd uses ancient OMF object format, but gcc compiles to COFF.
This D2 program comes (with few changes) from rosettacode site, it shows a
simple example of function composition:
// program #1
import std.stdio: writefln;
private import std.math;
T delegate(S) compose(T, U, S)(T delegate(U) f, U delegate(S) g) {
return (S s) { return f(g(s)); };
}
void
On Thu, Aug 19, 2010 at 2:46 PM, Jonathan M Davis wrote:
> My first question would be whether you used the same linker for both D and C.
> On
> Linux, they should both be using gcc. On Windows, they should both be using
> dmc.
> Still, I would have expected a linking error to be a bit more expl
On Thursday, August 19, 2010 11:08:33 Johannes Pfau wrote:
> Hi, I wrote some unittests using the built-in d unittest and a came
> across 2 problems:
>
> 1) I have some code that accepts both delegates and functions. How can a
> unittest explicitly check the function part? Whenever I add a functio
On Thursday, August 19, 2010 06:52:33 Bob Cowdery wrote:
> Hi
>
> Just trying to get started and need a little advice. First up was
> selecting an IDE, tried a few and settled on Code::Blocks. I need
> Windows and Linux and also C and D supported in the same IDE. The
> support does not seem to be
On Thursday, August 19, 2010 08:23:42 Simen kjaeraas wrote:
> A destructor is always final, and private destructors make no sense,
> so I would say the attributes should not be there.
Actually, I could see private destructors making at least some sense.
Obviously,
the runtime needs to be able to
I'm trying to create a Windows DLL as described in the tutorial at
http://www.digitalmars.com/d/2.0/dll.html. I got the basic example working
fine, but if I try to get more complicated, it doesn't work. Specifically, I'm
trying to link another static library into my DLL (the project is called canto
Philippe Sigaud wrote:
What, that's *five* more characters, five! I win, I win!
;'(
More seriously, yours might be more 'solid', but isn't enum implicit in
this
case?
Seems you are right. I thought the template would work as a namespace,
giving this situation:
Init!int = 4;
int a = Ini
Good to hear. I was almost going to open an enhancement request. :)
bearophile Wrote:
> Andrej Mitrovic:
> > Well first of all, DMD doesn't actually print it out simple qualifiers when
> > arrays are used, for example:
>
> I have an open bug report on this.
>
> Bye,
> bearophile
On Thu, Aug 19, 2010 at 22:16, Simen kjaeraas wrote:
> Philippe Sigaud wrote:
>
> And, looking in my codebase, here is what I'm using ;)
>>
>> template Init(T...)
>> {
>>T Init;
>> }
>>
>
> Doh. I believe this is slightly better, though:
>
> template Init( T... ) {
>enum T Init;
> }
>
>
Philippe Sigaud wrote:
And, looking in my codebase, here is what I'm using ;)
template Init(T...)
{
T Init;
}
Doh. I believe this is slightly better, though:
template Init( T... ) {
enum T Init;
}
:p
--
Simen
On Thu, Aug 19, 2010 at 21:51, Simen kjaeraas wrote:
> Johannes Pfau wrote:
>
> Hi,
>> I want to do exactly the same as described in
>> http://d.puremagic.com/issues/show_bug.cgi?id=4536 . The problem is I
>> can't even get the workaround to work. Dmd complains about the following
>> template:
>
Johannes Pfau wrote:
Hi, I wrote some unittests using the built-in d unittest and a came
across 2 problems:
1) I have some code that accepts both delegates and functions. How can a
unittest explicitly check the function part? Whenever I add a function
in an unittest block it becomes a delegate
Johannes Pfau:
> 1) I have some code that accepts both delegates and functions. How can a
> unittest explicitly check the function part? Whenever I add a function
> in an unittest block it becomes a delegate.
You may define it outside the unittest{} block (that is a function) and wrap
everything
Andrej Mitrovic:
> Well first of all, DMD doesn't actually print it out simple qualifiers when
> arrays are used, for example:
I have an open bug report on this.
Bye,
bearophile
Johannes Pfau wrote:
Hi,
I want to do exactly the same as described in
http://d.puremagic.com/issues/show_bug.cgi?id=4536 . The problem is I
can't even get the workaround to work. Dmd complains about the following
template:
---
templat
Hi,
I want to do exactly the same as described in
http://d.puremagic.com/issues/show_bug.cgi?id=4536 . The problem is I
can't even get the workaround to work. Dmd complains about the following
template:
---
template Init(T...)
{
alias
Hi, I wrote some unittests using the built-in d unittest and a came
across 2 problems:
1) I have some code that accepts both delegates and functions. How can a
unittest explicitly check the function part? Whenever I add a function
in an unittest block it becomes a delegate.
---
Hi
Just trying to get started and need a little advice. First up was
selecting an IDE, tried a few and settled on Code::Blocks. I need
Windows and Linux and also C and D supported in the same IDE. The
support does not seem to be finished in Code::Blocks though, does it
really not have syntax high
Btw, should I skip trying to use inout at all for now? I've read some posts
saying that it's awfully broken, and the example of inout in TDPL doesn't work..
Andrej Mitrovic Wrote:
> snip
In TDPL, page 289 & 299, there's this code (I've modified the names slightly)
and explanation:
struct A
{
const(int[]) c;
immutable(int[]) i;
}
import std.stdio;
unittest
{
const(A) const_a;
immutable(A) immu_b;
}
A short version of the explanation:
"if qualifiers would apply
Simen kjaeraas:
> A destructor is always final, and private destructors make no sense,
> so I would say the attributes should not be there.
Thank you for your answer, I have added the test case to bug 3934
Bye,
bearophile
bearophile wrote:
According to TDPL the whole object destructor chain is called up to the
top of the hyerarchy.
This D2 program compiles and runs with DMD 2.048 with no errors:
import std.c.stdio: puts;
class Base {
private final ~this() { puts("Base.~this"); }
}
class Derived : Base {
Rory Mcguire Wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
> assert("This" is "This");
> }
>
>
> Can this be relied upon?
T
Rory Mcguire wrote:
Are all string literals that have the same value initialized to the same
address?
void main() {
string same() {
return "This";
}
assert("This" is same());
assert("This" is "This");
}
Can this be relied upon?
No. The same s
According to TDPL the whole object destructor chain is called up to the top of
the hyerarchy.
This D2 program compiles and runs with DMD 2.048 with no errors:
import std.c.stdio: puts;
class Base {
private final ~this() { puts("Base.~this"); }
}
class Derived : Base {
private final ~thi
On 19.08.2010 09:53, Rory Mcguire wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
> assert("This" is "This");
> }
>
>
> Can thi
Jonathan Davis wrote:
You can always check with the is operator though. If it reports true,
then the two strings have the same instance. If it reports false, then
they don't.
I can't see how testing each string literal to see if it's the same
instance as another can work.
The OP's point is:
Rory Mcguire:
> Are all string literals that have the same value initialized to the same
> address?
> ...
> Can this be relied upon?
Probably a conforming D implementation is free to not give the same address to
those.
Bye,
bearophile
18.08.2010 17:54, Jesse Phillips wrote:
In my experience Windows hasn't gotten piping right. And it has been known to
have bugs, this might be related:
http://stackoverflow.com/questions/466801/python-piping-on-windows-why-does-this-not-work
Thanks, I'll take a look at that.
--
On 8/19/10, Rory Mcguire wrote:
> Are all string literals that have the same value initialized to the same
> address?
>
> void main() {
> string same() {
> return "This";
> }
> assert("This" is same());
> assert("This" is "This");
> }
>
>
> Can this be relied
Are all string literals that have the same value initialized to the same
address?
void main() {
string same() {
return "This";
}
assert("This" is same());
assert("This" is "This");
}
Can this be relied upon?
On Wed, 18 Aug 2010 13:50:34 -0400, Nick Sabalausky wrote:
> "Steven Schveighoffer" wrote in message
> news:op.vhl46mdneav...@localhost.localdomain...
>>
>> Changes are afoot to std.process, we recently got a blocker fixed (not
>> yet in svn, but someone submitted a correct patch)
>>
>>
> Issue #
33 matches
Mail list logo
