On 03.09.19 16:03, James Blachly wrote:
For my own learning, why was a unittest to ensure no GC added to sformat
instead of a @nogc annotation?
`sformat` uses the GC less now, but it's not @nogc. It can still throw
GC-allocated exceptions, e.g. when the arguments don't match the format
string
On 8/31/19 5:12 PM, ag0aep6g wrote:
I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163
Wonderful!
For my own learning, why was a unittest to ensure no GC added to sformat
instead of a @nogc annotation?
On Saturday, 31 August 2019 at 21:12:32 UTC, ag0aep6g wrote:
I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163
Thanks for the responses, very cool seeing these updates happen
so fluidly.
On Saturday, 31 August 2019 at 21:12:32 UTC, ag0aep6g wrote:
I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163
Merged.
On 31.08.19 14:07, cc wrote:
I'm guessing it's allocating a string first to write the contents
of the array and then inserting that string into the buffer I supplied.
Is there no way to have it skip this step and just write each element
(plus the joining punctuation, etc) directly into the buf
On Saturday, 31 August 2019 at 12:07:56 UTC, cc wrote:
And what, if anything, can I do to avoid it?
import core.stdc.stdio : printf;
There are no @nogc versions of the Phobos write* and format
functions.
, 1048304, 272)
["abcd", "efgh", "ijkl"]
Stats(464, 1048112, 464)
I get similar behavior trying to use formattedWrite with an
appender:
string[] arr = ["abcd", "efgh", "ijkl"];
s any
significant difference in compilation-speed and if formatValue
and/or formattedWrite needs to allocate using the GC when we are
writing a array of `char`s or a long, directly to standard
output. In theory the string could be written directly to stdout
without an extra memory buffer and the
Is `formatValue` also preferred over `formattedWrite` when
writing a single value?
Code example:
import std.array : appender;
auto writer1 = appender!string();
writer1.formattedWrite("%08b", 42);
auto writer2 = appender!string();
auto f = singleSpec("%08b");
writer2.form
ormat : formattedWrite;
const x = "42";
alias A = CopyableArray!(char);
A a;
a.formattedWrite!("x : %s")(x);
assert(a == "x : 42");
}
but I can't tag the unittest as `nothrow @nogc` because of the
call to `formattedWrite`. Is this because `formattedW
On Saturday, 7 October 2017 at 18:27:36 UTC, jmh530 wrote:
On Saturday, 7 October 2017 at 18:14:00 UTC, Nordlöw wrote:
It would be nice to be able to formatted output in -betterC...
Agreed. If you know the size of the buffer, you can use
sformat, which might be @nogc, but I don't know if it'
On Saturday, 7 October 2017 at 18:14:00 UTC, Nordlöw wrote:
It would be nice to be able to formatted output in -betterC...
Agreed. If you know the size of the buffer, you can use sformat,
which might be @nogc, but I don't know if it's compatible with
betterC. Also, you might check out Ocean,
Is it currently possible to somehow do @nogc formatted output to
string?
I'm currently using my `pure @nogc nothrow` array-container
`CopyableArray` as
@safe pure /*TODO nothrow @nogc*/ unittest
{
import std.format : formattedWrite;
const x = "42";
alias A = Copy
On Thursday, 4 September 2014 at 17:06:00 UTC, Márcio Martins
wrote:
On Wednesday, 3 September 2014 at 07:43:20 UTC, Guillaume
Chatelet wrote:
+1 I've been bitten by this also.
Same here, +1
It's still on my radar, but it's actually not that trivial of a
change, especially if we want to avo
On Wednesday, 3 September 2014 at 07:43:20 UTC, Guillaume
Chatelet wrote:
+1 I've been bitten by this also.
Same here, +1
+1 I've been bitten by this also.
I logged this bug a while ago:
https://issues.dlang.org/show_bug.cgi?id=10291
On Friday, 2 May 2014 at 10:06:43 UTC, ref2401 wrote:
Is it a bug or is there a reason for such behaviour?
On Friday, 2 May 2014 at 10:23:03 UTC, Andrej Mitrovic via
Digitalmars-d-learn wrote:
Ouch, ouch, ouch! What's happening is that the 'clear' Appender
method
is only compiled-in if the data is mutable, otherwise you end up
calling the object.clear UFCS function. So don't use clear here.
I don't
On 5/2/14, ref2401 via Digitalmars-d-learn
wrote:
> class MyClass {
> Appender!string _stringBuilder;
>
> this() {
> _stringBuilder = Appender!string(null);
> _stringBuilder.clear();
Ouch, ouch, ouch! What's happening is that the 'clear' Appender method
is
) {
formattedWrite(_stringBuilder, "%s", s);
}
}
MyClass c = new MyClass();
c.append("text 1");
c.append("__222");
writeln(c.str); //in this case nothing is printed out
Following workarounds work:
1) call _stringBuilder.put() ins
On Sunday, 19 January 2014 at 15:28:04 UTC, Tobias Pankrath wrote:
On Sunday, 19 January 2014 at 15:12:07 UTC, Tobias Pankrath
wrote:
On Sunday, 19 January 2014 at 15:03:13 UTC, monarch_dodra
wrote:
So, my conclusion, "*" might be a workable solution. But
simply taking by ref would be cleaner
On Sunday, 19 January 2014 at 15:12:07 UTC, Tobias Pankrath wrote:
On Sunday, 19 January 2014 at 15:03:13 UTC, monarch_dodra wrote:
So, my conclusion, "*" might be a workable solution. But
simply taking by ref would be cleaner, and make more sense as
a whole.
Or a special template constraint
On Saturday, 18 January 2014 at 23:06:42 UTC, Tobias Pankrath
wrote:
I actually didn't think that a ptr (to output range) would
work. This way we can have best of both worlds and I'm happy
with it.
A fun fact is that since "." notation works with pointers, more
often than not, if "T" verifies
On Sunday, 19 January 2014 at 15:03:13 UTC, monarch_dodra wrote:
So, my conclusion, "*" might be a workable solution. But simply
taking by ref would be cleaner, and make more sense as a whole.
Or a special template constraint path for T*.
foo(T)(T t) if (is(T = Q*)) && manyOtherChecks!(Q)
foo
has internal state and if I
want to use formattedWrite with this wrapper than state changes
don't propagate to the calling context because by value
semantics.
Short solution: I'm using a class now.
Alternatively, pass a pointer: formattedWrite(&writer, ...)
On Saturday, 18 January 2014 at 22:58:59 UTC, bearophile wrote:
monarch_dodra:
*I* think it should. File a report, and I'll see what I can do
about it. The problem with these kinds of things though might
be breaking existing code...
Given the frequency of bugs caused by such functions that
has internal state and if I
want to use formattedWrite with this wrapper than state changes
don't propagate to the calling context because by value
semantics.
Short solution: I'm using a class now. But shouldn't
formattedWrite take it's output range by ref? Does anyone e
monarch_dodra:
*I* think it should. File a report, and I'll see what I can do
about it. The problem with these kinds of things though might
be breaking existing code...
Given the frequency of bugs caused by such functions that require
a pointer to the data, I think that a breaking change is
I want to print a tree structure and need to keep track of the
indention for different parts of the tree. My idea was to write a
generic wrapper for an output range that outputs tabs when it
encounters a newline. This wrapper has internal state and if I
want to use formattedWrite with this
On 08.08.2011 14:07, simendsjo wrote:
On 08.08.2011 13:41, simendsjo wrote:
On 08.08.2011 13:37, Vladimir Panteleev wrote:
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo
wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
Thanks, that wa
On 08.08.2011 13:41, simendsjo wrote:
On 08.08.2011 13:37, Vladimir Panteleev wrote:
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo
wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
Thanks, that was the function I was looking for. I jus
On 08.08.2011 13:37, Vladimir Panteleev wrote:
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
Thanks, that was the function I was looking for. I just expected it to
be in std.format (and
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo wrote:
I cannot find any string format() method in phobos.
What's wrong with format() from std.string?
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
I cannot find any string format() method in phobos.
Having to do:
auto a = appender!string();
formattedWrite(a, "", ...);
a.data
seems unnecessary in many cases.
34 matches
Mail list logo
