On Sat, Sep 1, 2012 at 1:38 AM, Ellery Newcomer
ellery-newco...@utulsa.edu wrote:
On 08/31/2012 03:18 PM, Andrej Mitrovic wrote:
On 8/31/12, Ellery Newcomer ellery-newco...@utulsa.edu wrote:
hey, is anyone else getting a segfault from dmd on this code?
Yep on win32.
thanks
Same here on
On Sat, Sep 1, 2012 at 12:21 AM, Jonathan M Davis jmdavisp...@gmx.com wrote:
Using an enum is particularly bad for an AA, since it's not exactly a simple
data type, and there's definitely some cost to constructing them.
Yeah, my (nasty) bad. I'm too used to put 'enum' everywhere.
Gosh, I
On Saturday, September 01, 2012 09:39:04 Philippe Sigaud wrote:
On Sat, Sep 1, 2012 at 12:21 AM, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Using an enum is particularly bad for an AA, since it's not exactly a
simple data type, and there's definitely some cost to constructing them.
Yeah,
Using enum can be very useful, but I wouldn't use it for AAs at all, and I'd
be leery of using it for much in the way of arrays other than string literals
(since the string literals should avoid the memory allocations that other
array literals get). It's fine most other stuff, but for those
On Saturday, September 01, 2012 11:07:34 Philippe Sigaud wrote:
Using enum can be very useful, but I wouldn't use it for AAs at all, and
I'd be leery of using it for much in the way of arrays other than string
literals (since the string literals should avoid the memory allocations
that
Those still have different addresses when made immutable too, is
this something that could be optimized for all immutable enums to
behave like strings or are there reasons to keep them unique at
each instance?
Because the built-in arithmetic vector operators are supported
by hardware.
Should that matter from a user's point of view? It's a clean
syntax that should be made more univeral. It'd be nice to be able
to do things like:
return a[] + b[];
and using that in lambdas as well without needing
Hello, I've got a little problem with DerelictSFML2. Despite the
fact that I downloaded from the official website binaries CSFML2,
this little application closes with the message: Failed to load
symbol sfWindow_setSize from shared library csfml-window-2.dll
module main;
import std.stdio;
On Saturday, September 01, 2012 16:14:29 ixid wrote:
Those still have different addresses when made immutable too, is
this something that could be optimized for all immutable enums to
behave like strings or are there reasons to keep them unique at
each instance?
The compiler has to got to
On Saturday, September 01, 2012 11:10:17 Jonathan M Davis wrote:
On Saturday, September 01, 2012 16:14:29 ixid wrote:
Those still have different addresses when made immutable too, is
this something that could be optimized for all immutable enums to
behave like strings or are there reasons
On Saturday, 1 September 2012 at 15:53:20 UTC, Zhenya wrote:
Hello, I've got a little problem with DerelictSFML2. Despite
the fact that I downloaded from the official website binaries
CSFML2, this little application closes with the message:
Failed to load symbol sfWindow_setSize from shared
On Saturday, 1 September 2012 at 19:59:33 UTC, cal wrote:
On Saturday, 1 September 2012 at 15:53:20 UTC, Zhenya wrote:
Hello, I've got a little problem with DerelictSFML2. Despite
the fact that I downloaded from the official website binaries
CSFML2, this little application closes with the
There are 3 separated versions of opOpAssign
first version must be the same as the second for Vec!(sometype, 4)
why it doesn't work?
Simplified code:
struct Vec(T, uint size)
{
this(T rhs) { array[] = rhs; }
// It doesn't work but compiles
ref Vec!(T, size)
Hmm, strange...
z.opOpAssign!+(z); works with both first and second versions
On Sunday, 2 September 2012 at 04:10:39 UTC, Ivan Agafonov wrote:
There are 3 separated versions of opOpAssign
first version must be the same as the second for Vec!(sometype,
4)
why it doesn't work?
Simplified code:
struct Vec(T, uint size)
{
this(T rhs) { array[] = rhs; }
15 matches
Mail list logo
