Re: How to avoid the console from apearing.
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 #? 3979
String literals have only one instance?
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?
Re: String literals have only one instance?
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 upon?
>
Well, since in Windows at least, string literals can be concatenated
to and whatnot, I very much doubt that there's any sharing involved.
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.
Re: Reading stdin in Windows 7
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. --
Re: String literals have only one instance?
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
Re: String literals have only one instance?
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: Are identical string literals *guaranteed* to be the same instance? Regardless of implementation? Regardless of whether they're next to each other, in different modules or anything in between? Regardless of the phase of the moon? Stewart.
Re: String literals have only one instance?
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 this be relied upon?
I don't think so. It might work now, as we only have static linking, but
what happens if we have 2 independent shared libraries with the string
"This"? Each library has to include the string because the libraries
don't depend on each other, but as soon as a program uses both libraries
there are 2 memory locations where the string could be. (I guess the
linker won't do some magic to make these point at the same location. But
I might be wrong.)
--
Johannes Pfau
private final class destructors
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 ~this() { puts("Derived.~this"); }
}
void main() {
new Derived();
}
Output:
Derived.~this
Base.~this
Are the 'private final' attributes used here correct?
See also: http://d.puremagic.com/issues/show_bug.cgi?id=3934
Bye,
bearophile
Re: String literals have only one instance?
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 string in different object files may be different instances,
as may of course those in dynamically linked libraries. I would think the
optimizer feels free to move string literals around as it sees fit, and
the spec does not anywhere state that the compiler should merge string
literals.
--
Simen
Re: String literals have only one instance?
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?
This should be expected but I wouldn't rely upon it.
Re: private final class destructors
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 {
private final ~this() { puts("Derived.~this"); }
}
void main() {
new Derived();
}
Output:
Derived.~this
Base.~this
Are the 'private final' attributes used here correct?
See also: http://d.puremagic.com/issues/show_bug.cgi?id=3934
A destructor is always final, and private destructors make no sense,
so I would say the attributes should not be there.
--
Simen
Re: private final class destructors
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
typeid() after const/immutable qualifiers
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 blindly, the types would be:
const_a.c == const(const(int[]))
const_a.i == const(immutable(int[]))
immu_b.c == immutable(const(int[])).
immu_b.i == immutable(immutable(int[])).
When two qualifiers are identical, they are collapsed into one, otherwise
const(immutable(T)) and immutable(const(T)) are both collapsed into
immutable(T)"
>From my interpretation, that would mean the types are now:
const_a.c == const(int[])
const_a.i == immutable(int[])
immu_b.c == immutable(int[])
immu_b.i == immutable(int[])
Am I correct so far?
Well first of all, DMD doesn't actually print it out simple qualifiers when
arrays are used, for example:
const(int[]) x;
writeln(typeid(x));
Writes:
const(const(int)[])
Which is fine, both x and it's contents are const so it's the correct output.
The second thing which I'm actually puzzled by, is why I'm getting typeid()
return the same qualifiers as defined in the struct. Here's some simplified
code with using basic types, not arrays:
struct A
{
const(int) c;
immutable(int) i;
}
import std.stdio;
unittest
{
const(A) const_a;
immutable(A) immu_b;
writeln("const_a.c == ", typeid(const_a.c));
writeln("const_a.i == ", typeid(const_a.i));
writeln("immu_b.c == ", typeid(immu_b.c));
writeln("immu_b.i == ", typeid(immu_b.i));
}
void main()
{
}
Writes:
const_a.c == const(int)
const_a.i == immutable(int)
immu_b.c == const(int)
immu_b.i == immutable(int)
Shouldn't this be this instead:
const_a.c == const(int)
const_a.i == immutable(int)
immu_b.c == immutable(int) // immu_b.c is now immutable
immu_b.i == immutable(int)
AFAIK immutable propagates to all fields of the struct, so const c should be an
immutable now?
Re: typeid() after const/immutable qualifiers
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
Can't get D calling C to build.
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 highlighting for D or did I miss something. Anyhow it works well enough for now. First task was to build a test of D calling C. Made the simplest possible C static library, one method returns a string. Made the simplest possible D app which calls the C method and prints the result. I built the C part and then referenced it as a library in the D build. The D build goes with no errors and says it has written the output file... but it doesn't, there is no output file. It says: Linking console executable: bin\Release\DTest.exe 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). Regards Bob
unittest questions
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.
---
void add(T)(T handler) if (is(T == void function())){}
void add(T)(T handler) if (is(T == void delegate())){}
unittest
{
//always a delegate
void handler() {};
add(&handler);
}
2) I know Errors should not be caught. But when I expect a function to
throw in debug mode, but not necessarily in release mode (assert), I
have to check for both Errors and Exceptions --> Throwable. Is it OK to
catch Throwables in this case?
unittest
{
void handler() {};
bool thrown = false;
try
add(&handler);
catch(Throwable)
thrown = true;
assert(thrown);
}
--
Johannes Pfau
Getting .init of a Typetuple
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 (Tuple!T.init).expand Init;
}
---
Dmd output:
---
test.d(18): basic type expected, not (
test.d(18): found '!' when expecting ')'
test.d(18): semicolon expected to close alias declaration
test.d(18): no identifier for declarator T.init
test.d(18): semicolon expected, not ')'
test.d(18): Declaration expected, not ')'
---
Is it possible that this has recently stopped working? Is this a bug in
dmd or is this the expected behavior? Is there any other way to achieve
the same thing?
--
Johannes Pfau
Re: Getting .init of a Typetuple
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:
---
template Init(T...)
{
alias (Tuple!T.init).expand Init;
}
---
Dmd output:
---
test.d(18): basic type expected, not (
test.d(18): found '!' when expecting ')'
test.d(18): semicolon expected to close alias declaration
test.d(18): no identifier for declarator T.init
test.d(18): semicolon expected, not ')'
test.d(18): Declaration expected, not ')'
---
Is it possible that this has recently stopped working? Is this a bug in
dmd or is this the expected behavior? Is there any other way to achieve
the same thing?
This works for me:
template Init( T ) {
alias TypeTuple!( T.init ) Init;
}
template Init( T, U... ) {
alias TypeTuple!( T.init, Init!U ) Init;
}
--
Simen
Re: typeid() after const/immutable qualifiers
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
Re: unittest questions
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 inside a version(unittest){} block.
Bye,
bearophile
Re: unittest questions
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.
---
void add(T)(T handler) if (is(T == void function())){}
void add(T)(T handler) if (is(T == void delegate())){}
unittest
{
//always a delegate
void handler() {};
add(&handler);
}
You can use version statements[1] to place the function outside the
unittest scope:
version( unittest ) {
void handler() {}
}
unittest {
add( &handler );
}
You could also use function literals[2]:
unittest {
add( function void() {} );
}
2) I know Errors should not be caught. But when I expect a function to
throw in debug mode, but not necessarily in release mode (assert), I
have to check for both Errors and Exceptions --> Throwable. Is it OK to
catch Throwables in this case?
unittest
{
void handler() {};
bool thrown = false;
try
add(&handler);
catch(Throwable)
thrown = true;
assert(thrown);
}
Yes.
[1]: http://www.digitalmars.com/d/2.0/version.html#version
http://www.digitalmars.com/d/2.0/version.html#PredefinedVersions
[2]: http://www.digitalmars.com/d/2.0/expression.html#FunctionLiteral
--
Simen
Re: Getting .init of a Typetuple
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:
>> ---
>> template Init(T...)
>> {
>
> alias (Tuple!T.init).expand Init;
>> }
>>
>
Hmm, I'm pretty sure it used to worked, because as one time that's what I
used.
Anyway, Simen's solutions is better, a bit less dependency. TypeTuple is a
bit more universal than Tuple.
Simen:
>
> template Init( T ) {
>alias TypeTuple!( T.init ) Init;
> }
>
> template Init( T, U... ) {
>alias TypeTuple!( T.init, Init!U ) Init;
> }
>
>
And, looking in my codebase, here is what I'm using ;)
template Init(T...)
{
T Init;
}
It's so simple...
I think I found this before the bug report and then forgot about it and
copied an old version. I'll update the bug report accordingly, if the latter
version works for you.
Philippe
Re: Getting .init of a Typetuple
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
Re: Getting .init of a Typetuple
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;
> }
>
> :p
>
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?
Anyway, T.init should exist, since "T Init;" works...
Philippe
Re: typeid() after const/immutable qualifiers
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
Re: Getting .init of a Typetuple
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 = Init!int; // What, 4?! But such is not the case. Anyway, T.init should exist, since "T Init;" works... Indeed. -- Simen
having trouble linking a library into a DLL
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): dmd -ofcanto.dll -L/IMPLIB canto.d dllmain.d canto.def IddParserD.lib Based on the example given, this seems like it should work, but when I run it, neither the .dll nor its implementation lib is created (even though DMD reports no errors). A canto.obj was generated and I tried to use optlink directly, but again no .dll was created. Additionally, if I leave the .lib off the DMD command line, DMD reports link errors (as it should) but then somehow builds a .dll and ATA.lib anyway (I don't know why it's not naming the implementation library correctly). (Naturally, these are not useful for anything.) How am I supposed to do what I'm trying to do?
Re: private final class destructors
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 call them, but I could see someone wanting to make it so that a destructor could not be explicitly called by the programmer. I'm not sure that that's ultimately all that useful, but I could see private destructors working that way. - Jonathan M Davis
Re: Can't get D calling C to build.
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 finished in Code::Blocks though, does it > really not have syntax highlighting for D or did I miss something. > > Anyhow it works well enough for now. First task was to build a test of D > calling C. Made the simplest possible C static library, one method > returns a string. Made the simplest possible D app which calls the C > method and prints the result. I built the C part and then referenced it > as a library in the D build. The D build goes with no errors and says it > has written the output file... but it doesn't, there is no output file. > > It says: > Linking console executable: bin\Release\DTest.exe > > 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). > > Regards > Bob 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 explosive than nothing. - Jonathan M Davis
Re: unittest questions
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 function
> in an unittest block it becomes a delegate.
> ---
> void add(T)(T handler) if (is(T == void function())){}
> void add(T)(T handler) if (is(T == void delegate())){}
>
> unittest
> {
> //always a delegate
> void handler() {};
> add(&handler);
> }
>
>
> 2) I know Errors should not be caught. But when I expect a function to
> throw in debug mode, but not necessarily in release mode (assert), I
> have to check for both Errors and Exceptions --> Throwable. Is it OK to
> catch Throwables in this case?
>
> unittest
> {
> void handler() {};
> bool thrown = false;
> try
> add(&handler);
> catch(Throwable)
> thrown = true;
>
> assert(thrown);
> }
>
If you declare a nested function as static, it shouldn't be a delegate. Also, I
don't believe that you need the semicolon after the function declaration.
- Jonathan m Davis
Re: Can't get D calling C to build.
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 explosive than > nothing. > > - Jonathan M Davis My experience has been the opposite - dmd is needed to link programs that mix C and D. While you may not want to jump into CMake for builds, the regression tests for cmaked include building and link D+C objects and D + C libraries. http://code.google.com/p/cmaked2/wiki/GettingStarted FYI, cmaked is still work in progress, so you might run into bumps. -steve
std.functional.compose() design
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 main() {
auto sin = (real x) { return std.math.sin(x); };
auto asin = (real x) { return std.math.asin(x); };
auto cos = (real x) { return std.math.cos(x); };
auto acos = (real x) { return std.math.acos(x); };
auto cube = (real x) { return x ^^ 3; };
auto cbrt = (real x) { return std.math.cbrt(x); };
auto fun = [sin, cos, cube];
auto inv = [asin, acos, cbrt];
foreach (i, f; fun)
writefln("%6.3f", compose(f, inv[i])(0.5));
}
In Phobos2 there is a compose(), but it takes the functions as template
arguments, so you can't just use:
foreach (i, f; fun)
writefln("%6.3f", compose!(f, inv[i])(0.5));
You need to use (ugly) TypeTuples of delegates, a static foreach and a bit of
template blot caused by the static foreach:
// program #2
import std.stdio: writefln;
private import std.math;
import std.functional: compose;
import std.typetuple: TypeTuple;
void main() {
// wrappers needed as not all built-in functions
// have same signature, eg pure/nothrow
auto sin = (real x) { return std.math.sin(x); };
auto asin = (real x) { return std.math.asin(x); };
auto cos = (real x) { return std.math.cos(x); };
auto acos = (real x) { return std.math.acos(x); };
auto cube = (real x) { return x ^^ 3; };
auto cbrt = (real x) { return std.math.cbrt(x); };
alias TypeTuple!(sin, cos, cube) dir;
alias TypeTuple!(asin, acos, cbrt) inv;
foreach (i, f; dir)
writefln("%6.3f", compose!(f, inv[i])(0.5));
}
Is the usage of compose of program #1 common? If so the design of
std.functional.compose may be reconsidered.
Bye,
bearophile
Re: Can't get D calling C to build.
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.
