On Wednesday, 8 June 2022 at 01:32:42 UTC, Steven Schveighoffer
wrote:
I like `$`. It's got a well-defined meaning, and already is
somewhat magic.
-Steve
I agree it's magic.
warray[5..$] - this is one of the best uses of syntax magic in D!
I think it's what first attracted me to the
On 6/7/22 9:17 PM, forkit wrote:
On Wednesday, 8 June 2022 at 01:11:45 UTC, Mike Parker wrote:
...The author withdrew the DIP
..
That's a shame.
Seems like a useful language feature. I'd be using it already if it
existed.
I agree, it's a pain to dig out an import and the verbose
On Wednesday, 8 June 2022 at 01:11:45 UTC, Mike Parker wrote:
...The author withdrew the DIP
..
That's a shame.
Seems like a useful language feature. I'd be using it already if
it existed.
I'd have gone for:
int[..] arr = [1,2,3];
On Wednesday, 8 June 2022 at 00:43:24 UTC, Ali Çehreli wrote:
Do I remember correctly that there were syntax proposals that
used $ or _?
int[$] arr = [ 1, 2 ];
int[_] arr = [ 1, 2 ];
But I can't find past discussions about that.
On 6/7/22 16:38, arandomonlooker wrote:
There is any chance size inference is going to be implemented into D as
a feature?
Do I remember correctly that there were syntax proposals that used $ or _?
int[$] arr = [ 1, 2 ];
int[_] arr = [ 1, 2 ];
But I can't find past discussions about
On Tuesday, 7 June 2022 at 00:20:31 UTC, Ali Çehreli wrote:
On 6/6/22 17:04, arandomonlooker wrote:
> [...]
syntax causes
> [...]
As you already know, the correct syntax is 'int[]' :) but it
won't work because -betterC cannot support dynamic array.
[...]
There is any chance size inference
On Tuesday, 7 June 2022 at 00:20:31 UTC, Ali Çehreli wrote:
> it's complaining about TypeInfo being absent.
What an unfortunate error message! Trying writeln() causes
equally weird error messages.
Walter just improved it! https://github.com/dlang/dmd/pull/14181
Perhaps try a [nightly
On Tuesday, 7 June 2022 at 00:20:31 UTC, Ali Çehreli wrote:
On 6/6/22 17:04, arandomonlooker wrote:
> [...]
syntax causes
> [...]
As you already know, the correct syntax is 'int[]' :) but it
won't work because -betterC cannot support dynamic array.
[...]
Thank you. I was kind of
On 6/6/22 17:04, arandomonlooker wrote:
> I usually transcribe them as follows, because the previous syntax causes
> a compiler error:
>
> ```d
> int numbersINeed[] = [1, 2, 3, 4, 5];
> ```
As you already know, the correct syntax is 'int[]' :) but it won't work
because -betterC cannot support
Hello.
I am working on a project related to low-level development as a
beginner, and i decided to pick D as the most optimal programming
language for that, in large part because of it's strong
integration with C and C++.
I happen to have a lot of arrays that i want to translate to D,
On Thursday, 9 February 2017 at 11:22:28 UTC, Suliman wrote:
Docs says that:
"The total size of a static array cannot exceed 16Mb."
But when I am creation array of:
int [1000_000] x; // 1000_000 is equal ~ 0,95MB
app crush on start.
Should it's reserve this memory with guaranty? I mean that
On Thursday, 9 February 2017 at 12:13:36 UTC, Daniel Kozák wrote:
V Thu, 09 Feb 2017 11:22:28 +
Suliman via Digitalmars-d-learn
napsáno:
Docs says that:
"The total size of a static array cannot exceed 16Mb."
But when I am creation array of:
int
On Thursday, 9 February 2017 at 12:16:26 UTC, jkpl wrote:
On Thursday, 9 February 2017 at 11:22:28 UTC, Suliman wrote:
Docs says that:
"The total size of a static array cannot exceed 16Mb."
But when I am creation array of:
int [1000_000] x; // 1000_000 is equal ~ 0,95MB
app crush on start.
On Thursday, 9 February 2017 at 11:22:28 UTC, Suliman wrote:
Docs says that:
"The total size of a static array cannot exceed 16Mb."
But when I am creation array of:
int [1000_000] x; // 1000_000 is equal ~ 0,95MB
app crush on start.
Should it's reserve this memory with guaranty? I mean that
V Thu, 09 Feb 2017 11:22:28 +
Suliman via Digitalmars-d-learn
napsáno:
> Docs says that:
> "The total size of a static array cannot exceed 16Mb."
> But when I am creation array of:
> int [1000_000] x; // 1000_000 is equal ~ 0,95MB
> app crush on start.
>
>
Docs says that:
"The total size of a static array cannot exceed 16Mb."
But when I am creation array of:
int [1000_000] x; // 1000_000 is equal ~ 0,95MB
app crush on start.
Should it's reserve this memory with guaranty? I mean that after
app start it should take +0.95MB of RAM in task manager.
On 13.04.2011 22:56, Andrej Mitrovic wrote:
Code:
void main()
{
static string[2] szFormat = [%s, %s];
}
This compiles, but this is buggy code. The first declaration should have been:
static string[2] szFormat = [%s, %s];
I can't tell whether the first case is legit code. You might *want*
simendsjo:
Why is this a bug?
Currently it isn't. But I (and few other people) have asked for it to be a bug,
because it sometimes leads to not catching a programmer mistake.
Static means it's only one instance (per thread),
right? The compiler cannot know if you meant to fill the entire
Code:
void main()
{
static string[2] szFormat = [%s, %s];
}
This compiles, but this is buggy code. The first declaration should have been:
static string[2] szFormat = [%s, %s];
I can't tell whether the first case is legit code. You might *want* to
initialize all the elements with the same
Andrej Mitrovic:
void main()
{
static string[2] szFormat = [%s, %s];
}
This compiles, but this is buggy code.
Please vote this old bug report of mine, about this problem:
http://d.puremagic.com/issues/show_bug.cgi?id=3849
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=481
Yeah, I don't have a lot of votes left, in fact I only have one left. :s
I think we're basically on our own when it comes to these kinds of
issues. We'll either get a compiler with a better warning system
(maybe GDC.. DDMD in the future), or we'll make some kind of Lint tool
for D. The latter
Andrej Mitrovic:
We'll either get a compiler with a better warning system
In that bug report I ask for an error, not a warning.
or we'll make some kind of Lint tool for D.
Eventually some lint tools will surely be written for D, but lot of people
don't use lints. What I am looking here is
On Sat, 02 Apr 2011 10:45:51 -0400, bearophile bearophileh...@lycos.com
wrote:
simendsjo:
http://digitalmars.com/d/2.0/arrays.html says static arrays are
limited to 16mb, but I can only allocate 1mb.
My fault, or bug?
It accepts 4_000_000 ints, but not (16 * 1024 * 1024) / int.sizeof =
Steven Schveighoffer:
That would be 16 MiB.
http://en.wikipedia.org/wiki/Mebibyte
Then I think 16 MiB are more useful than 16_000_000 bytes.
Bye,
bearophile
On Mon, 04 Apr 2011 12:43:03 -0400, bearophile bearophileh...@lycos.com
wrote:
Steven Schveighoffer:
That would be 16 MiB.
http://en.wikipedia.org/wiki/Mebibyte
Then I think 16 MiB are more useful than 16_000_000 bytes.
Seems arbitrary to me. I'm sure some people feel 32MB would be
http://digitalmars.com/d/2.0/arrays.html says static arrays are
limited to 16mb, but I can only allocate 1mb.
My fault, or bug?
enum size = (16 * 1024 * 1024) / int.sizeof;
//int[size] a; // Error: index 4194304 overflow for static
array
enum size2 = (16 * 1000 * 1000) /
This is using dmd 2.052 on windows by the way.
On 2011-04-02 06:21, simendsjo wrote:
http://digitalmars.com/d/2.0/arrays.html says static arrays are
limited to 16mb, but I can only allocate 1mb.
My fault, or bug?
enum size = (16 * 1024 * 1024) / int.sizeof;
//int[size] a; // Error: index 4194304 overflow for static
array
I think you missed my /int.sizeof at the end.
enum size = (16*1024*1024)/int.sizeof;
int[size] a; // Error index overflow for static as expected
int[size-1] b; // stack overflow
int[250_001] c; // stack overflow
int[250_000] d; // ok
simendsjo:
The main problem is that it gives a Stack Overflow already at 250_001
I meant with the array as a global variable.
The stack on Windows can be set very large too, with -L/STACK:1000
Bye,
bearophile
30 matches
Mail list logo