I don't know if this post is more fit for the main D newsgroup.
In the end I have decided that it's better to ask here first.
Here inside every instance of Bar there is a reference to an
instance of Foo:
abstract class Something {
int spam(int);
}
class Foo : Something {
int x;
Am 13.07.2013 15:17, schrieb Benjamin Thaut:
m_foo = typeof(m_foo)();
Sorry this line should read:
m_foo = typeof(m_foo)(DefaultCtor());
there should really be some kind of edit option for the newsgroup.
I had the very same problem and I'm using a composite helper struct for
this purpose:
struct DefaultCtor {}; //call default ctor type
struct composite(T)
{
static assert(is(T == class),"can only composite classes");
void[__traits(classInstanceSize, T)] _classMemory = void;
bool m_destruct
(Sorry, this post has gone in this newsgroup by mistake, but it's
a small mistake.)
To change and understand your code a bit (now the ComposeClass
constructor is a template) I have removed some of the tests and
debug code, but they should be added back later:
/*
string listAvailableCtors(T
Am 13.07.2013 17:15, schrieb bearophile:
(Sorry, this post has gone in this newsgroup by mistake, but it's a
small mistake.)
To change and understand your code a bit (now the ComposeClass
constructor is a template) I have removed some of the tests and debug
code, but they should be added back l
I also wanted to mention the "ListAvailableCtors" template which is a
nice addition in case there is no constructor available to be called
with the given arguments. It will generate a list of all aviable ctors
with the types of its arguments, and thus greatly improve the error
message given whe
Benjamin Thaut:
I also wanted to mention the "ListAvailableCtors" template
which is a nice addition in case there is no constructor
available to be called with the given arguments. It will
generate a list of all aviable ctors with the types of its
arguments, and thus greatly improve the error
Benjamin Thaut:
Yes the assignment in this(DefaultCtor) is needed, because the
construction process of a D object is defined as:
OK.
The debugging values are needed because most debuggers won't be
able to evaluate properties while debugging.
OK.
Is that ClassCompose destructor enough (w
On Saturday, 13 July 2013 at 12:47:28 UTC, bearophile wrote:
In C++ class instances are values, so the class Bar can contain
an instance of Foo as a value. This removes one allocation and
one indirection and decreases a bit the pressure on the GC. How
to do the same thing in D? Can I use Scoped
Kagamin:
emplace?
Can you show a little compilable program that solves my problem
using emplace?
Bye,
bearophile
On Saturday, 13 July 2013 at 16:19:06 UTC, Benjamin Thaut wrote:
Yes this looks pretty similar to scoped in phobos but I always
thought that scoped was inteded for objects to be placed on the
stack instead of inside other objects. Thats also why scoped
does some additional alignment which is ga
On Saturday, 13 July 2013 at 17:48:40 UTC, bearophile wrote:
Kagamin:
emplace?
Can you show a little compilable program that solves my problem
using emplace?
Do you want just to construct unique instances of Foo in each Bar
or you want to copy Foo by value like in C++?
Kagamin:
Do you want just to construct unique instances of Foo in each
Bar or you want to copy Foo by value like in C++?
Construct an instance of Foo in Bar is enough.
(Copying Foo is nice but not necessary.)
Bye,
bearophile
Am 13.07.2013 18:41, schrieb bearophile:
Benjamin Thaut:
I also wanted to mention the "ListAvailableCtors" template which is a
nice addition in case there is no constructor available to be called
with the given arguments. It will generate a list of all aviable ctors
with the types of its argume
Am 13.07.2013 18:49, schrieb bearophile:
Benjamin Thaut:
Yes the assignment in this(DefaultCtor) is needed, because the
construction process of a D object is defined as:
OK.
The debugging values are needed because most debuggers won't be able
to evaluate properties while debugging.
OK.
Am 13.07.2013 17:15, schrieb bearophile:
(Sorry, this post has gone in this newsgroup by mistake, but it's a
small mistake.)
To change and understand your code a bit (now the ComposeClass
constructor is a template) I have removed some of the tests and debug
code, but they should be added back l
Benjamin Thaut:
I just noticed that this still does not work. Even with dmd
2.063 I get the error message:
main.d(28): Error: template
main.ComposeClass!(Object).ComposeClass.__ctor(Targs...)(Targs
args) conflicts with constructor
main.ComposeClass!(Object).ComposeClass.this at main.d(20)
Benjamin Thaut:
With my version you will instantly know what ctors are
available and you don't have to go look it up in the sourcecode.
Right. On the other hand this is what happens when you call any
constructor or any overloaded function. So I don't think it's so
important.
One possible d
On Sunday, 14 July 2013 at 12:28:48 UTC, Dicebot wrote:
On Saturday, 13 July 2013 at 12:47:28 UTC, bearophile wrote:
...
P.S. but reading scoped docs I got no idea if this is a legal
safe usage.
Benjamin Thaut:
Trying to use ClassCompose in my code I have had some problems
caused by const classes and ClassCompose dtor. Maybe such dtor
(and isDestructed) can be versioned out for composed-in classes
that only contain values...
Can you give an example for that?
As a simple example try
On Saturday, 13 July 2013 at 12:47:28 UTC, bearophile wrote:
...
Hm, actually naive scoped usage seems to work for me:
---
import std.typecons;
class B
{
byte a;
}
class A
{
typeof(scoped!B()) b = void;
this()
{
Am 14.07.2013 14:03, schrieb bearophile:
Benjamin Thaut:
I just noticed that this still does not work. Even with dmd 2.063 I
get the error message:
main.d(28): Error: template
main.ComposeClass!(Object).ComposeClass.__ctor(Targs...)(Targs args)
conflicts with constructor
main.ComposeClass!(Obj
Am 14.07.2013 14:25, schrieb bearophile:
Benjamin Thaut:
Trying to use ClassCompose in my code I have had some problems caused
by const classes and ClassCompose dtor. Maybe such dtor
(and isDestructed) can be versioned out for composed-in classes
that only contain values...
Can you give an ex
Benjamin Thaut:
Does this actually work for you?
It seems to work. (But in that little program I have found two
new unrelated compiler bugs that don't allow me to compile the
program in an useful way. I have reported both of them in
Bugzilla and one of them has now a patch, so probably I wi
Am 14.07.2013 16:25, schrieb bearophile:
Benjamin Thaut:
Does this actually work for you?
It seems to work. (But in that little program I have found two new
unrelated compiler bugs that don't allow me to compile the program in an
useful way. I have reported both of them in Bugzilla and one of
Benjamin Thaut:
Can you give a link to the two respective bugs please?
I think they are:
http://d.puremagic.com/issues/show_bug.cgi?id=10629
http://d.puremagic.com/issues/show_bug.cgi?id=10632
The first has already a patch, and probably the second is a
regression.
Bye,
bearophile
Dicebot:
Hm, actually naive scoped usage seems to work for me:
---
import std.typecons;
class B
{
byte a;
}
class A
{
typeof(scoped!B()) b = void;
this()
{
b = scoped!B();
}
}
Good. If I com
The warning comes from:
http://dlang.org/changelog.html#staticfields
Namespace:
The warning comes from:
http://dlang.org/changelog.html#staticfields
But is "void" an initializer?
Bye,
bearophile
On Sunday, 14 July 2013 at 15:28:26 UTC, bearophile wrote:
Namespace:
The warning comes from:
http://dlang.org/changelog.html#staticfields
But is "void" an initializer?
Bye,
bearophile
Seems so, but I don't know why. Anyway, it's obviously wrong, you
should fill a bug report.
On Sunday, 14 July 2013 at 15:28:26 UTC, bearophile wrote:
Namespace:
The warning comes from:
http://dlang.org/changelog.html#staticfields
But is "void" an initializer?
Bye,
bearophile
Technically - yes, but I think it should be an exclusion from
general rules mentioned there because of s
On Sunday, 14 July 2013 at 15:17:43 UTC, bearophile wrote:
test.d(4): Error: slice x[] is not mutable
This is almost 100% a bug. I have played a bit with this snippet
and seems like void initialization breaks usual rule that you can
cook const/immutable field in constructor (which is kind of
On 07/14/13 18:24, Dicebot wrote:
> class A
> {
> // immutable int x = void; // works not
`void` is special - yes. But keep in mind that this currently does
not actually do what it intuitively appears to, and what the code
posted in this thread apparently expects. IOW void-initialization
of ag
Ugh, rly? As far as I understand spec it should work like this:
T x; // sets x to T.init
T x = void; // don't initialize x at all, leave garbage
What hole in .init are you referring to?
On Sunday, 14 July 2013 at 16:49:13 UTC, Artur Skawina wrote:
...
On 07/14/13 18:59, Dicebot wrote:
> Ugh, rly? As far as I understand spec it should work like this:
>
> T x; // sets x to T.init
> T x = void; // don't initialize x at all, leave garbage
"void-initialization of aggregate fields does *not* actually disable
initialization":
struct S {
T x
Still can't find this in the spec but I see what you are getting
at, makes sense. I think this actually is yet another case where
CTFE-able default constructor for structs would have been a major
win.
On Sunday, 14 July 2013 at 17:41:35 UTC, Artur Skawina wrote:
On 07/14/13 18:59, Dicebot wro
On 07/14/2013 07:51 PM, Dicebot wrote:
Still can't find this in the spec but I see what you are getting at,
makes sense. ...
(This is a QOI issue.)
On Sunday, 14 July 2013 at 18:12:07 UTC, Timon Gehr wrote:
On 07/14/2013 07:51 PM, Dicebot wrote:
Still can't find this in the spec but I see what you are
getting at,
makes sense. ...
(This is a QOI issue.)
Is it really? I see certain conflicting interests between
bit-wise T.init copy for
void initialization is for stack variables only. It doesn't make
sense for fields as they're initialized with init.
39 matches
Mail list logo
