I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
My project has just stopped for this reason, I was
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
large static array could allow indexing it through a null pointer
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow
for static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow
for static array
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
Typo:
*scenario
On Saturday, 1 August 2015 at 18:07:51 UTC, NX wrote:
Sorry, I can't see _the_ point in that.
Yeah, especially since you can jsut break up the array and get
the same effect anyway...
so like if you don't want to dynamically allocate the memory, you
could also try:
byte[1024*1024*8] arr1;
V Sat, 01 Aug 2015 18:07:50 +
NX via Digitalmars-d-learn napsáno:
> On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
> > On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
> >> I wonder if the followings are compiler bugs:
> >
> > No, it is by design, the idea is to keep st
On Saturday, 1 August 2015 at 18:07:51 UTC, NX wrote:
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
Sorry, I can't see _the_ point in that. I understand that could
be a problem if it was a "global" array but this scenery is
completely wrong in my view. I'm already going to d
On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote:
Still same problem, You can`t allocate more then 16M on stack.
Use dynamic allocation
I don't think "new MyStruct" allocates on stack, actually
allocating ~16MB on stack will immediatelly crash the program
which is not the case w
On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote:
No you don't. You still use static allocation for array
Can clarify why does that happen and I still suspect it's a
static allocation it would increase output exe if it was really
that static..?
V Sat, 01 Aug 2015 19:16:16 +
NX via Digitalmars-d-learn napsáno:
> On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote:
> > Still same problem, You can`t allocate more then 16M on stack.
> > Use dynamic allocation
>
> I don't think "new MyStruct" allocates on stack, actually
>
V Sat, 01 Aug 2015 19:21:36 +
NX via Digitalmars-d-learn napsáno:
> On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote:
> > No you don't. You still use static allocation for array
>
> Can clarify why does that happen and I still suspect it's a
> static allocation it would increa
On Saturday, 1 August 2015 at 19:33:26 UTC, Daniel Kozak wrote:
My fault It is not on stack, but still it is a static allocation
I think you're misusing "static allocation" and "static
declaration" for each other.
V Sat, 01 Aug 2015 20:20:14 +
NX via Digitalmars-d-learn napsáno:
> On Saturday, 1 August 2015 at 19:33:26 UTC, Daniel Kozak wrote:
> > My fault It is not on stack, but still it is a static allocation
>
> I think you're misusing "static allocation" and "static
> declaration" for each other.
14 matches
Mail list logo
