How to realize isSortedRange?
I need to ensure that range passed to function is SortedRange to use
binary search. I did something like:
static if(!__traits(compiles,
{
ElementType!(typeof(data)) element;
auto d = data.trisect(element);
}
)) assert(0, DataRange shall be SortedRange);
It works for me, but in fact it checks if the type of 'data' have
'trisect' method and conception of SortedRange is something more than
having 'trisect' method.
I remember there is(?) some way to get general type of template (i.e.
SortedRange instead of SortedRange!int), but can not find it.
Re: How to realize isSortedRange?
http://dlang.org/phobos/std_traits.html#TemplateOf
Re: How to realize isSortedRange?
On Wednesday, 20 August 2014 at 07:18:12 UTC, Kagamin wrote: http://dlang.org/phobos/std_traits.html#TemplateOf Or isInstanceOf. static if (__traits(isSame, TemplateOf!R, SortedRange)) static if (isInstanceOf!(SortedRange, R))
Re: How to realize isSortedRange?
Thank you!
Re: Auto attributes for functions
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
Currently, just templated functions get their attributes inferred. The biggest
problem with inferring them for all functions is that you can declare a
function without defining it in the same place (e.g. if you're using .di
files), in which case the compiler has no function body to use for attribute
inferrence.
There have been discussions on ways to reasonably infer attributes under more
circumstances, but nothing has come of them yet. However, I'd expect that
there will be at least some improvements to the situation at some point given
that there is a general consensus that while the attributes are quite useful,
it's also rather annoying to have to keep typing them all.
- Jonathan M Davis
Re: Auto attributes for functions
On Wednesday, 20 August 2014 at 09:13:15 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
On Wed, 20 Aug 2014 01:38:52 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Hi all,
Bit new to D so this might be a very naive question...
Can the compiler auto infer function attributes?
I am often adding as many attributes as possible and use the
compiler to show me where they're not applicable and take them
away. It would be great if this could be achieved like so:
auto function() @auto
{}
instead of manually writing:
auto function() pure @safe nothrow @nogc const
{}
Currently, just templated functions get their attributes
inferred. The biggest
problem with inferring them for all functions is that you can
declare a
function without defining it in the same place (e.g. if you're
using .di
files), in which case the compiler has no function body to use
for attribute
inferrence.
There have been discussions on ways to reasonably infer
attributes under more
circumstances, but nothing has come of them yet. However, I'd
expect that
there will be at least some improvements to the situation at
some point given
that there is a general consensus that while the attributes are
quite useful,
it's also rather annoying to have to keep typing them all.
- Jonathan M Davis
Thanks guys for the info.
/uri
delegates GC allocations
I've been hearing that delegates get a context pointer which will be
allocated on the GC. Is this also true for delegates which stay in scope?
e.g.
void addThree() {
int val;
void addOne() {
val++;
}
addOne();
addOne();
addOne();
return val;
}
Will the above function allocate on the GC?
Re: delegates GC allocations
On Wed, 20 Aug 2014 10:44:38 -0400 Etienne via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Will the above function allocate on the GC? no. signature.asc Description: PGP signature
Variadic parameter of length 1
I have several times seen a construct
template foo(T...) if(T.length == 1)
{
...
}
What is that good for?
Why using variadic parameter if anyway exactly one parameter is
required?!?
Re: delegates GC allocations
non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive.
Re: delegates GC allocations
On Wednesday, 20 August 2014 at 14:44:39 UTC, Etienne wrote:
I've been hearing that delegates get a context pointer which
will be allocated on the GC. Is this also true for delegates
which stay in scope?
e.g.
void addThree() {
int val;
void addOne() {
val++;
}
addOne();
addOne();
addOne();
return val;
}
Will the above function allocate on the GC?
int getInt1() @nogc
{
int val;
int func() @nogc { return val; }
return func();
}
int delegate() getInt2() //@nogc - thie one allocates!
{
int val;
int func() @nogc { return val; }
return func;
}
int delegate() getInt3() @nogc
{
int val;
int func() @nogc { return 0; }
return func;
}
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:11:53 UTC, Dominikus Dittes
Scherkl wrote:
I have several times seen a construct
template foo(T...) if(T.length == 1)
{
...
}
What is that good for?
Why using variadic parameter if anyway exactly one parameter is
required?!?
AFAIK, it's a historical workaround to accept T as either alias
or not alias, as varargs have auto alias. EG:
foo!int //OK
foo!hello //OK too
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:26:14 UTC, monarch_dodra wrote: AFAIK, it's a historical workaround to accept T as either alias or not alias, as varargs have auto alias. EG: foo!int //OK foo!hello //OK too Ah, ok. And why historical? Is that not necessary anymore? What better solution is there today?
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:11:53 UTC, Dominikus Dittes
Scherkl wrote:
I have several times seen a construct
template foo(T...) if(T.length == 1)
{
...
}
What is that good for?
Why using variadic parameter if anyway exactly one parameter is
required?!?
That's because template alias parameters cannot take builtin
types like int, and type parameters can only take types. But
tuple elements can be anything.
struct SomeType {}
template a(X) {enum a = 0;} /* type parameter */
enum a1 = a!int; /* ok */
enum a2 = a!SomeType; /* ok */
version(none) enum a3 = a!42; /* Error: template instance a!42
does not match template declaration a(X) */
template b(alias x) {enum b = 0;} /* alias parameter */
version(none) enum b1 = b!int; /* Error: template instance b!int
does not match template declaration b(alias x) */
enum b2 = b!SomeType; /* ok */
enum b3 = b!42; /* ok */
template c(x ...) if(x.length == 1) {enum c = 0;} /* tuple
parameter */
enum c1 = c!int; /* ok */
enum c2 = c!SomeType; /* ok */
enum c3 = c!42; /* ok */
Re: Variadic parameter of length 1
On Wed, Aug 20, 2014 at 5:34 PM, Dominikus Dittes Scherkl via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Wednesday, 20 August 2014 at 15:26:14 UTC, monarch_dodra wrote: AFAIK, it's a historical workaround to accept T as either alias or not alias, as varargs have auto alias. EG: foo!int //OK foo!hello //OK too Ah, ok. And why historical? Is that not necessary anymore? What better solution is there today? No better solution that I know of. alias template parameters (alias a) match symbols (names, user-defined types) whereas type parameter (T) match only pure types. So when we need to match anything, we use (T...) if (T.length == 1)
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:37:18 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: No better solution that I know of. alias template parameters (alias a) match symbols (names, user-defined types) whereas type parameter (T) match only pure types. So when we need to match anything, we use (T...) if (T.length == 1) Ok, now it's clear. Thank you very much. Sometimes D is really a little weird...
How to set workDir for std.process.execute ?
Hello,
I'm trying to follow the documentation:
http://dlang.org/phobos/std_process.html#.execute
Unfortunately, the following code gives me a compiler error:
class Probator
{
char[] dir;
this(const char[] dir){
this.dir = dir.dup;
}
int revision(){
import std.process;
import std.conv;
const char[] workDir = ~.dup;
auto p = std.process.execute([svnversion, dir], null,
Config.none, size_t.max, workDir);
if(p.status == 0){
return to!int(p.output);
}else{
throw new Exception(p.output);
}
}
}
error:
/d629/f876.d(15): Error: function std.process.execute
(const(char[][]) args, const(immutable(char)[][string]) env =
null, Config config = cast(Config)0, ulong maxOutput =
18446744073709551615LU) is not callable using argument types
(const(char)[][], typeof(null), Config, ulong, const(char[]))
It's as if the implementation didn't expect the last argument.
Re: How to set workDir for std.process.execute ?
On Wed, 20 Aug 2014 16:07:47 + KrzaQ via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: It's as if the implementation didn't expect the last argument. try to upgrade to dmd 2.066. signature.asc Description: PGP signature
Re: How to set workDir for std.process.execute ?
On Wednesday, 20 August 2014 at 16:16:03 UTC, ketmar via Digitalmars-d-learn wrote: On Wed, 20 Aug 2014 16:07:47 + KrzaQ via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: It's as if the implementation didn't expect the last argument. try to upgrade to dmd 2.066. That did the trick. Thanks.
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 15:34:30 UTC, Dominikus Dittes Scherkl wrote: And why historical? Is that not necessary anymore? What better solution is there today? Historical in a sense that distinct can be anything template parameter is probably a better approach but it is too late to change such core language part.
Re: Variadic parameter of length 1
On Wednesday, 20 August 2014 at 17:02:59 UTC, Dicebot wrote: On Wednesday, 20 August 2014 at 15:34:30 UTC, Dominikus Dittes Scherkl wrote: And why historical? Is that not necessary anymore? What better solution is there today? Historical in a sense that distinct can be anything template parameter is probably a better approach but it is too late to change such core language part. Yeah, what he said. It's a language artifact.
Can you explain this?
Hi,
I'm implementing some template checks on some types I'm using in
a project, and went to phobos for some indications on how to use
them.
In std.range, I see this construct quite a bit:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
}
Can anyone explain the:
is(typeof(
(inout int = 0) {}
);
section to me?
It looks veryhacky.
I see 3 distinct parts playing a role in my confusion:
A) The 'is' keyword. What does it do when you have is(expression);
B) typeof( expression ); whats this doing? Particularly when the
expression its acting on is a closure that returns nothing? (at
least as far as I can see)
C) The closure expression:
(inout int = 0) {
// Check to see if I can do InputRangy stuff...
}
Why is there a need for that inout int = 0 clause at the start of
it?
Sorry for the long question!
Thanks,
Colin
Re: Can you explain this?
On Wed, 20 Aug 2014 20:01:03 +, Colin wrote:
It looks veryhacky.
I see 3 distinct parts playing a role in my confusion:
A) The 'is' keyword. What does it do when you have is(expression);
B) typeof( expression ); whats this doing? Particularly when the
expression its acting on is a closure that returns nothing? (at least as
far as I can see)
C) The closure expression:
(inout int = 0) {
// Check to see if I can do InputRangy stuff...
}
Why is there a need for that inout int = 0 clause at the start of it?
Sorry for the long question!
Thanks,
Colin
Before the introduction of __traits(compiles, ...), `is(typeof(...))` was used.
It works because the is expression evaluates to false if the contents don't have
a type or are semantically invalid. So this code creates a delegate to test
the various properties--if it would compile, the delegate has a type and `is`
returns true.
The inout int parameter is very hacky, see this thread:
http://forum.dlang.org/thread/opykgvxbqqeleuikt...@forum.dlang.org#post-mailman.102.1396007039.25518.digitalmars-d-learn:40puremagic.com
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:01:05 UTC, Colin wrote:
I see 3 distinct parts playing a role in my confusion:
A) The 'is' keyword. What does it do when you have
is(expression);
http://dlang.org/expression.html#IsExpression
It is a tool for type checking. It has many options but plain
`is(T)` checks if `T` is a valid type and returns `true` if it
is. `void` is considered a valid type.
B) typeof( expression ); whats this doing? Particularly when
the expression its acting on is a closure that returns nothing?
(at least as far as I can see)
typeof(() {}) evaluates to void:
static assert(is(typeof(() {}) == void));
However, if any compilation errors happen inside the delegate, it
evaluates to special invalid type which yield `false` when
supplied to `is` expression.
Thus `is(typeof(expr))` is a way to express a concept if `expr`
compiles. Delegate is necessary to test statements because
`typeof` only accepts expressions.
C) The closure expression:
(inout int = 0) {
// Check to see if I can do InputRangy stuff...
}
Why is there a need for that inout int = 0 clause at the start
of it?
Now this is a really weird one. This is necessary for input
ranges with `inout` functions to fit the trait because `inout`
variables can be declared only inside `inout` functions. See this
bug report for details :
https://issues.dlang.org/show_bug.cgi?id=7824
It is one of surprising feature inter-operation cases you don't
expect when designing features :)
No Output with shebang.
#!/usr/bin/gdc
import std.stdio;
void main()
{
writeln(Hello, world with automated script running!);
}
When I compile the code above normal to an a.out binary it runs
like expected. But running it with shebang it does nothing. No
output, especially no error message. Nothing.
What do I wrong?
Re: No Output with shebang.
On Wednesday, 20 August 2014 at 20:21:13 UTC, anonymous wrote:
On Wednesday, 20 August 2014 at 20:17:49 UTC, Newbie wrote:
#!/usr/bin/gdc
import std.stdio;
void main()
{
writeln(Hello, world with automated script running!);
}
When I compile the code above normal to an a.out binary it runs
like expected. But running it with shebang it does nothing. No
output, especially no error message. Nothing.
What do I wrong?
gdc just compiles the program to a.out. It doesn't run the
resulting executable. You need to use something like rdmd
instead
of gdc. rdmd compiles to some temporary location and then runs
the executable.
Wow, that was fast. Thanks a lot!
Re: No Output with shebang.
On Wednesday, 20 August 2014 at 20:17:49 UTC, Newbie wrote:
#!/usr/bin/gdc
import std.stdio;
void main()
{
writeln(Hello, world with automated script running!);
}
When I compile the code above normal to an a.out binary it runs
like expected. But running it with shebang it does nothing. No
output, especially no error message. Nothing.
What do I wrong?
gdc just compiles the program to a.out. It doesn't run the
resulting executable. You need to use something like rdmd instead
of gdc. rdmd compiles to some temporary location and then runs
the executable.
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:12:58 UTC, Justin Whear wrote:
On Wed, 20 Aug 2014 20:01:03 +, Colin wrote:
It looks veryhacky.
I see 3 distinct parts playing a role in my confusion:
A) The 'is' keyword. What does it do when you have
is(expression);
B) typeof( expression ); whats this doing? Particularly when
the
expression its acting on is a closure that returns nothing?
(at least as
far as I can see)
C) The closure expression:
(inout int = 0) {
// Check to see if I can do InputRangy stuff...
}
Why is there a need for that inout int = 0 clause at the start
of it?
Sorry for the long question!
Thanks,
Colin
Before the introduction of __traits(compiles, ...),
`is(typeof(...))` was used.
is(typeof(foo)) and __traits(compiles, foo) are not the same. The
first tests for the existence of the symbol, whereas the second
checks whether the code will actually compile. In most cases,
there's no real difference, but if you're trying to use a symbol
in a context where it's not legal (e.g. using a private variable
that you don't have access to), then the is expression will pass,
whereas the _traits(compiles.. will fail. At least in Phobos,
is(typeof... is used far more freqently than __traits(compiles...
The trait is used almost exclusively in unit tests, not in
template constraints or in user-defined traits such as
isInputRange.
- Jonathan M Davis
new error message in 2.066, type bool (const)
Re-compiling existing code with version 2.066 generates a lot of
errors complaining about implicit conversion to const. Typical is
this call (inside a struct with properties 1 2):
z.sign = x.sign ^ y.sign;
Error: None of the overloads of 'sign' are callable using
argument types bool (const), candidates are:
1) @property
@safe
bool sign() const
{
return signed;
}
2) @property
@safe
bool sign(in bool value)
{
signed = value;
return signed;
}
What changed? It ran okay with early beta versions, but not with
the release.
Paul
Re: delegates GC allocations
On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive. Or if it refers to any state of the parent function.
Re: No Output with shebang.
gdc just compiles the program to a.out. It doesn't run the resulting executable. You need to use something like rdmd instead of gdc. rdmd compiles to some temporary location and then runs the executable. Wow, that was fast. Thanks a lot! Can compiler switches be used with the shebang notation? If yes, there is certainly a GDC flag (-run?) that tells it to run the generated executable.
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:39:42 UTC, Jonathan M Davis
wrote:
is(typeof(foo)) and __traits(compiles, foo) are not the same.
The first tests for the existence of the symbol, whereas the
second checks whether the code will actually compile.
Is that even true? I mean, are you just repeating something
you've heard, or have you checked? is(typeof(foo)) has always
failed for me merelly if foo fails to compile. foo being an
existing (but private) symbol is enough.
Test case:
//
module foo;
struct S
{
private int i;
}
//
import foo;
void main(string[] args)
{
S s;
writeln(is(typeof(s.i)));
writeln(__traits(compiles, s.i));
}
//
This says false, false.
I've yet to find a usecase where is(typeof(...)) and
__traits(compiles, ...) aren't interchangeable.
I mean, I may have missed something, but it seems the whole
private thing is just miss-information.
Re: delegates GC allocations
On Wednesday, 20 August 2014 at 20:48:38 UTC, Chris Nicholson-Sauls wrote: On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive. Or if it refers to any state of the parent function. As long as the compiler knows where it will be called from it should be able use a stack pointer offset (unless alloca gets in the way) without the frame pointer of the parent.
Re: new error message in 2.066, type bool (const)
On Wednesday, 20 August 2014 at 20:46:20 UTC, Paul D Anderson
wrote:
Re-compiling existing code with version 2.066 generates a lot
of errors complaining about implicit conversion to const.
Typical is this call (inside a struct with properties 1 2):
z.sign = x.sign ^ y.sign;
Error: None of the overloads of 'sign' are callable using
argument types bool (const), candidates are:
1) @property
@safe
bool sign() const
{
return signed;
}
2) @property
@safe
bool sign(in bool value)
{
signed = value;
return signed;
}
What changed? It ran okay with early beta versions, but not
with the release.
Paul
Could you provide a short, but complete program that reproduces
the issue? With this:
//
struct S
{
bool signed;
@property
@safe
bool sign() const
{
return signed;
}
@property
@safe
bool sign(in bool value)
{
signed = value;
return signed;
}
}
void main(string[] args)
{
S s;
s.sign = s.sign ^ s.sign;
}
//
It works for me with both 2.065.0 and 2.066.0.
What is the type of signed ? Is it something other than bool,
by any chance?
Re: delegates GC allocations
On Wednesday, 20 August 2014 at 21:19:18 UTC, Ola Fosheim Gr wrote: On Wednesday, 20 August 2014 at 20:48:38 UTC, Chris Nicholson-Sauls wrote: On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: Only if it is recursive. Or if it refers to any state of the parent function. As long as the compiler knows where it will be called from it should be able use a stack pointer offset (unless alloca gets in the way) without the frame pointer of the parent. Well, I guess simple recursion could be solved easily too by having a wrapper function that puts the frame pointer in a free callee save register...
Re: delegates GC allocations
On 2014-08-20 5:25 PM, Ola Fosheim Gr wrote: Well, I guess simple recursion could be solved easily too by having a wrapper function that puts the frame pointer in a free callee save register... So, my question inspired a new optimization? :-p
Re: Can you explain this?
On Wednesday, 20 August 2014 at 21:06:49 UTC, monarch_dodra wrote:
On Wednesday, 20 August 2014 at 20:39:42 UTC, Jonathan M Davis
wrote:
is(typeof(foo)) and __traits(compiles, foo) are not the same.
The first tests for the existence of the symbol, whereas the
second checks whether the code will actually compile.
Is that even true? I mean, are you just repeating something
you've heard, or have you checked? is(typeof(foo)) has always
failed for me merelly if foo fails to compile. foo being an
existing (but private) symbol is enough.
Test case:
//
module foo;
struct S
{
private int i;
}
//
import foo;
void main(string[] args)
{
S s;
writeln(is(typeof(s.i)));
writeln(__traits(compiles, s.i));
}
//
This says false, false.
I've yet to find a usecase where is(typeof(...)) and
__traits(compiles, ...) aren't interchangeable.
I mean, I may have missed something, but it seems the whole
private thing is just miss-information.
Well, hereas an example of them not being the same:
---
import std.stdio;
struct S
{
static void foo()
{
writeln(is(typeof(this)));
writeln(__traits(compiles, this));
}
}
void main()
{
S.foo();
}
---
I originally found out about it from Don here:
https://issues.dlang.org/show_bug.cgi?id=8339
I don't know why your example doesn't show them as different. But
we should probably change it so that they _are_ the same - either
that or document their differences explicitly and clearly, but I
don't know why the is(typeof.. behavior here would be desirable.
Maybe so that we could do type(this) to declare a local variable
of the class type generically? I don't know. They're _almost_ the
same but not quite, and I don't know what the exact differences
are. Pretty much all I have to go on is Don's explanation in that
bug report.
- Jonathan M Davis
Re: delegates GC allocations
On Wednesday, 20 August 2014 at 21:30:41 UTC, Etienne wrote: So, my question inspired a new optimization? :-p A decent optimizing compiler would detect that the function is calling itself and save stack space by using register where possible...
Produce some COFF object with 2.066 ?
Hello, I've been very interested about the announce saying that DMD is able to produce COFF object files. Mostly because I'm thinking using some objects programmed in D in a software programmed in another lang, a bit like when statically linking a dll to a program but with an obj, to keep a nice monolithic executable. First thing: I've tried a simple thing: compile an exported function with the args myfile.d -c -ms32mscoff and dmd complains that -ms32mscoff is not a recognized switch. Second thing: If I understand well, it means that previously, to link D a object with a soft programmed in another lang was not possible because the OMF objs don't include everything (e.g the objs coming from other imported static libs) and that now it's faisable ? right ?
Re: Produce some COFF object with 2.066 ?
On Wednesday, 20 August 2014 at 23:56:23 UTC, Baz wrote: Hello, I've been very interested about the announce saying that DMD is able to produce COFF object files. Mostly because I'm thinking using some objects programmed in D in a software programmed in another lang, a bit like when statically linking a dll to a program but with an obj, to keep a nice monolithic executable. First thing: I've tried a simple thing: compile an exported function with the args myfile.d -c -ms32mscoff and dmd complains that -ms32mscoff is not a recognized switch. 32-bit COFF is only in git master currently. It'll be in 2.067 when that comes out. 64-bit COFF has been in dmd for quite some time now. You just have to have a copy of Visual Studio installed (the free Express edition should be fine) and compile with -m64. Second thing: If I understand well, it means that previously, to link D a object with a soft programmed in another lang was not possible because the OMF objs don't include everything (e.g the objs coming from other imported static libs) and that now it's faisable ? right ? They'd just have to both be OMF format if you wanted to statically link. If you had a DLL you could create an import library from the DLL and still link that just fine. Walter has a tool on Digital Mars to do it. Now you should be able to directly link to COFF libraries.
Re: Variadic parameter of length 1
On Wed, 20 Aug 2014 17:47:36 + monarch_dodra via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Yeah, what he said. It's a language artifact. by the way, it would be nice to have wiki page with such artifacts and their explanations. signature.asc Description: PGP signature
Re: No Output with shebang.
On Wed, 20 Aug 2014 23:03:48 +0200 Philippe Sigaud via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Can compiler switches be used with the shebang notation? If yes, there is certainly a GDC flag (-run?) that tells it to run the generated executable. it's possible to use switches, but GDC is not fitted for such usage anyway. it will not automatically compile included modules, it will not automatically put the binary in predefined place and so on. ah, dmd is not suitable for such usage too, that's why we have rdmd. rdmd can be adapted to use GDC (if compiled with GDC, rdmd will use gdmd instead of dmd), but dmd is faster and the quality of generated code is not so important in scripts. signature.asc Description: PGP signature
Re: new error message in 2.066, type bool (const)
What changed? It ran okay with early beta versions, but not with the release. Paul It compiles in beta-5 but not beta-6. Is the list of changes in the beta testing wiki complete? None seem pertinent. monarch_dodra: Thanks for checking. I was trying to avoid tearing everything down. I was hoping someone would recognize the error. Looks like I'll have to chase it down. Paul
D with no druntime
Hi All, I am playing with a small hack OS for fun and in 2066 there are these undefined refs (I have no druntime): _d_arraybounds (new to 2066) _d_assert (new to 2066) _d_unittest (new to 2066) _Dmodule_ref (also in 2065) _d_dso_registry (also in 2065) It is trivial to stub these out but it got me wondering... Is there any way to compile D that has no dependencies? Thanks, uri
onDispatch demo not compiling
I'm trying to compile the onDispatch demo program from The D
Programming Language (page 387). At first I had an import
problem, but I fixed that. Now, however, when I try to call
a.do_something_cool, I get an error message saying:
onDispatch.d(43): Error: no property 'do_something_cool' for type
'onDispatch.A'
Full program follows (into onDispatch.d):
import core.stdc.ctype;
import std.stdio;
string underscoresToCamelCase(string sym) {
string result;
result.reserve(sym.length);
bool makeUpper;
foreach (c; sym) {
if (c == '_') {
makeUpper = true;
} else {
if (makeUpper) {
result ~= toupper(c);
makeUpper = false;
} else {
result ~= c;
}
}
}
return result;
}
unittest {
assert(underscoresToCamelCase(hello_world) == helloWorld);
assert(underscoresToCamelCase(_a) == A);
assert(underscoresToCamelCase(abc) == abc);
assert(underscoresToCamelCase(a_bc_d_) == aBcD);
}
class A {
auto onDispatch(string m, Args...)(Args args) {
// return
mixin(this.~underscoresToCamelCase(m)~(args));
}
void doSomethingCool(int x, int y) {
writeln(Do something cool);
}
}
unittest {
auto a = new A;
a.doSomethingCool(5, 6);
a.do_something_cool(5, 6);
}
