Big thank.
Switch to /bin64 and now works until full memory using.
My guess is you are compiling to 32bit and the GC tries to
reserve >4gb wich it can't, therefore out of memory
Compiling to 64bit with: `dmd -m64 -run test.d` works no problem
uot;%,3d", i),
format("%,3d", dic.length));
}
}
```
got an error:
"processed line 32,000,000: 32,000,001
core.exception.OutOfMemoryError@src\core\lifetime.d(126): Memory
allocation failed"
app used is about 1.6 Gb, more than 4 stays free.
1. What is happened, w
On Friday, 25 February 2022 at 06:13:35 UTC, 9il wrote:
On Friday, 25 February 2022 at 06:03:34 UTC, Nonobvious wrote:
From [Go Your Own Way (Part Two: The
Heap)](https://dlang.org/blog/2017/09/25/go-your-own-way-part-two-the-heap/):
[...]
http://mir-algorithm.libmir.org/mir_ndslice_allocati
On Friday, 25 February 2022 at 06:03:34 UTC, Nonobvious wrote:
From [Go Your Own Way (Part Two: The
Heap)](https://dlang.org/blog/2017/09/25/go-your-own-way-part-two-the-heap/):
[...]
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#.stdcUninitSlice
From [Go Your Own Way (Part Two: The
Heap)](https://dlang.org/blog/2017/09/25/go-your-own-way-part-two-the-heap/):
`import core.stdc.stdlib;`
`// Allocate a block of untyped bytes that can be managed`
`// as a slice.`
`void[] allocate(size_t size)`
`{`
`// malloc(0) is i
On Tuesday, 26 October 2021 at 13:43:36 UTC, Steven Schveighoffer
wrote:
On 10/26/21 2:32 AM, bauss wrote:
On Monday, 25 October 2021 at 22:38:38 UTC, Imperatorn wrote:
On Monday, 25 October 2021 at 20:50:40 UTC, Steven
Schveighoffer wrote:
On 10/24/21 8:00 AM, Selim Ozel wrote:
It turns out
On Tuesday, 26 October 2021 at 20:33:17 UTC, Steven Schveighoffer
wrote:
On 10/26/21 1:38 PM, Imperatorn wrote:
That's the current implementation.
No, that's the API. You cannot fix the implementation with that
API and not end up allocating an array to hold the entire
unzipped contents. Yo
On 10/26/21 1:38 PM, Imperatorn wrote:
That's the current implementation.
No, that's the API. You cannot fix the implementation with that API and
not end up allocating an array to hold the entire unzipped contents. You
can't even decompress to a file, and then mmap those contents -- the
ad
On Tuesday, 26 October 2021 at 17:38:22 UTC, Imperatorn wrote:
On Tuesday, 26 October 2021 at 13:43:36 UTC, Steven
Schveighoffer wrote:
On 10/26/21 2:32 AM, bauss wrote:
On Monday, 25 October 2021 at 22:38:38 UTC, Imperatorn wrote:
[...]
Definitely not. It shouldn't use a lot of memory when
On Tuesday, 26 October 2021 at 13:43:36 UTC, Steven Schveighoffer
wrote:
On 10/26/21 2:32 AM, bauss wrote:
On Monday, 25 October 2021 at 22:38:38 UTC, Imperatorn wrote:
On Monday, 25 October 2021 at 20:50:40 UTC, Steven
Schveighoffer wrote:
On 10/24/21 8:00 AM, Selim Ozel wrote:
[...]
Wait
On 10/26/21 2:32 AM, bauss wrote:
On Monday, 25 October 2021 at 22:38:38 UTC, Imperatorn wrote:
On Monday, 25 October 2021 at 20:50:40 UTC, Steven Schveighoffer wrote:
On 10/24/21 8:00 AM, Selim Ozel wrote:
It turns out my computer was literally running out of memory as the
file was getting u
On Tuesday, 26 October 2021 at 06:32:21 UTC, bauss wrote:
On Monday, 25 October 2021 at 22:38:38 UTC, Imperatorn wrote:
On Monday, 25 October 2021 at 20:50:40 UTC, Steven
Schveighoffer wrote:
On 10/24/21 8:00 AM, Selim Ozel wrote:
[...]
Wait, x86 is 32-bit. Max address space is 4GB. So mayb
On Monday, 25 October 2021 at 22:38:38 UTC, Imperatorn wrote:
On Monday, 25 October 2021 at 20:50:40 UTC, Steven
Schveighoffer wrote:
On 10/24/21 8:00 AM, Selim Ozel wrote:
It turns out my computer was literally running out of memory
as the file was getting unzipped. For some reason to
uncom
On Monday, 25 October 2021 at 20:50:40 UTC, Steven Schveighoffer
wrote:
On 10/24/21 8:00 AM, Selim Ozel wrote:
It turns out my computer was literally running out of memory
as the file was getting unzipped. For some reason to
uncompress a 1-gig file with uncompressed size of 4-gig, Zip
Archiv
On 10/24/21 8:00 AM, Selim Ozel wrote:
It turns out my computer was literally running out of memory as the file
was getting unzipped. For some reason to uncompress a 1-gig file with
uncompressed size of 4-gig, Zip Archive of D-Lang tries to use more than
16 gig of RAM. I don't know why. Maybe
On Sunday, 24 October 2021 at 14:14:08 UTC, Imperatorn wrote:
Create an issue and we can solve it
Thanks. I opened an issue.
https://issues.dlang.org/show_bug.cgi?id=22436
On Sunday, 24 October 2021 at 12:00:39 UTC, Selim Ozel wrote:
On Friday, 15 October 2021 at 20:41:36 UTC, Selim Ozel wrote:
[...]
It turns out my computer was literally running out of memory as
the file was getting unzipped. For some reason to uncompress a
1-gig file with uncompressed size
has a solution? Memory mapping [2] previously solved
some part of my issue but expand is still throwing memory
allocation failure.
Selim
[1] https://dlang.org/phobos/std_zip.html
[2]
https://forum.dlang.org/thread/mfnleztnwrbgivjvz...@forum.dlang.org
It turns out my computer was literally running o
Did you try the MmFile workaround?
I did. I also pinpointed the problem, I use x86_mscoff to run dub
and it's specific to that architecture selection. It's related to
MapViewOfFileEx [1].
I still haven't found a way around it though.
[1]
https://stackoverflow.com/questions/12121843/mapview
has a solution? Memory mapping [2] previously solved
some part of my issue but expand is still throwing memory
allocation failure.
Selim
[1] https://dlang.org/phobos/std_zip.html
[2]
https://forum.dlang.org/thread/mfnleztnwrbgivjvz...@forum.dlang.org
Did you try the MmFile workaround?
issue but expand is still throwing memory allocation
failure.
Selim
[1] https://dlang.org/phobos/std_zip.html
[2]
https://forum.dlang.org/thread/mfnleztnwrbgivjvz...@forum.dlang.org
On Wednesday, 2 June 2021 at 17:52:12 UTC, mw wrote:
On Thursday, 12 November 2020 at 13:16:21 UTC, Steven
Schveighoffer wrote:
On 11/12/20 4:22 AM, Per Nordlöw wrote:
Why don't I get a stack trace on Memory allocation exceptions?
In my case I only get:
src/core/exception.d(647): [uni
On Thursday, 12 November 2020 at 13:16:21 UTC, Steven
Schveighoffer wrote:
On 11/12/20 4:22 AM, Per Nordlöw wrote:
Why don't I get a stack trace on Memory allocation exceptions?
In my case I only get:
src/core/exception.d(647): [unittest] Memory allocation f
On Wednesday, 24 February 2021 at 06:14:58 UTC, Imperatorn wrote:
On Tuesday, 23 February 2021 at 19:44:39 UTC, David wrote:
Not sure if `learn` is the right topic or not to post this..
I've been going through Bob Nystrom's "Crafting Interpreters"
for a bit of fun and over the weekend put toge
On Tuesday, 23 February 2021 at 19:44:39 UTC, David wrote:
Not sure if `learn` is the right topic or not to post this..
I've been going through Bob Nystrom's "Crafting Interpreters"
for a bit of fun and over the weekend put together a toy
allocator in D - free and gc not yet done. It's single
Not sure if `learn` is the right topic or not to post this..
I've been going through Bob Nystrom's "Crafting Interpreters" for
a bit of fun and over the weekend put together a toy allocator in
D - free and gc not yet done. It's single threaded and
unsurprisingly faster than malloc for small ob
On 11/12/20 4:22 AM, Per Nordlöw wrote:
Why don't I get a stack trace on Memory allocation exceptions?
In my case I only get:
src/core/exception.d(647): [unittest] Memory allocation failed
core.exception.OutOfMemoryError@src/core/exception.d(647): Memory
allocation failed
Certain e
On Thursday, 12 November 2020 at 09:22:10 UTC, Per Nordlöw wrote:
Why don't I get a stack trace on Memory allocation exceptions?
Is it because the stack may be corrupted?
Why don't I get a stack trace on Memory allocation exceptions?
In my case I only get:
src/core/exception.d(647): [unittest] Memory allocation failed
core.exception.OutOfMemoryError@src/core/exception.d(647): Memory
allocation failed
On Saturday, 13 July 2019 at 06:25:37 UTC, Andrey wrote:
On Tuesday, 9 July 2019 at 19:04:53 UTC, Max Haughton wrote:
Is this a 64 or 32 bit compiler? Also could you post the
source code if possible?
You could try "--DRT-gcopt=profile:1" druntime flag to see if
the compiler is running out of
On Tuesday, 9 July 2019 at 19:04:53 UTC, Max Haughton wrote:
Is this a 64 or 32 bit compiler? Also could you post the source
code if possible?
You could try "--DRT-gcopt=profile:1" druntime flag to see if
the compiler is running out of memory for real
Thanks for help. I solved my issue by re
Is this a 64 or 32 bit compiler? Also could you post the source
code if possible?
You could try "--DRT-gcopt=profile:1" druntime flag to see if the
compiler is running out of memory for real
On Tuesday, 9 July 2019 at 17:59:24 UTC, Max Haughton wrote:
On Tuesday, 9 July 2019 at 17:48:52 UTC, Andrey wrote:
Hello,
I have got a problem with compile-time calulations.
I have some code generator that should create some long string
of code during CT and after generation I mixin it. If I r
On Tuesday, 9 July 2019 at 17:59:24 UTC, Max Haughton wrote:
On Tuesday, 9 July 2019 at 17:48:52 UTC, Andrey wrote:
I in addition wrote "buffer.reserve(10 * 1014 * 1024);" and it
also doesn't help.
On Tuesday, 9 July 2019 at 17:48:52 UTC, Andrey wrote:
Hello,
I have got a problem with compile-time calulations.
I have some code generator that should create some long string
of code during CT and after generation I mixin it. If I run it
normally - in run time - then there is no error and I g
run it in CT then I recieve an error:
core.exception.OutOfMemoryError@core\exception.d(702): Memory
allocation failed
0x7FF65A80BE73
0x7FF65A80BE73
0x7FF65A80BB46
0x7FF65A7FBA5C
0x7FF65A8035EC
0x7FF65A804311
0x7FF658BA733E
0x7FF658CC561F
On Saturday, 22 June 2019 at 16:52:07 UTC, Anonymouse wrote:
When entering the following function, does it allocate:
1. 0 times, because while there are closures defined, none is
ever called?
2. 2 times, because there are closures over two variables?
3. 20 times, because there are 20 unique cl
On Saturday, 22 June 2019 at 19:26:13 UTC, Cym13 wrote:
On Saturday, 22 June 2019 at 16:52:07 UTC, Anonymouse wrote:
[...]
Clearly this is a good time for you to learn about the tools D
offers to profile allocations. There is the --profile=gc DMD
argument that you can use but here there's so
On Saturday, 22 June 2019 at 16:52:07 UTC, Anonymouse wrote:
I'm looking into why my thing does so many memory allocations.
Profiling with kcachegrind shows _d_allocmemory being called
upon entering a certain function, lots and lots of times.
It's a function that receives concurrency messages,
I'm looking into why my thing does so many memory allocations.
Profiling with kcachegrind shows _d_allocmemory being called upon
entering a certain function, lots and lots of times.
It's a function that receives concurrency messages, so it
contains nested functions that close over local variab
On Monday, December 25, 2017 15:00:19 aliak via Digitalmars-d-learn wrote:
> On Monday, 25 December 2017 at 14:12:32 UTC, Marc wrote:
> > Does to!(string)(char[]) do any memory allocation on conversion
> > or is this similar to a cast or what else?
>
> As said it ca
On Monday, 25 December 2017 at 14:12:32 UTC, Marc wrote:
Does to!(string)(char[]) do any memory allocation on conversion
or is this similar to a cast or what else?
As said it calls idup, which calls _trustedDup which seems to
call _dup which does memory allocation ->
https://github.com/dl
On Monday, 25 December 2017 at 14:37:01 UTC, Mengu wrote:
On Monday, 25 December 2017 at 14:12:32 UTC, Marc wrote:
Does to!(string)(char[]) do any memory allocation on
conversion or is this similar to a cast or what else?
yes, it is allocating memory. you can test such cases with
@nogc [0
On Monday, 25 December 2017 at 14:12:32 UTC, Marc wrote:
Does to!(string)(char[]) do any memory allocation on conversion
or is this similar to a cast or what else?
yes, it is allocating memory. you can test such cases with @nogc
[0].
you can get a char[] via .dup of a string and then you
On Monday, 25 December 2017 at 14:37:01 UTC, Mengu wrote:
yes, it is allocating memory. you can test such cases with
@nogc [0].
nogc is really conservative and thus gives a lot of false
positives. I'd just compare instr.ptr is outstr.ptr here and see
if it changes (it will tho)
On Monday, 25 December 2017 at 14:12:32 UTC, Marc wrote:
Does to!(string)(char[]) do any memory allocation on conversion
or is this similar to a cast or what else?
It is translated to idup.
So yes, it allocates memory.
Does to!(string)(char[]) do any memory allocation on conversion
or is this similar to a cast or what else?
On Thursday, 8 June 2017 at 17:39:41 UTC, Ivan Kazmenko wrote:
Reported: https://issues.dlang.org/show_bug.cgi?id=17481
Thank You!
On Thursday, 8 June 2017 at 15:35:06 UTC, Ivan Kazmenko wrote:
Perhaps a regression should be filed, or searched for, at
issues.dlang.org. I can do it, but not right now, and would be
glad if someone beats me to it.
Reported: https://issues.dlang.org/show_bug.cgi?id=17481
On Thursday, 8 June 2017 at 11:41:40 UTC, realhet wrote:
I've managed to narrow the problem even more:
//win32 dmd -O
class Obj{
synchronized void trigger(){ new ubyte[1]; }
}
void main(){
auto k = new shared Obj;
k.trigger;
}
This time I got a more sophisticated error message:
object.
I've managed to narrow the problem even more:
//win32 dmd -O
class Obj{
synchronized void trigger(){ new ubyte[1]; }
}
void main(){
auto k = new shared Obj;
k.trigger;
}
This time I got a more sophisticated error message:
object.Error@(0): Access Violation
0x7272456D in
realhet wrote:
On Thursday, 8 June 2017 at 10:48:41 UTC, ketmar wrote:
worksforme with -O, and with -O -inline.
I forgot to mention, that I'm generating win32 output.
DMD32 D Compiler v2.074.0
mine: GNU/Linux, 32 bit, dmd git HEAD.
On Thursday, 8 June 2017 at 10:48:41 UTC, ketmar wrote:
worksforme with -O, and with -O -inline.
I forgot to mention, that I'm generating win32 output.
DMD32 D Compiler v2.074.0
worksforme with -O, and with -O -inline.
Hi,
This code works well with the unoptimized compilation with DMD.
import std.array;
synchronized class Obj{
private int[] arr;
void trigger(){ arr.length += 1; }
}
void main(){
auto k = new shared Obj;
k.trigger;
}
And when I use the -O option, it shows the following error in the
t
On Thursday, 30 March 2017 at 11:22:05 UTC, Gary Willoughby wrote:
On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
I have a memory buffer allocated using different methods. It
is simply a pointer and a size.
I would like to be able to manage this buffer by treating it
as a memory p
On Wednesday, 29 March 2017 at 23:26:04 UTC, H. S. Teoh wrote:
On Wed, Mar 29, 2017 at 11:01:12PM +, Enigma via
Digitalmars-d-learn wrote:
On Wednesday, 29 March 2017 at 21:36:14 UTC, Petar Kirov
[ZombineDev] wrote:
> [...]
But these seem to require passing a mallocator. I simply want
to
On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
I have a memory buffer allocated using different methods. It is
simply a pointer and a size.
I would like to be able to manage this buffer by treating it as
a memory pool or heap. I think I can use allocators to do this
but not sure h
On Wed, Mar 29, 2017 at 11:01:12PM +, Enigma via Digitalmars-d-learn wrote:
> On Wednesday, 29 March 2017 at 21:36:14 UTC, Petar Kirov [ZombineDev] wrote:
> > On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
> > > [...]
> >
> > It looks like you are looking for this:
> > http://dlang
On Wednesday, 29 March 2017 at 21:36:14 UTC, Petar Kirov
[ZombineDev] wrote:
On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
[...]
It looks like you are looking for this:
http://dlang.org/phobos-prerelease/std_experimental_allocator_building_blocks_region.html.
But these seem to
On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
I have a memory buffer allocated using different methods. It is
simply a pointer and a size.
I would like to be able to manage this buffer by treating it as
a memory pool or heap. I think I can use allocators to do this
but not sure h
On 2017-03-29 23:30, Faux Amis wrote:
On 2017-03-29 21:19, Enigma wrote:
I have a memory buffer allocated using different methods. It is simply a
pointer and a size.
Can you maybe just tread it like an array and slice it for allocation?
*treat*
On 2017-03-29 21:19, Enigma wrote:
I have a memory buffer allocated using different methods. It is simply a
pointer and a size.
Can you maybe just tread it like an array and slice it for allocation?
I have a memory buffer allocated using different methods. It is
simply a pointer and a size.
I would like to be able to manage this buffer by treating it as a
memory pool or heap. I think I can use allocators to do this but
not sure how.
Effectively I want something like new or malloc but it
On Tuesday, 22 November 2016 at 15:53:39 UTC, Steven
Schveighoffer wrote:
On 11/21/16 11:53 AM, ag0aep6g wrote:
Thank you very much for explaining such a difficult and slippery
situation.
On 11/21/16 11:53 AM, ag0aep6g wrote:
On Monday, 21 November 2016 at 16:37:32 UTC, Kagamin wrote:
Anything in .data and .bss sections and stack. See
https://issues.dlang.org/show_bug.cgi?id=15723
Ok, not an actual reference then, but a false pointer.
Yes. 100 million bytes is 1/40 of all add
On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
core.exception.OutOfMemoryError@src\core\exception.d(693):
Memory allocation failed
Simple program and error. Why? Windows 7 (32) dmd 2.072.0
Making a 100 million bytes array by appending one byte at
On Monday, 21 November 2016 at 16:37:32 UTC, Kagamin wrote:
Anything in .data and .bss sections and stack. See
https://issues.dlang.org/show_bug.cgi?id=15723
Ok, not an actual reference then, but a false pointer.
On Monday, 21 November 2016 at 11:22:40 UTC, ag0aep6g wrote:
Who could "someone" be? It's a self-contained example, and buf
doesn't leave the test function.
Anything in .data and .bss sections and stack. See
https://issues.dlang.org/show_bug.cgi?id=15723
As for GC compaction:
https://issues
On 11/21/2016 08:27 AM, Stefan Koch wrote:
Someone could still be hanging on to an old Reference of buf.
Who could "someone" be? It's a self-contained example, and buf doesn't
leave the test function.
On Monday, 21 November 2016 at 06:45:04 UTC, ag0aep6g wrote:
On 11/21/2016 07:36 AM, Stefan Koch wrote:
On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:
On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
[...]
[...]
Y
On 11/21/2016 07:36 AM, Stefan Koch wrote:
On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:
On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
import core.sys.windows.windows: MessageBoxA;
void test() {
for(int i; i
;.ptr, 0);
}
void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}
core.exception.OutOfMemoryError@src\core\exception.d(693):
Memory allocation failed
This short program doesn't work at Windows 32. Why GC do
eBoxA(null, "--The end--".ptr, "".ptr, 0);
}
core.exception.OutOfMemoryError@src\core\exception.d(693):
Memory allocation failed
This short program doesn't work at Windows 32. Why GC doesn't
release memory in case of its shortage in Windows! This is bug?
On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:
On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:
[...]
For me there's no exception. Maybe the GC is poluted. Try to
add this after each iteration in the first test loop:
import core.memory: GC;
GC.collect()
}
core.exception.OutOfMemoryError@src\core\exception.d(693):
Memory allocation failed
Simple program and error. Why? Windows 7 (32) dmd 2.072.0
For me there's no exception. Maybe the GC is poluted. Try to add
this after each iteration in the first test lo
buf; // if ON - then memory delete in step
}
MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}
void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}
core.exception.OutOfMemo
On Sat, 20 Feb 2016 16:58:02 +, Adam D. Ruppe wrote:
> On Saturday, 20 February 2016 at 14:21:28 UTC, tcak wrote:
>> What happens if memory allocation fails with "new" keyword?
>
> Be aware that memory allocation might never actually fail. It really
> dep
On Saturday, 20 February 2016 at 14:21:28 UTC, tcak wrote:
What happens if memory allocation fails with "new" keyword?
Be aware that memory allocation might never actually fail. It
really depends on the operating system.
But if it did fail, it would throw OutOfMemoryE
Currently it crashes:
https://issues.dlang.org/show_bug.cgi?id=1180
This is not easy to try. So I need ask, maybe someone has
experienced.
What happens if memory allocation fails with "new" keyword? Does
it
throw an exception? throwable?
All I want is to be able to catch OutOfMemory event, and take
other
steps based on that.
On Monday, 21 December 2015 at 09:46:58 UTC, Shriramana Sharma
wrote:
Jonathan M Davis via Digitalmars-d-learn wrote:
If it isn't, all that means is that the
array's capacity will be 0, so it's going to have to reallocate
So it's safe to return a string produced by fromStringz without
having
Jonathan M Davis via Digitalmars-d-learn wrote:
> If it isn't, all that means is that the
> array's capacity will be 0, so it's going to have to reallocate
So it's safe to return a string produced by fromStringz without having to
worry that the user would append to it?
Then why is it marked @sy
On Monday, 21 December 2015 at 08:35:22 UTC, Jonathan M Davis
wrote:
There's also fromStringz that Jakob suggests using elsewhere in
this thread, but that really just boils down to
return cString ? cString[0 .. strlen(cString)] : null;
So, using that over simply slicing is primarily for
d
On Monday, December 21, 2015 18:39:32 Rikki Cattermole via Digitalmars-d-learn
wrote:
> size_t strLen = ...;
> char* ptr = ...;
>
> string myCString = cast(string)ptr[0 .. strLen];
>
> I can't remember if it will include the null terminator or not, but if
> it does just decrease strLen by 1.
Cast
On Monday, December 21, 2015 05:43:59 Jakob Ovrum via Digitalmars-d-learn wrote:
> On Monday, 21 December 2015 at 05:41:31 UTC, Shriramana Sharma
> wrote:
> > Rikki Cattermole wrote:
> >
> >> string myCString = cast(string)ptr[0 .. strLen];
> >
> > Thanks but does this require that one doesn't atte
On Monday, 21 December 2015 at 06:00:45 UTC, Shriramana Sharma
wrote:
I suppose what you mean is, the onus of guaranteeing that
const(char)* refers to a null-terminated string is upon the
person calling the to! function? Yes I understand, and Phobos
documentation does say that using a pointer f
Jakob Ovrum wrote:
> Use std.string.fromStringz. to!string assumes that pointers to
> characters are null-terminated strings which is not safe or
> general
I suppose what you mean is, the onus of guaranteeing that const(char)*
refers to a null-terminated string is upon the person calling the to
On Monday, 21 December 2015 at 05:39:32 UTC, Rikki Cattermole
wrote:
size_t strLen = ...;
char* ptr = ...;
string myCString = cast(string)ptr[0 .. strLen];
I can't remember if it will include the null terminator or not,
but if it does just decrease strLen by 1.
Strings from C libraries shoul
On Monday, 21 December 2015 at 05:43:04 UTC, Rikki Cattermole
wrote:
On 21/12/15 6:41 PM, Shriramana Sharma wrote:
Rikki Cattermole wrote:
string myCString = cast(string)ptr[0 .. strLen];
Thanks but does this require that one doesn't attempt to
append to the
returned string using ~= or such
Rikki Cattermole wrote:
> string myCString = cast(string)ptr[0 .. strLen];
Thanks but does this require that one doesn't attempt to append to the
returned string using ~= or such? In which case it is not safe, right?
--
Shriramana Sharma, Penguin #395953
On 21/12/15 6:41 PM, Shriramana Sharma wrote:
Rikki Cattermole wrote:
string myCString = cast(string)ptr[0 .. strLen];
Thanks but does this require that one doesn't attempt to append to the
returned string using ~= or such? In which case it is not safe, right?
Correct, ~= should only be use
On Monday, 21 December 2015 at 05:41:31 UTC, Shriramana Sharma
wrote:
Rikki Cattermole wrote:
string myCString = cast(string)ptr[0 .. strLen];
Thanks but does this require that one doesn't attempt to append
to the returned string using ~= or such? In which case it is
not safe, right?
Grow
On Monday, 21 December 2015 at 05:34:07 UTC, Shriramana Sharma
wrote:
Hello. I have the following code:
import std.stdio, std.conv;
extern(C) const(char) * textAttrN(const (char) * specString,
size_t n);
string textAttr(const(char)[] specString)
{
const(char) * ptr = textAttrN(specString.p
On 21/12/15 6:34 PM, Shriramana Sharma wrote:
Hello. I have the following code:
import std.stdio, std.conv;
extern(C) const(char) * textAttrN(const (char) * specString, size_t n);
string textAttr(const(char)[] specString)
{
const(char) * ptr = textAttrN(specString.ptr, specString.length);
Hello. I have the following code:
import std.stdio, std.conv;
extern(C) const(char) * textAttrN(const (char) * specString, size_t n);
string textAttr(const(char)[] specString)
{
const(char) * ptr = textAttrN(specString.ptr, specString.length);
writeln(ptr);
return to!string(ptr);
}
voi
(not translated into D yet)
http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-java-7-garbage-collectors/
http://www.mm-net.org.uk/resources/benchmarks.html
http://www.ccs.neu.edu/home/will/GC/sourcecode.html
http://yoda.arachsys.com/csharp/benchmark.html
it's possible we already have bett
On Friday, 5 September 2014 at 06:43:56 UTC, monarch_dodra wrote:
On Sunday, 24 August 2014 at 09:29:53 UTC, Jacob Carlborg wrote:
On 2014-08-24 10:03, Bienlein wrote:
I have omitted the code for the TestClass class to save
space. Problem
is that the compiler outputs this:
Error: @nogc funct
On Sunday, 24 August 2014 at 09:29:53 UTC, Jacob Carlborg wrote:
On 2014-08-24 10:03, Bienlein wrote:
I have omitted the code for the TestClass class to save space.
Problem
is that the compiler outputs this:
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew'
cannot call
non-@nogc fu
1 - 100 of 149 matches
Mail list logo
