07-Jan-2013 00:02, Dmitry Olshansky пишет:
06-Jan-2013 23:55, Philippe Sigaud пишет:
On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote:
Regarding toString there is a better signature that avoids useless
allocations:
void toString(scope void deleg
Am 06.01.2013 20:55, schrieb Philippe Sigaud:
On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote:
Regarding toString there is a better signature that avoids useless
allocations:
void toString(scope void delegate(const (char)[]) sink);
It takes
06-Jan-2013 23:55, Philippe Sigaud пишет:
On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote:
Regarding toString there is a better signature that avoids useless
allocations:
void toString(scope void delegate(const (char)[]) sink);
It takes a d
On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky wrote:
> Regarding toString there is a better signature that avoids useless
> allocations:
>
> void toString(scope void delegate(const (char)[]) sink);
>
> It takes a delegate to output string representation directly to the
> destination via 'sink'
06-Jan-2013 14:37, Benjamin Thaut пишет:
Am 05.01.2013 05:24, schrieb ixid:
On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote:
Am 31.12.2012 15:02, schrieb DypthroposTheImposter:
Do you find that D without GC is more effective than C++? Seems like
you would be stuck using str
Am Sun, 06 Jan 2013 13:14:39 +0100
schrieb David :
> > I guess when we have custom allocators we can also provide toString
> > methods templated on allocators.
> >
>
> Custom allocators released together with HL3?
A lot of things are blocked by custom allocators and this is indeed an
issue. It
Am 06.01.2013 13:23, schrieb Jacob Carlborg:
On 2013-01-06 13:19, Benjamin Thaut wrote:
Here is the full implementation if you are interested:
https://github.com/Ingrater/druntime/blob/master/src/rtti.d
Thanks. Is that possible to do without having to modify the runtime?
No. The template h
On 2013-01-06 13:19, Benjamin Thaut wrote:
Here is the full implementation if you are interested:
https://github.com/Ingrater/druntime/blob/master/src/rtti.d
Thanks. Is that possible to do without having to modify the runtime?
--
/Jacob Carlborg
Am 06.01.2013 12:50, schrieb Jacob Carlborg:
On 2013-01-06 12:28, Benjamin Thaut wrote:
It does not exist. The current RTInfo template just outputs a null
pointer for every type.
Yes, but it still exists.
It is planned that the RTInfo template will be
used for a percise GC in the future. (D
> I guess when we have custom allocators we can also provide toString
> methods templated on allocators.
>
Custom allocators released together with HL3?
Am Sun, 06 Jan 2013 12:10:38 +0100
schrieb Jacob Carlborg :
> On 2013-01-06 11:37, Benjamin Thaut wrote:
>
> > I wouldn't say its moving away from it. Some recent changes to
> > druntime have made it significantly less leaking. But on the other
> > hand a API design like toString() which pretty m
On 2013-01-06 12:28, Benjamin Thaut wrote:
It does not exist. The current RTInfo template just outputs a null
pointer for every type.
Yes, but it still exists.
It is planned that the RTInfo template will be
used for a percise GC in the future. (Did you read the article? ^^)
Yes, I've read
Am 06.01.2013 12:17, schrieb Jacob Carlborg:
On 2013-01-06 11:30, Benjamin Thaut wrote:
Yes I know flectioned. But I did not require that much RTTI information.
No I'M not manually triggering the code for generating the RTTI. As
mentioned in the article it is done via the RTInfo template inside
On 2013-01-06 11:30, Benjamin Thaut wrote:
Yes I know flectioned. But I did not require that much RTTI information.
No I'M not manually triggering the code for generating the RTTI. As
mentioned in the article it is done via the RTInfo template inside
object_.d / object.di which is automatically
On 2013-01-06 11:37, Benjamin Thaut wrote:
I wouldn't say its moving away from it. Some recent changes to druntime
have made it significantly less leaking. But on the other hand a API
design like toString() which pretty much does leak in almost all cases
don't exactly help a GC free D. In Summar
Benjamin Thaut:
In Summary it feels to me that GC free D is not important
to the community or the active contributors.
I think it will become more important for them, in future. At the
moment the work is mostly on finishing immutability, purity,
shared, and other parts of the core language,
Am 05.01.2013 05:24, schrieb ixid:
On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote:
Am 31.12.2012 15:02, schrieb DypthroposTheImposter:
Do you find that D without GC is more effective than C++? Seems like
you would be stuck using structs which seems somewhat limiting, even
c
Am 05.01.2013 12:15, schrieb Jacob Carlborg:
On 2012-12-30 13:32, Benjamin Thaut wrote:
An article about runtime code reloading in the context of game
developement. A topic I'm currently working on in my spare time. I hope
it holds some valuable information for everyone working with D.
http://3
On 2012-12-30 13:32, Benjamin Thaut wrote:
An article about runtime code reloading in the context of game
developement. A topic I'm currently working on in my spare time. I hope
it holds some valuable information for everyone working with D.
http://3d.benjamin-thaut.de/?p=25
This looks very co
On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote:
Am 31.12.2012 15:02, schrieb DypthroposTheImposter:
Do you find that D without GC is more effective than C++?
Seems like
you would be stuck using structs which seems somewhat
limiting, even
compared to C++...
UE4 has simila
Am 31.12.2012 15:02, schrieb DypthroposTheImposter:
Do you find that D without GC is more effective than C++? Seems like
you would be stuck using structs which seems somewhat limiting, even
compared to C++...
UE4 has similar reloading capabilities(using DLLs), though they use
C++ and rely m
Do you find that D without GC is more effective than C++? Seems
like you would be stuck using structs which seems somewhat
limiting, even compared to C++...
UE4 has similar reloading capabilities(using DLLs), though they
use C++ and rely more on the ability to serialize everything
On 12/30/2012 06:02 PM, Benjamin Thaut wrote:
An article about runtime code reloading in the context of game
developement. A topic I'm currently working on in my spare time. I hope
it holds some valuable information for everyone working with D.
Thanks for the article. It was very informative. W
On Sunday, 30 December 2012 at 12:32:00 UTC, Benjamin Thaut wrote:
An article about runtime code reloading in the context of game
developement. A topic I'm currently working on in my spare
time. I hope it holds some valuable information for everyone
working with D.
http://3d.benjamin-thaut.de
Am 30.12.2012 14:27, schrieb bearophile:
This seems one of the situations where knowing "why" is almost more
important than "doing": understanding the cause, and maybe even fixing
it, will help future D programmers.
Bye,
bearophile
The problem only happens if you have a POD struct in a librar
Benjamin Thaut:
http://3d.benjamin-thaut.de/?p=25
The pointer to the RTTI information for each member is a
workaround for a strange bug I encountered. For POD structs the
rtInfo template will be instancated, but for some reason you can
not query the results at runtime. It is possible that t
An article about runtime code reloading in the context of game
developement. A topic I'm currently working on in my spare time. I hope
it holds some valuable information for everyone working with D.
http://3d.benjamin-thaut.de/?p=25
Kind Regards
Benjamin Thaut
27 matches
Mail list logo
