dmd (>2.068) compiler error
Unsure of exactly how to communicate this one, so posting here. Compilation of https://github.com/dcarp/asynchronous. Using 'dub --verbose build' produces: dmd -lib -of.dub/build/library-debug-linux.posix-x86_64-dmd_2071-7450FEAE5605F646044C35441C27D67E/libasynchronous.a -debug -g -w -version=CryptoSafe - version=Have_asynchronous -version=Have_libasync -version=Have_memutils -Isrc/ -I../../../../.dub/packages/libasync-0.7.9/libasync/source/ - I../../../../.dub/packages/memutils-0.4.6/memutils/source/ src/asynchronous/events.d src/asynchronous/futures.d src/asynchronous/libasync/events.d src/asynchronous/locks.d src/asynchronous/package.d src/asynchronous/protocols.d src/asynchronous/queues.d src/asynchronous/streams.d src/asynchronous/tasks.d src/asynchronous/transports.d src/asynchronous/types.d -vcolumns Enhanced memory security is enabled. Memory debugger enabled ../../../../.dub/packages/libasync-0.7.9/libasync/source/libasync/internals/socket_compat.d(57,16): Deprecation: module std.c.linux.socket is deprecated - Import the appropriate core.sys.posix.* modules instead Using Linux EPOLL for events (successful compile) So far, so good. However, if I do not use dub to compile the code, and compile into individual object files, then for the following file: /usr/bin/dmd -ofbuild/events.d.o -debug -g -w -version=CryptoSafe -version=Have_asynchronous -version=Have_libasync -version=Have_memutils -Isrc - I../../../../.dub/packages/memutils-0.4.6/memutils/source/ -I../../../../.dub/packages/libasync-0.7.9/libasync/source/ -c src/asynchronous/libasync/events.d for any dmd >2.068 causes the following error: dmd: glue.c:809: void FuncDeclaration_toObjFile(FuncDeclaration*, bool): Assertion `fd->semanticRun == PASSsemantic3done' failed. Aborted However, it works find for dmd.2.068. Any ideas?
Re: A better way than foreach with this?
try: auto names1 = names.map!( a = replace(a, _, )); ...not sure how to do it in-place though. Joel wrote: auto names = Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split; foreach (ref name; names) name = replace(name, _, );
Re: Templates and writing variable number of arguments
try replacing:
final void output(T)(string text, T params...) const {
with
final void output(T...)(string text, T params) const {
Andre Polykanine via Digitalmars-d-learn wrote:
Hi everyone,
It's me again.
Now I'm struggling with the `output` member function which should
output a string either to stdout or to a file, depending on the
parameter.
However, I would like it to work like `writefln` with variable number
of arguments:
output(Hello %s!, world); // should be OK
output(%s %s: %s %d times, I, say, Hello world!, 500); //
Should also be OK
Here is my code:
final void output(T)(string text, T params...) const {
if (this.outFile == ) {
writefln(text, params);
} else { // Output to a file
auto f = File(this.outFile, w);
try {
f.writefln(text, params);
} catch(Exception e) {
writefln(Unable to write to %s: %s,
this.outFile, e.msg);
}
}
}
And the compiler says it can't deduce the type of arguments.
What am I doing wrong here?
Maybe, I don't need such a function and all and there is a way to make
it more elegant?
Thanks!
Re: Wiki article: Starting as a Contributor
I confess to being a bit confused overall - there is a bit of overlap and confusion for someone who wishes to venture into this area. Please bear with me: From wiki.dlang.org - 'Get involved'. So far so good. From here, I can go to 'Building DMD' and 'How to Fork and Build dlang.org', which both seem to build DMD - I'm unsure of the overlap aspects here. There is also an issue with the set of instructions in 'How to Fork and Build dlang.org' - and I don't know what category to file the bug under in bugzilla !?). Now, where does 'Starting as a Contributor' fit? --ted - $ git clone https://github.com/D-Programming-Language/dlang.org $ git clone https://github.com/D-Programming-Language/dmd $ cd dlang.org/ $ make -f posix.mak html $ make -f posix.mak druntime-release From https://github.com/D-Programming-Language/dmd * branchHEAD - FETCH_HEAD LATEST=2.068.0 -- place in the command line to skip network traffic. [ -d ../druntime-2.068.0 ] || git clone -b v2.068.0 --depth=1 https://github.com/D-Programming-Language/druntime ../druntime-2.068.0/ Cloning into '../druntime-2.068.0'... remote: Counting objects: 412, done. remote: Compressing objects: 100% (372/372), done. remote: Total 412 (delta 42), reused 154 (delta 30), pack-reused 0 Receiving objects: 100% (412/412), 959.29 KiB | 564.00 KiB/s, done. Resolving deltas: 100% (42/42), done. Checking connectivity... done. Note: checking out '0ca25648947bb8f27d08dc618f23ab86fddea212'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name touch ../druntime-2.068.0/.cloned make --directory=../dmd-2.068.0/src -f posix.mak -j 4 make[1]: *** ../dmd-2.068.0/src: No such file or directory. Stop. posix.mak:338: recipe for target '../dmd-2.068.0/src/dmd' failed make: *** [../dmd-2.068.0/src/dmd] Error 2 Andrei Alexandrescu wrote: I had to set up dmd and friends on a fresh Ubuntu box, so I thought I'd document the step-by-step process: http://wiki.dlang.org/Starting_as_a_Contributor Along the way I also hit a small snag and fixed it at https://github.com/D-Programming-Language/dlang.org/pull/1049 Further improvements are welcome. Thanks, Andrei
Re: Wiki article: Starting as a Contributor
cheers for that - that differentiation/distinction wasn't clear (to me). anonymous wrote: On Saturday 22 August 2015 11:05, ted wrote: From here, I can go to 'Building DMD' and 'How to Fork and Build dlang.org', which both seem to build DMD - I'm unsure of the overlap aspects here. The 'dlang.org' project is the website. It deals with building dmd only insofar as you need a compiler to build the website. If your goal is to build dmd, don't bother with anything 'dlang.org'. There is also an issue with the set of instructions in 'How to Fork and Build dlang.org' - and I don't know what category to file the bug under in bugzilla !?). Component: dlang.org make --directory=../dmd-2.068.0/src -f posix.mak -j 4 make[1]: *** ../dmd-2.068.0/src: No such file or directory. Stop. posix.mak:338: recipe for target '../dmd-2.068.0/src/dmd' failed make: *** [../dmd-2.068.0/src/dmd] Error 2 This is issue 14915, a regression in 2.068: https://issues.dlang.org/show_bug.cgi?id=14915 As a workaround, you can manually revert the changes done in PR #1050. Though, repeating myself, if your goal is to build dmd, don't bother with dlang.org.
std.traits: ParameterIdentifierTuple on 'interface' not working ?
Is this behaviour expected ?
(dmd2.068, linux 64bit)
dmd -oftest test.d
(string, uint, bool)
tuple(a, b, c)
(string, uint, bool)
tuple(, , )
(i.e. ParameterIdentifierTuple does not appear to work for interfaces? -
what am I doing incorrectly?)
test.d:
import std.traits;
interface IFoo { ulong foo_me(string a, uint b, bool c); }
class myFoo:IFoo{ ulong foo_me(string a, uint b, bool c){ return 42; } }
void main()
{
auto tmp_foo = new myFoo;
alias ParameterTypeTuple!(tmp_foo.foo_me) tmpfooTypes;
pragma(msg,tmpfooTypes);
alias ParameterIdentifierTuple!(tmp_foo.foo_me) tmpfooNames;
pragma(msg,tmpfooNames);
foreach ( method; __traits(allMembers, IFoo))
{
alias MemberFunctionsTuple!(IFoo, method) funcs;
alias typeof(funcs[0]) func;
alias ReturnType!func return_type;
alias ParameterTypeTuple!func ParameterTypes;
alias ParameterIdentifierTuple!func ParameterNames;
pragma(msg,ParameterTypes);
pragma(msg,ParameterNames);
}
}
Re: SList container problem
thanks for the reply...
the method you described is suitable for appending to an array, but I'm
using the singly-linked-list container.
I've extended the test, and I'm pretty sure it's a bug...
--ted
Nicholas Wilson wrote:
On Thursday, 13 August 2015 at 08:40:13 UTC, ted wrote:
have upgraded from 2.066.1 to 2.068.0, and have a change in
behaviour:
import std.container: SList;
void main()
{
SList!int tmp;
tmp.insertAfter( tmp[], 3 );
}
used to work happily with dmd2.066.1, causes assert
(core.exception.AssertError@std/container/slist.d(57):
Assertion failure) in 2.068.0 (also 2.067.1).
There was a change in slist.d in 2.067. Am I no longer able to
start from an empty list?
--ted
tmp ~= 3; ?
Bug in std.container: SList
Hi,
(earlier posting on D.learn, but better test included here)...
dmd.2.067, dmd.2068 (64bit linux)
import std.container: SList;
void main()
{
SList!int tmp=( 4 );
SList!int tmp1;
// Ensure tmp is empty
tmp.removeAny();
assert( tmp.empty == true );
// Both tmp and tmp1 are empty
// (however tmp1 is not internally initialised)
tmp.insertAfter( tmp[], 3 );
//tmp1.insertAfter( tmp1[], 3 );== asserts here.
}
core.exception.AssertError@std/container/slist.d(57): Assertion failure
Changes in phobos mean that you cannot append to an _uninitialised_ empty
singly linked list (you can, however, append to an _initialised_ empty
linked list.
bug ?
--ted
SList container problem
have upgraded from 2.066.1 to 2.068.0, and have a change in behaviour:
import std.container: SList;
void main()
{
SList!int tmp;
tmp.insertAfter( tmp[], 3 );
}
used to work happily with dmd2.066.1, causes assert
(core.exception.AssertError@std/container/slist.d(57): Assertion failure)
in 2.068.0 (also 2.067.1).
There was a change in slist.d in 2.067. Am I no longer able to start from
an empty list?
--ted
Re: Making RCSlice and DIP74 work with const and immutable
Andrei Alexandrescu wrote: We have a few candidates for solutions, but wanted to open with a good discussion first. So, how do you envision a way to define and access mutable metadata for objects (including immutable ones)? Andrei It seems to me that (in the particular case of _this_ RC metadata - not attempting to cover any more general case (beyond my ken)), the compiler could internally mark class members that are modified inside the opAddRef/opRelease methods as mutable. This would not require any special source code markups. --ted
Re: DIP74: Reference Counted Class Objects
Andrei Alexandrescu wrote: On 2/27/15 1:09 AM, ted wrote: Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei Trivial typos: struct, class, and closure types that have RCO members accommodate calls to Release during their destruction. s/Release/opRelease/ Explicit casting to of from void* does not entail a call to opAddRef. s/of/or/ also: s/opReleasecalls/opRelease calls/ The examples in Defining a reference counted object with deallocation, and defining a type that owns resources both define '_refs', and manipulate 'refs'. Fixed, thanks! This is probably a really stupid question, but how does the 'new' work for an RCO. I assume it uses the GC memory allocation system, but must mark it as 'not for collection' (or similar), for the GC.free() call to work (as used in the examples). DIP74 does not prescribe specific allocation techniques. They are left to the user. I'm still a bit confused here: the examples in DIP74 showed the freeing of memory via 'GC.free(cast(void*) this);' - so I had assumed that 'Widget a = new Widget' would be the way it was created? (and that automatically uses GC - or is this what I am missing?) I can see how a system that used (for example) malloc/calloc/free would work, I'm just querying the consistency of the examples within DIP74? One nice point of the design space would be to use the GC for allocation and early deallocation, in such a way that the GC is still able to collect cycles. Probably another silly question: How would the examples work with const/immutable (using examples in howtos)? e.g. const Widget a = new Widget; auto b = a;-- mutable method Widget.opAddRef is not callable using a const object This is tricky. I meant to discuss it; for now I planted a TODO. Andrei
Re: DIP74: Reference Counted Class Objects
Andrei Alexandrescu wrote: http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss. Thanks, Andrei Trivial typos: struct, class, and closure types that have RCO members accommodate calls to Release during their destruction. s/Release/opRelease/ Explicit casting to of from void* does not entail a call to opAddRef. s/of/or/ also: s/opReleasecalls/opRelease calls/ The examples in Defining a reference counted object with deallocation, and defining a type that owns resources both define '_refs', and manipulate 'refs'. This is probably a really stupid question, but how does the 'new' work for an RCO. I assume it uses the GC memory allocation system, but must mark it as 'not for collection' (or similar), for the GC.free() call to work (as used in the examples). Probably another silly question: How would the examples work with const/immutable (using examples in howtos)? e.g. const Widget a = new Widget; auto b = a;-- mutable method Widget.opAddRef is not callable using a const object
cannot deduce function from argument types issue.
Hi!
I get the following compile error (linux, dmd2.066.1):
test.d(13): Error: template test.testFunc cannot deduce function from
argument types !()(double[], double), candidates are:
test.d(3):test.testFunc(R)(R range, ElementType!R foo)
For the following test file:
import std.range: ElementType, isInputRange;
ElementType!R testFunc(R)( R range, ElementType!R foo) // compiles with
double foo
{
static assert( isInputRange!R );
ElementType!R retVal = foo*foo;
return retVal;
}
void main()
{
double[] values = [0.0, 3.0, -1.0, 5.0];
auto result = testFunc( values, 8.8 );
}
And I'm not sure what I'm doing incorrectly. It compiles/works fine if I
hardcode the type for foo.
Could someone enlighten me ?
regards,
ted
Re: cannot deduce function from argument types issue.
Ali Çehreli wrote: On 02/10/2015 12:31 AM, ted wrote: ElementType!R testFunc(R)( R range, ElementType!R foo) // compiles with double foo If think it is a little too much to ask from the template system of D. A proper way of doing the same thing is to use a template constraint: ElementType!R testFunc(R, E)( R range, E foo) if (is (E : ElementType!R)) Ali thanks !
Re: cannot deduce function from argument types issue.
bearophile wrote:
ted:
Could someone enlighten me ?
This works:
import std.range: ElementType, isInputRange;
ElementType!R testFunc(R, T)(R range, T foo)
if (is(ElementType!R == T)) {
static assert(isInputRange!R);
typeof(return) retVal = foo ^^ 2; // More DRY.
return retVal;
}
void main() {
auto values = [0.0, 3.0, -1.0, 5.0];
auto result = testFunc(values, 8.8);
}
The D compiler seems unable to compute ElementType!R in the
function signature. If I am right, then this seems worth an
enhancement request.
Bye,
bearophile
thanks !...
... where you say 'More DRY' above, are you referring to
- foo^^2 ( I just did foo*foo for the sake of the example), or
- typeof(return) - a construct I am completely unfamiliar with and will
now have to look up !
If it is 'typeof(return)' why would this be selected over ElementType!R ??
Is it more idiomatic ?
regards,
ted
Re: cannot deduce function from argument types issue.
bearophile wrote: ted: ... where you say 'More DRY' above, are you referring to I was referring to both, but mostly to the typeof. It's more DRY (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself ). You are stating only once the type of the return variable. This is less bug-prone. Bye, bearophile Ha ! ..more stuff to learn! many thanks... regards, ted
Re: cannot modify struct with immutable members
Ali Çehreli wrote: On 01/02/2015 10:10 PM, ted wrote: I'm now taking the view that const is there for the compiler to optimise code on the basis that nothing can alter it once set (and can only be set on initialisation). Of course, that is true for const values, not for const references. In the latter case it means I will not modify but others may modify, so the optimization that you mention does not apply to const in general. However, immutable can be used for optimization. Ali thats (sort of) where I had started from. My (clearly incorrect) interpretation was that reinitialising 'myTest1' was part of the 'others may modify' category because of the fact that it was in scope of the _someFunc function ...anywaylots to learn. BTW: your book is excellent, and as soon as you have it available for purchase I will certainly be buying a copy.
Re: Weird UFC and opCall issues
Darrell wrote:
Seems when creating your own ranges they can't be a class.
Must be a struct or Segmentation fault (core dumped) will follow.
This works as long as Test is a struct.
struct Test
{
@property int front()
{
return 2;
}
void popFront()
{
}
enum bool empty = false;
};
static assert(isInputRange!Test);
void mainx(){
Test x;
writeln(x.take(1));
}
With classes, you need to create an instance, so (adjusting some of your
previous code) this works:
import std.range;
import std.stdio;
class Test
{
@property int front()
{
return 2;
}
void popFront()
{
}
@property bool empty()
{
return false;
}
};
static assert(isInputRange!Test);
void main(){
ubyte [] p1;
Test myTest = new Test();
writeln(myTest.take(1));
}
Re: cannot modify struct with immutable members
ketmar via Digitalmars-d-learn wrote:
On Sat, 03 Jan 2015 14:45:24 +1030
ted via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Well, I just cleared up some of my misunderstanding.
I did not realise the mA (within struct Test) would be a _copy_ of arg,
not a reference (pointer) to arg.
So the more correct code snippet would be:
struct A
{
int someInt;
}
struct Test
{
@property { const(A) getA() { return *mA; } }
this( in A arg )
{
mA = arg;
}
private:
const A* mA;
}
void main()
{
Test myTest1;
A topA;
topA.someInt = 100;
void _someFunc( in A myA )
{
myTest1 = Test(myA);
}
Test myTest2 = Test(topA); // is ok as expected
_someFunc( topA );
}
nonononono! ;-)
please, don't use pointers like this. try to avoid pointers altogether,
they are VERY dangerous. as for your sample: it is already invalid. see:
this (in A arg) { mA = arg; }
you are storing the address of *local* *var* *from* *stack* here. then
local will go out of scope and... BANG! everyone is dead.
Oops...true (*blush*) - should have noticed this.
This code snippet is me trying to understand whether I have a
fundamental misunderstanding with const, or whether it is an issue with
the compiler
seems that you didn't get D `const`. it's deffers from C/C++ `const`.
in most cases you don't need to use it at all. the funny thing of D
const is that const variable cannot be changed in any way after
assigning. that's why compiler complains: you're trying to change
variable with `const` part, which is forbidden.
structure instance with const fields can be initialized only once, upon
creation. so did `Test myTest1;` -- you initialized `myTest1` with
default values. you can't reinitialize it later.
in C++ constness on member doesn't impose such restrictions. this is
confusing for newcomers with C/C++ expirience. the best advice here is
don't use `const` in D unless you are fully understand what you are
doing and how it work in D.
Ironically, I'm trying to use const in an effort to understand it...but
there seems to be an unusual amount of pain until I grok it.
I'm happy I've got a workaround (which seems to safely preserve the
const'dness), but I still don't understand why the compiler barfs on the
struct version as it should be 'replacing' the higher scoped
variable
you don't need `const` here at all. as far as i can see you want to
tell the compiler that `mA` must not be changed after creating a
struct. to achieve that you'd better move your struct to separate
module and provide read-only getter.
you need to move your struct to separate module 'cause `private`
modifier will not affect the code in the same module. one of the D
rules is that the code in one module can access anything that was
declared in the same module, including private members of
structs/classes. C++ tries to achieve that with friend members, but
as D has full-fledged module system, it doesn't need such tricks.
tl;dr: don't use `const` here, provide an accessor and stop
worrying/helping the compiler. ;-)
Yeah.its one of those cases where the prototype code is getting too
ugly, and a refactorisation is required.but no time !!
many thanks,
ted
Re: cannot modify struct with immutable members
Hi,
thanks for the reply...to answer your direct question, the original code
looked like:
struct A
{
int someInt;
}
struct Test
{
@property { const(A) getA() { return mA; } }
this( ref const(A) arg )
{
mA = arg;
}
private:
A mA;
}
void main()
{
Test myTest1;
A topA;
void _someFunc( ref const(A) myA )
{
myTest1 = Test(myA);
}
Test myTest2 = Test(topA); // is ok as expected
_someFunc( topA );
// later on
A foo = myTest1.getA();
}
which compiles. However, I think I exercised some other compiler-related
bug when I added a field to another structure in the module, and the
compiler started complaining about the construct above...
'Error: cannot implicitly convert expression (arg) of type const(A) to A'
in the constructor of Test (I'm unable to recreate this error in this
simple code example).
(I am prototyping something, so the code I'm producing is very badly
structured, and I have nested functions within delegates within and I
have also hit some odd scoping errors - definite compiler issues -
(notwithstanding the horrible code structure)).
so (given my D knowledge is limited) I then wondered why it accepted
(nonconst)mA=(const)arg in the first place, hence the const()...hence the
original question.
I am assuming that the ref const(A) myA means that _someFunc (and below) is
unable to alter any fields of myA. This may be my basic error.
thanks !
ketmar via Digitalmars-d-learn wrote:
On Sat, 03 Jan 2015 13:25:31 +1030
ted via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
I get the following error from the code below: (dmd2.066.1, linux)
test.d(26): Error: cannot modify struct myTest1 Test with immutable
members
Is this expected?
If so, how can I achieve this result - being able to set (a new) initial
value of myTest1 from within an nested function ?
thanks !
ted
code:
struct A
{
int someInt;
}
struct Test
{
this( ref const(A) arg )
{
mA = arg;
}
private:
const(A) mA;
}
void main()
{
Test myTest1;
A topA;
void _someFunc( ref const(A) myA )
{
myTest1 = Test(myA);
}
Test myTest2 = Test(topA); // is ok as expected
_someFunc( topA ); // error.
}
the question is: why do you want `mA` to be const? leaving aside
compiler complaints this is the one and important question. let's try
to fix your code instead of devising workarounds to beat the
compiler. ;-)
please remember that D `const` is not the same as C/C++ `const`, so my
question is not so stupid as it may look.
p.s. you can use `in A myA` instead of `ref const A myA`, in most cases
compiler is intelligent enough to use pass-by-reference for `in` args.
Re: cannot modify struct with immutable members
ketmar via Digitalmars-d-learn wrote: On Sat, 03 Jan 2015 15:56:58 +1030 ted via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Ironically, I'm trying to use const in an effort to understand it...but there seems to be an unusual amount of pain until I grok it. just remember that `const` infects everything down to the bytes when it's applied. and it's forbidden to overwrite `const` vars with different values. in your canse it infects your `A` struct, effectively converting it to `const A` (with `const int someInt`). and as you can't change consted value, and structs are `memcpy()`ed... compiler tracked that down and refused to do it. so you don't really need `const` fields in D. you can make getters `const` though, so that they can be used on `const MyStruct` instances. so two rules should help you here: 1. it's forbidden to overwrite `const` vars with new values. 2. `const` will infect everything down to bytes. maybe this will help you like it helps me. ;-) Thanks for your helpbesides the issues that you pointed out, I had forgotten that structs are always copied (I'm so used to thinking in pointers (if you ignore the fubar from my earlier example) - and a world where copying data structures is an expensive exercise to be avoided)... I'm now taking the view that const is there for the compiler to optimise code on the basis that nothing can alter it once set (and can only be set on initialisation). So I see your point that it would not be used very often in general defensive code - better to provide access restrictions (getters) for most cases. I am refactoring the code to use getters/setters One of the really good things about D is that it is relatively painless to refactor when you have to - much less boilerplate to have to move around ! thanks again, regards, ted
Re: cannot modify struct with immutable members
Well, I just cleared up some of my misunderstanding.
I did not realise the mA (within struct Test) would be a _copy_ of arg, not
a reference (pointer) to arg.
So the more correct code snippet would be:
struct A
{
int someInt;
}
struct Test
{
@property { const(A) getA() { return *mA; } }
this( in A arg )
{
mA = arg;
}
private:
const A* mA;
}
void main()
{
Test myTest1;
A topA;
topA.someInt = 100;
void _someFunc( in A myA )
{
myTest1 = Test(myA);
}
Test myTest2 = Test(topA); // is ok as expected
_someFunc( topA );
}
which fails to compile for the same reason (test.d(30): Error: cannot
modify struct myTest1 Test with immutable members)
(I have been able to work around my original issue by removing @safe from
Test, and then cast()ing ... but this is ugly)
This code snippet is me trying to understand whether I have a fundamental
misunderstanding with const, or whether it is an issue with the compiler
(I agree with your view that 'fixing my code' is the correct approach, btw
- I'm still curious).
(The reason for this basic structure is that _someFunc is a callback from
another module, and myTest1 contains state information that is
created/adjusted via the callback. And (to be safe) myTest1 contains
references to other structures that it should not adjust - hence the
const()).
and I can't use @safe and pointers..
So, it appears I need to do what I want with classes, not structs:
i.e.
import std.stdio;
class A
{
int someInt;
}
@safe class Test
{
@property { const(A) getA() { return mA; } }
this( in A arg )
{
mA = arg;
}
private:
const A mA;
}
void main()
{
Test myTest1;
A topA = new A;
topA.someInt = 100;
void _someFunc( in A myA )
{
myTest1 = new Test(myA);
}
Test myTest2 = new Test(topA); // is ok as expected
_someFunc( topA );
writeln( topA: , topA.someInt );
writeln( myTest1.A: , myTest1.getA.someInt );
}
I'm happy I've got a workaround (which seems to safely preserve the
const'dness), but I still don't understand why the compiler barfs on the
struct version as it should be 'replacing' the higher scoped variable
anyway...thanks for your response.apologies for the streaming
conciousness of this reply...
cannot modify struct with immutable members
I get the following error from the code below: (dmd2.066.1, linux)
test.d(26): Error: cannot modify struct myTest1 Test with immutable members
Is this expected?
If so, how can I achieve this result - being able to set (a new) initial value
of myTest1 from within an nested function ?
thanks !
ted
code:
struct A
{
int someInt;
}
struct Test
{
this( ref const(A) arg )
{
mA = arg;
}
private:
const(A) mA;
}
void main()
{
Test myTest1;
A topA;
void _someFunc( ref const(A) myA )
{
myTest1 = Test(myA);
}
Test myTest2 = Test(topA); // is ok as expected
_someFunc( topA );// error.
}
Re: D Users Survey: Primary OS?
Tom Browder via Digitalmars-d wrote: Has anyone done a survey of the primary OS of D users? I (a D newbie) use Debian Linux (64-bit), but I get the feeling that many (if not most) users are on some version of Windows. Thanks. Best regards, -Tom Gentoo linux 64-bit
port of Ash to D
Hi, I've made an attempt at porting Richard Lord's Ash component/entity system to D. It was mainly an exercise in learning about component/entity systems. It tries to remain faithful to the API of ash, but there were some aspects of ActionScript that did not map cleanly. It passes all the unit tests - but I've not yet ported the demonstration game (asteroids) to it yet (this will be done when I have time to grok openGL or SDL). Documentation is sparse. Not tested under windows - only linux. If this is of any use to anyone, I'd like to know ! (improvements/suggestions welcome). It has a dub file, and will produce a library using it but not the unit tests. The native build tool is bub - a build tool that will build/test complex projects across multiple languages (currently D/C++/C) (it is a work in progress - e.g. documentation output is lacking) https://github.com/axiom-a/ashd
