On 8/26/15 10:50 AM, Iain Buclaw via Digitalmars-d wrote:
On 26 August 2015 at 15:14, Mike via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote:
A MUCH better solution:
On 26 August 2015 at 15:14, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote:
A MUCH better solution:
T[] _d_arrayliteral(T)(size_t length)
Also, isn't the typeinfo now stored by the GC so it can call the dtor?
On Saturday, 22 August 2015 at 10:11:24 UTC, Iain Buclaw wrote:
A MUCH better solution:
T[] _d_arrayliteral(T)(size_t length)
Also, isn't the typeinfo now stored by the GC so it can call
the dtor? Perhaps that is done in the filling of the array
literal, but I would be surprised as this is
On 2015-08-25 10:18, w0rp wrote:
I think this is another case where Walter has got it right, by and
large. I think we should try and use 'export' to cut down on binary
bloat, and it looks like an acceptable solution.
I have said many times, lock your versions down, and don't update your D
I think this is another case where Walter has got it right, by
and large. I think we should try and use 'export' to cut down on
binary bloat, and it looks like an acceptable solution.
I have said many times, lock your versions down, and don't update
your D compiler until you're ready to pay
V Tue, 25 Aug 2015 10:34:57 +0200
Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com napsáno:
On 2015-08-25 10:18, w0rp wrote:
I think this is another case where Walter has got it right, by and
large. I think we should try and use 'export' to cut down on binary
bloat, and it
On 2015-08-21 22:26, Walter Bright wrote:
The principle often used by languages (C, C++, Rust) is you only pay for
what you use. With Object.factory, every program pays for it with every
class, despite very few actual uses of it.
A always thought of D as a bit more convenient language.
On 2015-08-21 07:06, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it work, though, every class in the program has to have a TypeInfo
generated for it. This leads to bloat:
On 8/23/2015 6:17 AM, Benjamin Thaut wrote:
How do you implement weak linking? It would be really usefull for my DLL work as
well, but I couldn't find any way to make it work with the microsoft linker.
I've always had trouble with linker bugs when using weak linking, to the point
where I
On 8/24/2015 1:09 AM, Benjamin Thaut wrote:
The good news is, once I'm done with my windows DLL work the code can be
trivialy reused to make export control the visibility of symbols on
linux as well.
Kind Regards
Benjamin Thaut
Wait we are getting almost full blown DLL support on Windows?
On Saturday, 22 August 2015 at 20:22:58 UTC, David Nadlinger
wrote:
On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright
wrote:
I'm not sure how export would help on Linux.
One of the use cases for export on Linux would be to set the
ELF visibility based on it. Emitting all the symbols
On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright wrote:
Marking them all as export will be inconvenient but is
possible - but I'd like
to get something useful in return, like well-defined and
working export for
example.
I'm not sure how export would help on Linux.
I have always
On Friday, 21 August 2015 at 06:24:34 UTC, Rikki Cattermole wrote:
On 8/21/2015 5:06 PM, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To
make it work, though, every class in the
On Friday, 21 August 2015 at 21:50:21 UTC, Walter Bright wrote:
As with everything, it's cost/benefit. Changing isnan to isNaN
is an example of all cost and no benefit.
I've explained the benefits of changing factory() a couple
times in this thread. I believe the benefits are significant,
On 8/23/2015 2:27 AM, Dicebot wrote:
Changing isnan to isNaN is a small benefit (better internal structure and
consistency is important) but it also comes at tiny, almost insignificant costs.
It doesn't cause any immediate breakage and can be adjusted to at any moment
with 1 simple
On Saturday, 22 August 2015 at 09:44:48 UTC, Martin Nowak wrote:
The export seems to be an arbitrary rule (and export is really
broken currently).
Let's just use every class that is linked into the binary (e.g.
weakly referencing them), then it'll naturally work with all
linker
On Sunday, 23 August 2015 at 13:09:46 UTC, Benjamin Thaut wrote:
The good news is, once I'm done with my windows DLL work the
code can be trivialy reused to make export control the
visibility of symbols on linux as well.
Kind Regards
Benjamin Thaut
But then you have the same problem on
On Friday, 21 August 2015 at 21:37:34 UTC, Walter Bright wrote:
On 8/21/2015 4:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Just change Object.factory to require registration of the
class.
What mechanism do you propose for that?
E.g.:
template
On Saturday, 22 August 2015 at 08:16:06 UTC, Marc Schütz wrote:
Another possible mechanisms would be some UDA magic.
E.g.:
class MyClass {
@factorizable
this() { }
@factorizable
this(string) { }
this(int) { }
}
mixin
On Friday, 21 August 2015 at 20:28:47 UTC, Walter Bright wrote:
Btw we use it for high-level testing framework - will be
rather hard to move
that to compile-time approach
It's good to hear of use cases for Object.factory.
If you want details it is special library for black box testing
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
The solution seems straightforward - only have Object.factory
be able to instantiate classes marked as 'export'. This only
makes sense anyway.
The export seems to be an arbitrary rule (and export is really
broken currently).
On Friday, 21 August 2015 at 13:47:49 UTC, Andrei Alexandrescu
wrote:
I think these need to be fixed (by replacing
indirect-calls-based code with templates) regardless of where
we go with TypeInfo. There's a fair amount of druntime code
that suffers from being written before templates or in
On Friday, 21 August 2015 at 13:47:49 UTC, Andrei Alexandrescu
wrote:
Thanks for this list. I think these need to be fixed (by
replacing indirect-calls-based code with templates) regardless
of where we go with TypeInfo. There's a fair amount of druntime
code that suffers from being written
Am Fri, 21 Aug 2015 11:46:21 +
schrieb Kagamin s...@here.lot:
On Friday, 21 August 2015 at 11:03:09 UTC, Mike wrote:
* postblit -
https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918
* destructor -
Am Fri, 21 Aug 2015 15:16:01 +0200
schrieb Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com:
Other than that, the semantics of pragma(inline, true) should
guarantee that the function is never *written* to object file.
This really should be documented then. If we build a shared
On 21 August 2015 at 13:35, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/21/15 7:22 AM, Iain Buclaw via Digitalmars-d wrote:
Where removing RTTI disables D feature's in a compromising way, I'd
start by questioning the why.
Eg: Why does array literals need
On 22 August 2015 at 11:33, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Fri, 21 Aug 2015 15:16:01 +0200
schrieb Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com:
Other than that, the semantics of pragma(inline, true) should
guarantee that the function
Am Sat, 22 Aug 2015 14:47:34 +0200
schrieb Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com:
On 22 August 2015 at 11:33, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Fri, 21 Aug 2015 15:16:01 +0200
schrieb Iain Buclaw via Digitalmars-d
On 8/22/2015 2:42 AM, Dicebot wrote:
On Friday, 21 August 2015 at 20:28:47 UTC, Walter Bright wrote:
Btw we use it for high-level testing framework - will be rather hard to move
that to compile-time approach
It's good to hear of use cases for Object.factory.
If you want details it is
On Saturday, 22 August 2015 at 21:56:25 UTC, Walter Bright wrote:
On 8/22/2015 1:22 PM, David Nadlinger wrote:
One of the use cases for export on Linux would be to set the
ELF visibility
based on it. Emitting all the symbols with default visibility,
like we currently
do, leads to size and load
On Saturday, 22 August 2015 at 23:33:15 UTC, Manu wrote:
On 21 August 2015 at 15:06, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[...]
I don't follow the reasoning, but yes! Kill it with fire!
I'd rather see a compile option or something to disable it
completely,
like
On 8/22/2015 3:41 PM, Adam D. Ruppe wrote:
The common saying if it isn't in bugzilla it is forgotten seems quite silly
when so much that IS in bugzilla is forgotten all the same.
Lots of people, like Daniel and Kenji and Vladimir and Martin, etc., go through
Bugzilla looking for things to
On 8/22/2015 5:47 AM, Iain Buclaw via Digitalmars-d wrote:
But it should be put in COMDAT
And it is.
On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright wrote:
I'm not sure how export would help on Linux.
One of the use cases for export on Linux would be to set the ELF
visibility based on it. Emitting all the symbols with default
visibility, like we currently do, leads to size and
On 8/22/2015 1:22 PM, David Nadlinger wrote:
On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright wrote:
I'm not sure how export would help on Linux.
One of the use cases for export on Linux would be to set the ELF visibility
based on it. Emitting all the symbols with default
On Saturday, 22 August 2015 at 22:08:50 UTC, David Nadlinger
wrote:
A bugzilla enhancement request for this would be nice.
https://issues.dlang.org/show_bug.cgi?id=9893
The common saying if it isn't in bugzilla it is forgotten seems
quite silly when so much that IS in bugzilla is forgotten
On 21 August 2015 at 15:06, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To make
it work, though, every class in the program has to
Am Thu, 20 Aug 2015 22:21:30 -0700
schrieb H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com:
On Fri, Aug 21, 2015 at 05:15:00AM +, deadalnix via Digitalmars-d
wrote:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
Am Fri, 21 Aug 2015 07:24:58 +
schrieb Benjamin Thaut c...@benjamin-thaut.de:
I don't think this is a good idea. That's just abusing a already
existing keyword. Export basically means Make this function or
class visible across shared library boundaries.
+1. I think we should be very
On 8/21/2015 12:24 AM, Benjamin Thaut wrote:
Export basically means Make this function or class visible across
shared library boundaries. I don't see how this connects to the object factory.
Object.factory() only has a point when it is used to instantiate classes in a
DLL/so. It fits in
Am Thu, 20 Aug 2015 23:16:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/20/2015 11:00 PM, Mike wrote:
Ideally it would be nice to only pull in those ModuleInfo instances
that are actually needed in the program, and by association, only
pull in those TypeInfo instances
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing,
postblit
Why slicing and postblit would need typeinfo?
See below for the source code. Some obvious, some not.
* dynamic
On 21 August 2015 at 13:03, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit
On 8/21/15 7:03 AM, Mike wrote:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit would need typeinfo?
See below for the source code.
On 21-Aug-2015 13:44, Walter Bright wrote:
On 8/21/2015 12:24 AM, Benjamin Thaut wrote:
Export basically means Make this function or class visible across
shared library boundaries. I don't see how this connects to the
object factory.
Object.factory() only has a point when it is used to
On 8/21/15 7:22 AM, Iain Buclaw via Digitalmars-d wrote:
Where removing RTTI disables D feature's in a compromising way, I'd
start by questioning the why.
Eg: Why does array literals need RTTI? Looking at _d_arrayliteralTX
implementation, it only does the following with the given TypeInfo
On 8/21/15 6:59 AM, Johannes Pfau wrote:
Am Thu, 20 Aug 2015 23:16:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/20/2015 11:00 PM, Mike wrote:
Ideally it would be nice to only pull in those ModuleInfo instances
that are actually needed in the program, and by association,
Am Fri, 21 Aug 2015 11:03:00 +
schrieb Mike n...@none.com:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing,
postblit
Why slicing and postblit would need
On 8/21/15 7:03 AM, Mike wrote:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit would need typeinfo?
See below for the source code.
On Friday, 21 August 2015 at 12:41:17 UTC, Steven Schveighoffer
wrote:
I have no idea. It probably should be guaranteed, because what
is the point of having an always inlined function that
generates it's own code?
If it is guaranteed, almost makes me want to abuse it for this:
pragma(inline,
On 8/21/15 7:57 AM, Dicebot wrote:
On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
Sure:
pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
-Steve
Btw, are `pragma(inline, true)` function actually guaranteed to not have
own code gen? :)
I have no idea. It
On 21 August 2015 at 14:43, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 12:41:17 UTC, Steven Schveighoffer wrote:
I have no idea. It probably should be guaranteed, because what is the
point of having an always inlined function that generates it's
On 2015-08-21 12:44, Walter Bright wrote:
Object.factory() only has a point when it is used to instantiate classes
in a DLL/so. It fits in nicely with export.
It's useful for deserialization as well.
--
/Jacob Carlborg
On 2015-08-21 10:52, Benjamin Thaut wrote:
Yes, the usual problem was that it only works with default constructors.
Also it doesn't work with nested classes e.g.
class Outer
{
class Inner
{
}
}
I don't know if that is fixed now.
It sounds like both of these could be fixed. BTW, in
How expensive putting a flag for the compiler?
--exportall, -ea
to export all, otherwise, only the classes with export keyword
are to be exported.
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On 21 August 2015 at 13:57, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
Sure:
pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
-Steve
Btw, are `pragma(inline, true)` function actually
On Friday, 21 August 2015 at 13:11:14 UTC, Iain Buclaw wrote:
If it is guaranteed, almost makes me want to abuse it for this:
pragma(inline, true)
string foo()
{
if (!__ctfe)
assert(false);
// ...
}
(for compilers other than LDC)
That enforces that foo() is always folded at
On Friday, 21 August 2015 at 13:18:17 UTC, Jacob Carlborg wrote:
On 2015-08-21 12:44, Walter Bright wrote:
Object.factory() only has a point when it is used to
instantiate classes
in a DLL/so. It fits in nicely with export.
It's useful for deserialization as well.
Btw we use it for
On 8/21/15 1:06 AM, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it work, though, every class in the program has to have a TypeInfo
generated for it. This leads to bloat:
On 8/21/2015 6:29 AM, Dicebot wrote:
On Friday, 21 August 2015 at 13:18:17 UTC, Jacob Carlborg wrote:
On 2015-08-21 12:44, Walter Bright wrote:
Object.factory() only has a point when it is used to instantiate classes
in a DLL/so. It fits in nicely with export.
It's useful for
On 8/21/2015 6:29 AM, Andrei Alexandrescu wrote:
Knee-jerk reaction: sensible and meaningful, but we need to make a good case for
breaking code. -- Andrei
The case is:
https://issues.dlang.org/show_bug.cgi?id=14758
i.e. D being unusable for embedded systems because of bloat.
And it always
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing,
postblit
Why slicing and postblit would need typeinfo?
Because the runtime implementation is broken and rely on it
On Friday, 21 August 2015 at 21:37:34 UTC, Walter Bright wrote:
On 8/21/2015 4:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Just change Object.factory to require registration of the
class.
What mechanism do you propose for that?
On 8/21/2015 6:27 AM, Dicebot wrote:
And when you combine both you gets function that is always folded at compile
time and does not bloat the generated object file (like it happens right now
with CTFE-only functions - they are still emitted to the binary). Win.
They are emitted as COMDATs, and
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
What do you think?
Do function pointer types also have TypeInfo? Derelict libraries
has hundreds of them and my belief is that they are related.
There were complaints about bloat at times. Those function
pointer types
On 8/21/2015 2:59 PM, deadalnix wrote:
[...]
It's a good idea, but is still equivalent to manually annotating the classes one
wishes to register, and still requires a new language feature.
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On Friday, 21 August 2015 at 22:21:43 UTC, Walter Bright wrote:
On 8/21/2015 2:59 PM, deadalnix wrote:
[...]
It's a good idea, but is still equivalent to manually
annotating the classes one wishes to register, and still
requires a new language feature.
Breaking the code must be worth it.
On 8/20/2015 11:40 PM, Jacob Carlborg wrote:
I think, or rather know, that this will break serialization, i.e. my library
Orange [1]. I really like that one doesn't need to register a class to be able
to (de)serialize it.
I can't believe this change is purposed that will clearly break valid
On Friday, 21 August 2015 at 20:26:29 UTC, Walter Bright wrote:
On 8/21/2015 6:29 AM, Andrei Alexandrescu wrote:
Knee-jerk reaction: sensible and meaningful, but we need to
make a good case for
breaking code. -- Andrei
The case is:
https://issues.dlang.org/show_bug.cgi?id=14758
i.e. D
On 8/21/2015 2:53 PM, ponce wrote:
Do function pointer types also have TypeInfo? Derelict libraries has hundreds of
them and my belief is that they are related.
Compile with -map and check to see what winds up in the binary.
On 8/21/2015 4:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
Just change Object.factory to require registration of the class.
What mechanism do you propose for that?
On Friday, 21 August 2015 at 11:34:58 UTC, Steven Schveighoffer
wrote:
A MUCH better solution:
T[] _d_arrayliteral(T)(size_t length)
It needs to be trivial wrapper which forwards to proposed
void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint
flags, bool
isshared);
Otherwise you
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On 8/21/15 7:39 AM, Dicebot wrote:
On Friday, 21 August 2015 at 11:34:58 UTC, Steven Schveighoffer wrote:
A MUCH better solution:
T[] _d_arrayliteral(T)(size_t length)
It needs to be trivial wrapper which forwards to proposed
void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint
On Friday, 21 August 2015 at 11:03:09 UTC, Mike wrote:
* postblit -
https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918
* destructor -
On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer
wrote:
Sure:
pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
-Steve
Btw, are `pragma(inline, true)` function actually guaranteed to
not have own code gen? :)
On Friday, 21 August 2015 at 21:59:30 UTC, deadalnix wrote:
Such a feature can be used to make sure that all child have a
mechanism to register themselves int he factory. Something à la
class Base {
super mixin {
shared this() {
library.register(typeid(typeof(this)));
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
What do you think?
Well, one suggestion would be to simply version Object.factory so
that programs that don't need it and don't want the bloat can
define a version which versions it out. The it won't pull in all
of the
On Friday, 21 August 2015 at 05:35:21 UTC, Walter Bright wrote:
On 8/20/2015 10:24 PM, BBasile wrote:
Other alternatives would be a pragma or an attribute to
disable TypeInfo
generation.
Interestingly, my idea would not disable TypeInfo generation.
Instead, the TypeInfo would be generated
On 8/20/2015 11:00 PM, Mike wrote:
Ideally it would be nice to only pull in those ModuleInfo instances that are
actually needed in the program, and by association, only pull in those TypeInfo
instances needed by the ModuleInfo. If no ModuleInfo is used, and the
associated TypeInfo is also not
On 2015-08-21 07:06, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it work, though, every class in the program has to have a TypeInfo
generated for it. This leads to bloat:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On 8/21/2015 5:06 PM, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it work, though, every class in the program has to have a TypeInfo
generated for it. This leads to bloat:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On 2015-08-21 09:24, Benjamin Thaut wrote:
Given how limited object.factory is I would just vote that we kill it
completely. Every time I wanted to use it, it was to limited and I ended
up building my own reflection / factory mechanism.
How is it limiting? That it only works with default
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
What do you think?
Isn't typeinfo referenced from vtbl? So as long as the class is
used, its typeinfo stays.
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit would need typeinfo?
On Friday, 21 August 2015 at 08:49:37 UTC, Jacob Carlborg wrote:
How is it limiting? That it only works with default
constructors? I don't think that underlying ClassInfo.find is
limiting, which is where the interesting part happens. I'm
pretty sure that Object.factory could be extended to
On Friday, 21 August 2015 at 05:24:52 UTC, BBasile wrote:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every
On Fri, Aug 21, 2015 at 05:15:00AM +, deadalnix via Digitalmars-d wrote:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To make it
work, though, every class in the program has to have a TypeInfo generated for
it. This leads to bloat:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On 8/20/2015 10:24 PM, BBasile wrote:
Other alternatives would be a pragma or an attribute to disable TypeInfo
generation.
Interestingly, my idea would not disable TypeInfo generation. Instead, the
TypeInfo would be generated into a COMDAT section. Then, only if it is
referenced is it linked
On 21-Aug-2015 08:06, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it work, though, every class in the program has to have a TypeInfo
generated for it. This leads to bloat:
98 matches
Mail list logo
