Re: Most performant way of converting int to string
On Wednesday, 23 December 2015 at 22:29:31 UTC, Andrew Chapman wrote: On Wednesday, 23 December 2015 at 11:46:37 UTC, Jakob Ovrum wrote: On Wednesday, 23 December 2015 at 11:21:32 UTC, Jakob Ovrum wrote: Dynamic memory allocation is expensive. If the string is short-lived, allocate it on the stack: See also std.conv.toChars[1] for stringifying lazily/on-demand. http://dlang.org/phobos/std_conv#toChars Thanks Jakob! I did try toChars but I couldn't quite figure out a syntax of calling it that the compiler was happy with. From memory I tried things along the lines of: string v = toChars!(16,char,LetterCase.lower)(i); to convert an integer to Hex for example, but the compiler wasn't happy with it. How would I convert an int to a string using this? Cheers. I haven't tested it, but: `toChars` doesn't return a string -- that's the whole point :) It returns a range, so you have to call it something like: auto v = toChars!(16,char,LetterCase.lower)(i);
Re: How is D doing?
On Thu, Dec 24, 2015 at 07:19:20AM +, rsw0x via Digitalmars-d-learn wrote: > On Thursday, 24 December 2015 at 06:10:55 UTC, H. S. Teoh wrote: > >On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via Digitalmars-d-learn > >wrote: [...] > >>D, as I expected, has a massive following in Japan. I'm still not > >>quite sure why. > > > >Maybe because one of the most prolific contributors to D, esp. to > >dmd, (and by far) happens to be from Japan? > > > > > >T > > I'm aware of Kenji, I'm just not sure why because I never notice that > many Japanese posters here. [...] Maybe because this forum is English-based? Just a conjecture. T -- Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown
Re: How is D doing?
On Thursday, 24 December 2015 at 06:10:55 UTC, H. S. Teoh wrote: On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via Digitalmars-d-learn wrote: [...] D, as I expected, has a massive following in Japan. I'm still not quite sure why. Maybe because one of the most prolific contributors to D, esp. to dmd, (and by far) happens to be from Japan? T I'm aware of Kenji, I'm just not sure why because I never notice that many Japanese posters here. It seems quite popular on Twitter with Japanese users though which is why I'm familiar with its popularity in Japan.
Re: How is D doing?
On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via Digitalmars-d-learn wrote: [...] > D, as I expected, has a massive following in Japan. I'm still not > quite sure why. Maybe because one of the most prolific contributors to D, esp. to dmd, (and by far) happens to be from Japan? T -- Many open minds should be closed for repairs. -- K5 user
Re: How is D doing?
On Thursday, 24 December 2015 at 00:16:16 UTC, rsw0x wrote: On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote: On Tuesday, 22 December 2015 at 17:49:34 UTC, Jakob Jenkov wrote: clip removed C++ because it just dwarfs the others. D, as I expected, has a massive following in Japan. I'm still not quite sure why. Hey, this can be D's theme song: https://www.youtube.com/watch?v=Cg6rp20OGLo
Re: Graphics/font/platform backends with common interfaces?
On 24/12/15 4:03 PM, Taylor Hillegeist wrote: On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote: On 24/12/15 8:22 AM, Taylor Hillegeist wrote: [...] So far I've been implementing windowing and image libraries for Phobos. Right now windowing works on Windows minice eventing. Once eventing is done it is ready for the first stage of feedback. [...] How do you handle fonts? Once my existing backlog is complete I /may/ consider a font rasterizer.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote: On 24/12/15 8:22 AM, Taylor Hillegeist wrote: [...] So far I've been implementing windowing and image libraries for Phobos. Right now windowing works on Windows minice eventing. Once eventing is done it is ready for the first stage of feedback. [...] How do you handle fonts?
What's wrong with my debugger?
Please see the linked screenshot: http://i.imgur.com/SpkXu5m.png As you can see, the inside, outside and collision arrays don't seem to work with the debugger. They show a bogus lenght and a bogus memory address. Extracting the lenghts to separate variables outl, insl and coll show that the arrays actually behave properly, though. Is that a debugger bug? Or maybe something I can fix? Thanks in advance. DMD 2.069.2, Mago debugger, VisualD 3.43, compiling for 32 bits if that makes a difference (can't get either 64 bit compilation or LDC to work)
Re: How is D doing?
On Thursday, 24 December 2015 at 00:16:16 UTC, rsw0x wrote: restrict it to 'programming' to get a more accurate assessment of D. https://google.com/trends/explore#cat=0-5-31&q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q&date=1%2F2010%2061m&cmpt=q&tz=Etc%2FGMT-2 removed C++ because it just dwarfs the others. D, as I expected, has a massive following in Japan. I'm still not quite sure why. 3 d language 3 d programming ?
Re: How is D doing?
On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote: On Tuesday, 22 December 2015 at 17:49:34 UTC, Jakob Jenkov wrote: On Tuesday, 22 December 2015 at 03:30:32 UTC, ShinraTensei wrote: I recently noticed massive increase in new languages for a person to jump into(Nim, Rust, Go...etc) but my question is weather the D is actually used anywhere or are there chances of it dying anytime soon. Check out Google Trends. Searches for D Tutorial still beats searches for Scala Tutorial by a big margin: https://google.com/trends/explore#q=d%20tutorial%2C%20scala%20tutorial Google Trends shows something interesting: https://google.com/trends/explore#q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT-2 restrict it to 'programming' to get a more accurate assessment of D. https://google.com/trends/explore#cat=0-5-31&q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q&date=1%2F2010%2061m&cmpt=q&tz=Etc%2FGMT-2 removed C++ because it just dwarfs the others. D, as I expected, has a massive following in Japan. I'm still not quite sure why.
Re: Graphics/font/platform backends with common interfaces?
On 24/12/15 8:22 AM, Taylor Hillegeist wrote:
So I have seen alot of projects that need the same sort of stuff.
graphics libraries
gui libraries
game libraries
ploting libaries
they would all benefit from a backend solution with a common interface for
color
fonts
drawing pen_style aliasing etc.
but each one i look at seems to have a built up solution with various
degrees of integration with things like freetype gdi cairo sdl glew opengl.
Shouldn't there be like a common (interface/abstract class) that these
back-ends can fulfill? maybe I am unaware of how these things are done.
And perhaps there are performance reasons that many of these are baked in.
perhaps it should be like:
standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.
//probably a grotesque simplification
interface font_do{
glyphstrokes getstrokes(string characterstoget);
}
interface draw_do{
drawpixel(double x,double y);
drawline(double x,double y);
drawglyph(glypstrokes g);
getpostdrawnsize(glypstroks g)
... other things
}
So far I've been implementing windowing and image libraries for Phobos.
Right now windowing works on Windows minice eventing. Once eventing is
done it is ready for the first stage of feedback.
Image library is nearly ready for next batch of feedback, PNG
read/writer is ugh not passing its tests for palette + Adam7 interlacing.
All in all looking at second half of next year for completion.
Manu Evans has been working on the color library which I use.
The vertices definition I am using is from gfm:math with permission for
Phobos inclusion but that needs drastic changes and somebody to take
ownership of.
Of course that really doesn't help when it comes to e.g. font
rasterization. But they are core and must be working first.
Re: Most performant way of converting int to string
On 12/23/2015 02:29 PM, Andrew Chapman wrote:
> string v = toChars!(16,char,LetterCase.lower)(i);
>
> to convert an integer to Hex for example, but the compiler wasn't happy
> with it. How would I convert an int to a string using this?
I had to squint at the error message to understand that the 16
specialization for radix requires that the value is unsigned. The
following works:
import std.conv;
import std.algorithm;
void main() {
assert(1234u// <-- unsigned
.toChars!(16, char, LetterCase.lower)
.equal("4d2"));
}
Ali
Re: Most performant way of converting int to string
On Wednesday, 23 December 2015 at 11:46:37 UTC, Jakob Ovrum wrote: On Wednesday, 23 December 2015 at 11:21:32 UTC, Jakob Ovrum wrote: Dynamic memory allocation is expensive. If the string is short-lived, allocate it on the stack: See also std.conv.toChars[1] for stringifying lazily/on-demand. http://dlang.org/phobos/std_conv#toChars Thanks Jakob! I did try toChars but I couldn't quite figure out a syntax of calling it that the compiler was happy with. From memory I tried things along the lines of: string v = toChars!(16,char,LetterCase.lower)(i); to convert an integer to Hex for example, but the compiler wasn't happy with it. How would I convert an int to a string using this? Cheers.
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 19:27:31 UTC, earthfront wrote: On Wednesday, 23 December 2015 at 11:12:22 UTC, ZombineDev wrote: Actually array() is from sts.array and correct way to use selective imports is: import std.exception : enforce; import std.array : array; import std.algorithm.iteration : filter; import std.functional : memoize; If you want to import several symbols from one module, you can list them after the column like so: import std.algorithm : any, find, sort /*, etc... */; I hadn't compiled yet, so the array thing is indeed an error. So there's no way to combine these _selective_ imports on a single line, like I can with regular _module_ imports: import std.exception, std.array, std.functional; Correct? Yes, it is not allowed by the grammar. I think the reason is that the list items would become ambiguous (the difference between selected symbols and module names could only be revealed after semantic analysis). See for example: import abc : cba, dcb, bca : acb, dbc; // What is dbc? A module or a member of bca?
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 21:19:14 UTC, Taylor Hillegeist wrote: On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist wrote: On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote: [...] Thanks for letting me know! So is what your saying is that an common interface is not possible or practical or perhaps useful? Also wouldn't the least common denominator be 2D FP in Retained Mode? Yes. and 2D FP immediate the most common then. GDI+, cairo, OGL ok. GDI with a lot of rouding.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist wrote: On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote: [...] Thanks for letting me know! So is what your saying is that an common interface is not possible or practical or perhaps useful? It's possible but it seems to be complex.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist wrote: On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote: [...] Thanks for letting me know! So is what your saying is that an common interface is not possible or practical or perhaps useful? Also wouldn't the least common denominator be 2D FP in Retained Mode?
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote: On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe wrote: [...] yes silly, more specially as - some of them are 2D with FP coordinates - some of them are 2D with integral coordinates - some of them are 2D with integral coordinates with transformation of the plan - some of them are 2D with integral coordinates without transformation of the plan - some of them are 3D FP float coordinates with transformation of the plan - some of them are in DirectMode, some of them not. - etc... So this would result in 5 or 6 templatized (because of the coord type) interface. IIRC Interfaces are not devirtualizables so that they can be extracted... also to put SDL and OPENGL on the same level is a bit strange. Thanks for letting me know! So is what your saying is that an common interface is not possible or practical or perhaps useful?
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 20:57:27 UTC, Taylor Hillegeist wrote: On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe wrote: On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor Hillegeist wrote: | GRAPICS LIB | +---+---+---+ <- what is this interface |SDL|GDI|OPENGL.| +---+---+---+ SDL, GDI, and OpenGL *are* graphics libs so it seems a bit silly to put an interface there. I guess I'm thinking that to be able to switch between backends(gdi sdl) you use you must have a common interface. And if everyone had the same common interface it could be nice right? maybe this is more what I'm thinking. +-+ | USER APP| +-+ | GUI LIB | +-+ <- what is this interface |GenericGL| +-+ <- what is this interface |NativeGL | +-+
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe wrote: On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor Hillegeist wrote: | GRAPICS LIB | +---+---+---+ <- what is this interface |SDL|GDI|OPENGL.| +---+---+---+ SDL, GDI, and OpenGL *are* graphics libs so it seems a bit silly to put an interface there. yes silly, more specially as - some of them are 2D with FP coordinates - some of them are 2D with integral coordinates - some of them are 2D with integral coordinates with transformation of the plan - some of them are 2D with integral coordinates without transformation of the plan - some of them are 3D FP float coordinates with transformation of the plan - some of them are in DirectMode, some of them not. - etc... So this would result in 5 or 6 templatized (because of the coord type) interface. IIRC Interfaces are not devirtualizables so that they can be extracted... also to put SDL and OPENGL on the same level is a bit strange.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe wrote: On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor Hillegeist wrote: | GRAPICS LIB | +---+---+---+ <- what is this interface |SDL|GDI|OPENGL.| +---+---+---+ SDL, GDI, and OpenGL *are* graphics libs so it seems a bit silly to put an interface there. I guess I'm thinking that to be able to switch between backends(gdi sdl) you use you must have a common interface. And if everyone had the same common interface it could be nice right?
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 19:34:26 UTC, earthfront wrote: On Wednesday, 23 December 2015 at 11:00:19 UTC, Jakob Ovrum wrote: [...] My goal is to import several symbols from different modules on one line. I'm trying to figure out if it's possible or not. It makes the code more concise in some cases. This is not available in the grammar. You can still open a duplicate enhancement request. https://issues.dlang.org/show_bug.cgi?id=14704 see also: http://forum.dlang.org/post/trrxoacvpyyqrdfqx...@forum.dlang.org I remember also another NG thread about this. A guy wanted this feature because he thought that this would allow him to write faster during a Hackathlon or something like that.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor Hillegeist wrote: | GRAPICS LIB | +---+---+---+ <- what is this interface |SDL|GDI|OPENGL.| +---+---+---+ SDL, GDI, and OpenGL *are* graphics libs so it seems a bit silly to put an interface there.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 20:23:25 UTC, rumbu wrote: On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor It was an initiative, but it looks abandoned now (Aurora Graphics): Thread: http://forum.dlang.org/thread/op.w9w0efr1707...@invictus.hra.local Source Code: https://github.com/auroragraphics/ I know I was excited when It was announced at DConf 2014. It really is too bad. what can be done now? how are standards defined around here for the benefit of the community? +---+ | USER APP| +---+ | GUI LIB | +---+ <- what is this interface | GRAPICS LIB | +---+---+---+ <- what is this interface |SDL|GDI|OPENGL.| +---+---+---+ But is there any standard interfaces?
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist
wrote:
So I have seen alot of projects that need the same sort of
stuff.
graphics libraries
gui libraries
game libraries
ploting libaries
they would all benefit from a backend solution with a common
interface for
color
fonts
drawing pen_style aliasing etc.
but each one i look at seems to have a built up solution with
various degrees of integration with things like freetype gdi
cairo sdl glew opengl.
Shouldn't there be like a common (interface/abstract class)
that these back-ends can fulfill? maybe I am unaware of how
these things are done. And perhaps there are performance
reasons that many of these are baked in.
perhaps it should be like:
standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.
//probably a grotesque simplification
interface font_do{
glyphstrokes getstrokes(string characterstoget);
}
interface draw_do{
drawpixel(double x,double y);
drawline(double x,double y);
drawglyph(glypstrokes g);
getpostdrawnsize(glypstroks g)
... other things
}
It was an initiative, but it looks abandoned now (Aurora
Graphics):
Thread:
http://forum.dlang.org/thread/op.w9w0efr1707...@invictus.hra.local
Source Code: https://github.com/auroragraphics/
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 11:00:19 UTC, Jakob Ovrum wrote: On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote: Now I'm left with a smattering of lines which are just selective imports from a single module: import std.exception:enforce; import std.algorithm:array; import std.algorithm.iteration:filter; import std.functional:memoize; What is the proper way to combine these into one line? There's no `array` in std.algorithm, and I don't see more than one import per module in your example, but I'm guessing what you want is: import mod : a, b, c; // import a, b and c from mod Sorry, no, I didn't want that. I should have typed above: "I'm left with lines which are selective imports from various modules." My goal is to import several symbols from different modules on one line. I'm trying to figure out if it's possible or not. It makes the code more concise in some cases.
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 11:12:22 UTC, ZombineDev wrote: Actually array() is from sts.array and correct way to use selective imports is: import std.exception : enforce; import std.array : array; import std.algorithm.iteration : filter; import std.functional : memoize; If you want to import several symbols from one module, you can list them after the column like so: import std.algorithm : any, find, sort /*, etc... */; I hadn't compiled yet, so the array thing is indeed an error. So there's no way to combine these _selective_ imports on a single line, like I can with regular _module_ imports: import std.exception, std.array, std.functional; Correct?
Graphics/font/platform backends with common interfaces?
So I have seen alot of projects that need the same sort of stuff.
graphics libraries
gui libraries
game libraries
ploting libaries
they would all benefit from a backend solution with a common
interface for
color
fonts
drawing pen_style aliasing etc.
but each one i look at seems to have a built up solution with
various degrees of integration with things like freetype gdi
cairo sdl glew opengl.
Shouldn't there be like a common (interface/abstract class) that
these back-ends can fulfill? maybe I am unaware of how these
things are done. And perhaps there are performance reasons that
many of these are baked in.
perhaps it should be like:
standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.
//probably a grotesque simplification
interface font_do{
glyphstrokes getstrokes(string characterstoget);
}
interface draw_do{
drawpixel(double x,double y);
drawline(double x,double y);
drawglyph(glypstrokes g);
getpostdrawnsize(glypstroks g)
... other things
}
Re: Convert to string an enum item
On Wednesday, 23 December 2015 at 17:43:52 UTC, Alex Parrill
wrote:
On Wednesday, 23 December 2015 at 13:11:28 UTC, tcak wrote:
[code]
import std.stdio;
import std.conv;
enum Values: ubyte{ One = 1, Two = 2 }
void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]
Output is "One".
casting works, but to be able to cast correctly, I need to
tell compiler that it is "ubyte".
Isn't there any NON-HACKISH solution to print out the value of
enum item? And do not decrease the performance as well please.
It runs on web server.
So you want the enum's integer value? Try casting it to an
integer.
writeln(cast(ubyte) Values.One);
He already mentioned that.
What you want to do is use std.traits.OriginalType
(https://dlang.org/phobos/std_traits.html#OriginalType) like so:
to!string(cast(OriginalType!Values)Values.one)
Re: Convert to string an enum item
On Wednesday, 23 December 2015 at 17:43:52 UTC, Alex Parrill
wrote:
On Wednesday, 23 December 2015 at 13:11:28 UTC, tcak wrote:
[code]
import std.stdio;
import std.conv;
enum Values: ubyte{ One = 1, Two = 2 }
void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]
Output is "One".
casting works, but to be able to cast correctly, I need to
tell compiler that it is "ubyte".
Isn't there any NON-HACKISH solution to print out the value of
enum item? And do not decrease the performance as well please.
It runs on web server.
So you want the enum's integer value? Try casting it to an
integer.
writeln(cast(ubyte) Values.One);
He already mentioned that.
What you want to do is use std.traits.
Re: Convert to string an enum item
On Wednesday, 23 December 2015 at 13:11:28 UTC, tcak wrote:
[code]
import std.stdio;
import std.conv;
enum Values: ubyte{ One = 1, Two = 2 }
void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]
Output is "One".
casting works, but to be able to cast correctly, I need to tell
compiler that it is "ubyte".
Isn't there any NON-HACKISH solution to print out the value of
enum item? And do not decrease the performance as well please.
It runs on web server.
So you want the enum's integer value? Try casting it to an
integer.
writeln(cast(ubyte) Values.One);
Re: How is D doing?
I'm doing quite well, thank you.
Merry Christmas
Twas the Night before Christmas and all through my D code. The compiler was compiling the new and the olde. Thanks to Walter, Alexander and Ali. I try to write more D code with happiness and Glee. In the forums with help from folks like me galore. I find I am not crazy, just need to learn more. So with all my D code, bugs and all. As long as I can compile and stay awake and from my chair not fall. May all your code work be fast and work as fast as light. I wish to All a Merry Christmas and to All a good night.
Convert to string an enum item
[code]
import std.stdio;
import std.conv;
enum Values: ubyte{ One = 1, Two = 2 }
void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]
Output is "One".
casting works, but to be able to cast correctly, I need to tell
compiler that it is "ubyte".
Isn't there any NON-HACKISH solution to print out the value of
enum item? And do not decrease the performance as well please. It
runs on web server.
Problem comes from that:
I have written a struct for JsonArray. It has multiple append
methods. One of them is "appendNumber".
public ref JsonArray appendNumber(N)( N num )
if( __traits( compiles, {auto x=num.min + num.max;} ) ||
__traits( compiles, {auto x=num.min_normal;} ) )
{
appendJSString( std.conv.to!string( num ) );
return this;
}
While I am passing an enum item to this function, as it has "min"
and "max" attributes, it is accepted. But the resulting string is
the name of enum item instead of its value. I do not want casting
while enum knows its type already.
Re: Most performant way of converting int to string
On Wednesday, 23 December 2015 at 11:21:32 UTC, Jakob Ovrum wrote: Dynamic memory allocation is expensive. If the string is short-lived, allocate it on the stack: See also std.conv.toChars[1] for stringifying lazily/on-demand. http://dlang.org/phobos/std_conv#toChars
Re: Most performant way of converting int to string
On Tuesday, 22 December 2015 at 17:23:11 UTC, Andrew Chapman
wrote:
On Tuesday, 22 December 2015 at 17:18:16 UTC, cym13 wrote:
On Tuesday, 22 December 2015 at 17:15:27 UTC, Andrew Chapman
wrote:
Sorry if this is a silly question but is the to! method from
the conv library the most efficient way of converting an
integer value to a string?
e.g.
string s = to!string(100);
I'm seeing a pretty dramatic slow down in my code when I use
a conversion like this (when looped over 10 million
iterations for benchmarking).
Cheers!
Out of curiosity a slow down compared to what? No conversion
at all?
Yeah, if I include a simple conversion in my loop:
for({int i; i = 0;} i < num; i++) {
//string s = to!string(i);
Customer c = Customer(i, "Customer",
"", i * 2);
string result = objS.serialize(c);
}
If I uncomment the "string s" line I'm seeing a 20% increase in
running time, which given what's going on the rest of the code
is quite surprising. I've tried compiling with both dmd and
ldc2 - it's the same under both.
Cheers.
Dynamic memory allocation is expensive. If the string is
short-lived, allocate it on the stack:
enum maxDigits = to!string(ulong.max).length;
foreach(i; 0 .. num) {
char[maxDigits] buffer = void;
auto c = Customer(sformat(buffer[], "%s", i));
string result = objS.serialize(c);
}
Note that this is unsafe if the string (sformat's return value)
outlives the loop iteration, as this is `buffer`'s scope.
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote:
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt,
and Dscanner.
Upon saving files, it produces suggestions, much like warnings
from the compiler.
One suggestion is to use selective imports in local scopes. OK,
I'll do that.
Now I'm left with a smattering of lines which are just
selective imports from a single module:
void foo()
{
import std.exception:enforce;
import std.algorithm:array;
import std.algorithm.iteration:filter;
import std.functional:memoize;
//..Work..
}
What is the proper way to combine these into one line?
Actually array() is from sts.array and correct way to use
selective imports is:
import std.exception : enforce;
import std.array : array;
import std.algorithm.iteration : filter;
import std.functional : memoize;
If you want to import several symbols from one module, you can
list them after the column like so:
import std.algorithm : any, find, sort /*, etc... */;
Re: Multiple selective imports on one line
On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote:
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt,
and Dscanner.
Upon saving files, it produces suggestions, much like warnings
from the compiler.
One suggestion is to use selective imports in local scopes. OK,
I'll do that.
Now I'm left with a smattering of lines which are just
selective imports from a single module:
void foo()
{
import std.exception:enforce;
import std.algorithm:array;
import std.algorithm.iteration:filter;
import std.functional:memoize;
//..Work..
}
What is the proper way to combine these into one line?
There's no `array` in std.algorithm, and I don't see more than
one import per module in your example, but I'm guessing what you
want is:
import mod : a, b, c; // import a, b and c from mod
Multiple selective imports on one line
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt,
and Dscanner.
Upon saving files, it produces suggestions, much like warnings
from the compiler.
One suggestion is to use selective imports in local scopes. OK,
I'll do that.
Now I'm left with a smattering of lines which are just selective
imports from a single module:
void foo()
{
import std.exception:enforce;
import std.algorithm:array;
import std.algorithm.iteration:filter;
import std.functional:memoize;
//..Work..
}
What is the proper way to combine these into one line?
Re: How is D doing?
On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote: Google Trends shows something interesting: https://google.com/trends/explore#q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q%2C%20C%2B%2B&cmpt=q&tz=Etc%2FGMT-2 Today I Learned C++ is most interested by in Ethiopia. ;)
