Re: App release build crashes
On Friday, 7 February 2014 at 07:43:05 UTC, Steve Teale wrote: I was attempting to to build my app COMPO using a Makefile this morning, and at first this worked to some extent, but after some fiddling with compiler flags to make a release version that then had problems, I reverted to my original makefile as of yesterday. That builds and links the app, but when I run it I get Fatal Error while loading '/usr/lib/i386-linux-gnu/libphobos2.so.0.64': The module 'std.regex' is already defined in './compo'. My Makefile has: LFLAGS = -L-L/usr/lib/i386-linux-gnu -L-L/usr/local/lib -L-L/home/steve/COMPO -L-lusps4cb -L-lgtkd-2 -L-lrsvg -L-lphobos2 -L-ldl -L-lpthread -L-lm -L-lrt compo: $(OBJFILES) gcc -o compo $(OBJFILES) $(LFLAGS) If I use static phobos2 -L-l:libphobos2.a, it runs OK. Building via CodeBlocks using phobos2 shared library works OK judging by the smaller executable size. What is wrong with my linker flags? Possibly nothing - I was using binutils-gold, and reverting to the Gnu linker fixed that. However the version built with phobos shared crashes in use, and I have to delve into that before I can say where.
Re: scope attribute vs scope keyword vs scope storage class
On Thursday, 6 February 2014 at 22:16:30 UTC, Dicebot wrote: On Thursday, 6 February 2014 at 19:01:52 UTC, Brad Anderson wrote: Couldn't scope allocating a class on the stack just be considered an optimization that can be applied if the scope storage class become fully implemented? I think so. Scope classes were unsafe because of leaking references but if `scope` is actually implemented to assure safety it becomes perfectly valid thing to do. If you declare something as scope, it is expected to have its destructor called at the end of the scope. Therefore, this behavior needs to be guaranteed. Theoretically of course, the memory could still be allocated on the heap and freed after destruction (or even just marked as destroyed and letting the GC clean it up), but this will probably not have advantages over stack allocation, except maybe for large objects.
Re: 3d vector struct
On Friday, 7 February 2014 at 04:03:58 UTC, Marco Leise wrote: Am Mon, 03 Feb 2014 22:01:14 + schrieb Stanislav Blinov stanislav.bli...@gmail.com: Return-by-value being optimized as a move might be one more reason why you would like to use slices... 3 doubles is only one machine word more than an array slice and there are no indirections, allocations and length attribute to deal with (which is always 3 here). I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices...
Usage of Shared
Hi all, I've been trying to learn more about how the shared qualifier works, and so far I haven't been able to find much. I've read the Migrating to Shared article, as well as the shared section in Attributes, but neither really give a good explanation on the details of what should be shared and what shouldn't. If anyone has any resources that they can share to help me (and others in the future) understand how and when to use shared it would be greatly appreciated. Thanks for the help!
Re: 3d vector struct
On Friday, 7 February 2014 at 10:50:49 UTC, Stanislav Blinov wrote: I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices... Wouldn't it make more sense to aim for a float SIMD implementation instead then? :P
Re: 3d vector struct
On Friday, 7 February 2014 at 21:37:26 UTC, Casper Færgemand wrote: On Friday, 7 February 2014 at 10:50:49 UTC, Stanislav Blinov wrote: I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices... Wouldn't it make more sense to aim for a float SIMD implementation instead then? :P It may well be :D
Avoiding allocation in broadcast server
Suppose I have a multi client broadcast server. One client sends a string, every client receives it. The client read thread reads the input from the client into a static byte array, makes a copy and casts it to a string, and passes it to the host thread, which relays it to all client write threads. This is done with message passing. Is there a way it can be done without allocation? That is, currently I use .idup on the static array.
Re: Avoiding allocation in broadcast server
To me it seems that you have to have at least one allocation per string received. To submit your string to another thread verbatim, you have to be able to guarantee that the buffer is immutable, which you cannot do because you can receive a new string at any given time (which would overwrite the existing buffer). So allocating on receive seems like the most logical option.
