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 #
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 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
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.
--
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
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:
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
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
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
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
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 {
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
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
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
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
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,
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
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
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:
> 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
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
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:
>
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 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;
> }
>
>
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
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
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
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
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 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 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
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
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.
33 matches
Mail list logo
