Re: C standard libraries
It is in core.stdc. For example: import core.stdc.stdio; // stdio.h import core.stdc.stdlib;// stdlib.h etc. Thanks! I'm confused why that module isn't mentioned in the library reference page. What's the difference between core.stdc and std.c? The docs do refer to core.stdc, though std.c.stdio in Phobos' source just imports core.stdc.stdio. The duplication seems a bit weird, and I'm wondering if one method is deprecated or migth be removed in the future.
Re: Handling different types gracefully
Roderick Gibson: Variant is a possiblity. How is the performance with large containers of these, since these structures will likely hold the majority of the data in the game? You probably have to benchmark yourself. (But I have suggested an Algebraic). Bye, bearophile
Re: Eponymous template with full template syntax
On Monday, 1 July 2013 at 22:46:55 UTC, Ali Çehreli wrote: On 07/01/2013 02:10 PM, monarch_dodra wrote: That is confusing. UFCS construction: Yes. I *think* I did not know it but I can't be sure. :) AH... I looked at the threads some more: I was actually thinking about a proposal that wanted (just like UFCS), to allow non-intrusively adding constructors. So I guess UFCS and constructors are fair game? I do not like this at all...
Re: Template constraints and opAdd
John:
Mass!(T,S) opAdd(Mass!(T,S) other) {
If you are using D2 then don't use opAdd, use opBinary:
http://dlang.org/operatoroverloading.html#Binary
Time ago I added an enhancement request for a warning (that later
is meant to become a deprecation) that helps avoid your problem:
http://d.puremagic.com/issues/show_bug.cgi?id=10320
Bye,
bearophile
Re: C standard libraries
On Monday, 1 July 2013 at 18:09:32 UTC, Jonathan M Davis wrote: On Monday, July 01, 2013 18:32:30 CJS wrote: Is there some header/module that includes declaration for all C standard libraries? I'm wondering both in general for future reference, and for the specific case of wanting to time a function and not knowing what in D--even after looking through the docs--would do something equivalent to clock and CLOCKS_PER_SEC in the C standard library time.h. If you want to time a function, checkout std.datetime.StopWatch: http://dlang.org/phobos/std_datetime.html#StopWatch +1 I really came to hate c's clock, StopWatch has been much more pleasant experience to work with.
Re: opDispatch and UFCS
On 07/02/13 02:45, cal wrote:
import std.conv, std.stdio, std.algorithm;
struct S {
void opDispatch(string s, T...)(T t) if (s.startsWith(foo)) {
writeln(s);
}
}
void main() {
S s;
s.foo();
auto p = s.to!string(); // Error: s.opDispatch!(to) isn't a template
}
Should the constraint on opDispatch allow the UFCS to call on S?
To avoid this kind of issues:
struct S {
template opDispatch(string s) if (s.startsWith(foo)) {
void opDispatch(T...)(T t) {
writeln(s);
}
}
}
And, yes, the compiler should be able to handle your simpler case too,
but currently doesn't (if there are several overloads then the
transformation isn't necessarily this easy). I usually end up doing
something like:
struct S {
static bool _disp(string s) {
if (s.startsWith(foo))
return true;
// ... other checks, AA lookups, introspection etc.
return false;
}
template opDispatch(string s) if (_disp(s)) {
void opDispatch(T...)(T t) {
writeln(s);
}
}
}
Dealing with the various frontend quirks can be fun.
artur
Re: C standard libraries
Use core.stdc, and forget of std.c. Bye, bearophile What's the reason for that?
Re: C standard libraries
Gary Willoughby: What's the reason for that? Moving the C stuff in core is probably a way to remember D programmers that stuff is not normal stuff you are supposed to use in D programs. A D programmer should use the normal safer and nicer D functions. Core is there for special cases. Bye, bearophile
Re: C standard libraries
On Tuesday, 2 July 2013 at 06:33:03 UTC, CJS wrote: Thanks! I'm confused why that module isn't mentioned in the library reference page. I don't know. What's the difference between core.stdc and std.c? std.c is what it was called in earlier versions of D, before there was a clear separation between phobos as the standard library (std.*) and druntime as the runtime library (core.*). Phobos is supposed to be 100% on top of druntime, so it is optional and interchangeable with ease. The runtime, however, needed access to some C functions for its own implementation. Since it isn't allowed to depend on std.*, the C functions got moved into core.*. The older std.c is kept around just for compatibility with the old names before the move, at least as far as I know. Maybe they haven't fully deprecated it though because there's other reasons I don't know about, since it has been many years now since the move.
Re: C standard libraries
Adam D. Ruppe: The older std.c is kept around just for compatibility with the old names before the move, at least as far as I know. Maybe they haven't fully deprecated it though because there's other reasons I don't know about, since it has been many years now since the move. In D/Phobos/Dmd there is a ton of stuff that's supposed to be obsolete, that should not be used, that is deprecated, etc. I presume Walter thinks that the problems caused from keeping it and from unwanted usages of it, is smaller than the breaking troubles caused by removing it. I am person that likes to keeps things ordered and clean, so I prefer to remove old stuff after a suitable deprecation period, instead of keeping it around almost forever (like floating point special comparison operators). Bye, bearophile
Re: Handling different types gracefully
On Tuesday, 2 July 2013 at 06:54:58 UTC, bearophile wrote: Roderick Gibson: Variant is a possiblity. How is the performance with large containers of these, since these structures will likely hold the majority of the data in the game? You probably have to benchmark yourself. (But I have suggested an Algebraic). Bye, bearophile I should know the types at compile time, so I will be using it most likely, but reading the docs it looks like Algebraic is built on top of the same structure as Variant. Is there any difference in implementation?
How to get warnings about unused imports ?
Hi, How to find unused imports ? It seems the compiler doesn't do it, but is there any other tool for that? This seems like small issue, but those unused imports pile up pretty quickly Regards, Gabi
Re: Handling different types gracefully
Roderick Gibson: I should know the types at compile time, so I will be using it most likely, but reading the docs it looks like Algebraic is built on top of the same structure as Variant. Is there any difference in implementation? Take a look at the Phobos source code, it's much faster than waiting for my answer. Algebraic is built on top of VariantN. Algebraic accepts only a limited number of types, while Variant doesn't have such limitation. So Algebraic is type safe. And maybe Algebraic can ideally be implemented more efficiently than a Variant because to denote the contained type an enum suffices, instead of a TypeInfo. Please take a look at VariantN if it contains the enum or a Typeinfo or something else. Bye, bearophile
Re: Handling different types gracefully
On Tuesday, 2 July 2013 at 21:45:57 UTC, bearophile wrote: Roderick Gibson: I should know the types at compile time, so I will be using it most likely, but reading the docs it looks like Algebraic is built on top of the same structure as Variant. Is there any difference in implementation? Take a look at the Phobos source code, it's much faster than waiting for my answer. Algebraic is built on top of VariantN. Algebraic accepts only a limited number of types, while Variant doesn't have such limitation. So Algebraic is type safe. And maybe Algebraic can ideally be implemented more efficiently than a Variant because to denote the contained type an enum suffices, instead of a TypeInfo. Please take a look at VariantN if it contains the enum or a Typeinfo or something else. Bye, bearophile Thanks, I'll do that. Thanks for the help, bearophile!
Re: opDispatch and UFCS
On Tuesday, 2 July 2013 at 11:04:20 UTC, Artur Skawina wrote:
To avoid this kind of issues:
struct S {
template opDispatch(string s) if (s.startsWith(foo)) {
void opDispatch(T...)(T t) {
writeln(s);
}
}
}
That's a handy workaround, thank you.
ref tuples
C++11's std::tuple includes a function std::tie that takes references to the arguments and returns a tuple that maintains the references to the arguments. Along with the usual cases where you'd want reference semantics it also enables this interesting construct for unpacking tuples. int a, b; tie(a, b) = make_tuple(1, 2); assert(a == 1 b == 2); Is there any way to do something similar with std.typecons.Tuple?
Re: opDispatch and UFCS
On Tuesday, 2 July 2013 at 00:45:23 UTC, cal wrote:
import std.conv, std.stdio, std.algorithm;
struct S {
void opDispatch(string s, T...)(T t) if
(s.startsWith(foo)) {
writeln(s);
}
}
void main() {
S s;
s.foo();
auto p = s.to!string(); // Error: s.opDispatch!(to) isn't
a template
}
Should the constraint on opDispatch allow the UFCS to call on
S?
That's a compiler bug.
http://d.puremagic.com/issues/show_bug.cgi?id=10526
Kenji Hara
Stop to! rounding?
writeln(to!double(151.42499));//prints 151.425 Is there any way to stop this rounding? Thanks, Josh
Re: Stop to! rounding?
On Wednesday, July 03, 2013 06:23:12 Josh wrote: writeln(to!double(151.42499));//prints 151.425 Is there any way to stop this rounding? No. double can't hold the value 151.42499. There are _tons_ of values that it can't hold exactly. The same goes for float and real. Floating point values are rounded all the time. Note that double d = 151.42499; writeln(d); prints exactly the same thing as your example. - Jonathan M Davis
Re: Stop to! rounding?
On Wednesday, 3 July 2013 at 04:32:15 UTC, Jonathan M Davis wrote: On Wednesday, July 03, 2013 06:23:12 Josh wrote: writeln(to!double(151.42499));//prints 151.425 Is there any way to stop this rounding? No. double can't hold the value 151.42499. There are _tons_ of values that it can't hold exactly. The same goes for float and real. Floating point values are rounded all the time. Note that double d = 151.42499; writeln(d); prints exactly the same thing as your example. - Jonathan M Davis Is there any way I would be able to hold that number then? Thanks, Josh
Re: Stop to! rounding?
On Wednesday, 3 July 2013 at 04:32:15 UTC, Jonathan M Davis wrote:
On Wednesday, July 03, 2013 06:23:12 Josh wrote:
writeln(to!double(151.42499));//prints 151.425
Is there any way to stop this rounding?
No. double can't hold the value 151.42499. There are _tons_ of
values that it
can't hold exactly. The same goes for float and real. Floating
point values are
rounded all the time. Note that
double d = 151.42499;
writeln(d);
prints exactly the same thing as your example.
- Jonathan M Davis
void main()
{
double d = 151.42499;
assert(d == 151.42499);
}
The rounding occurs in writeln surely.
Re: Stop to! rounding?
On Wednesday, July 03, 2013 07:04:47 cal wrote:
On Wednesday, 3 July 2013 at 04:32:15 UTC, Jonathan M Davis wrote:
On Wednesday, July 03, 2013 06:23:12 Josh wrote:
writeln(to!double(151.42499));//prints 151.425
Is there any way to stop this rounding?
No. double can't hold the value 151.42499. There are _tons_ of
values that it
can't hold exactly. The same goes for float and real. Floating
point values are
rounded all the time. Note that
double d = 151.42499;
writeln(d);
prints exactly the same thing as your example.
- Jonathan M Davis
void main()
{
double d = 151.42499;
assert(d == 151.42499);
}
The rounding occurs in writeln surely.
That's true because _both_ of the floating point values there get rounded to
151.425, and 151.425 is equal to 151.425. writeln is not doing anything wrong.
I highly suggest that you read this:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
- Jonathan M Davis
Re: Stop to! rounding?
On 07/02/2013 10:09 PM, Jonathan M Davis wrote:
On Wednesday, July 03, 2013 07:04:47 cal wrote:
void main()
{
double d = 151.42499;
assert(d == 151.42499);
}
The rounding occurs in writeln surely.
That's true because _both_ of the floating point values there get
rounded to
151.425,
The value that can be stored is not 151.42499, nor 151.425.
import std.stdio;
import std.conv;
void main()
{
auto a = to!double(151.42499);
writefln(%.60f, a);
}
Prints:
151.4249908194547262974083423614501953125000
writeln is not doing anything wrong.
True. It is using its default floating point precision, 6.
Ali
Re: Stop to! rounding?
On Wednesday, 3 July 2013 at 05:10:03 UTC, Jonathan M Davis wrote:
On Wednesday, July 03, 2013 07:04:47 cal wrote:
On Wednesday, 3 July 2013 at 04:32:15 UTC, Jonathan M Davis
wrote:
On Wednesday, July 03, 2013 06:23:12 Josh wrote:
writeln(to!double(151.42499));//prints 151.425
Is there any way to stop this rounding?
No. double can't hold the value 151.42499. There are _tons_
of
values that it
can't hold exactly. The same goes for float and real.
Floating
point values are
rounded all the time. Note that
double d = 151.42499;
writeln(d);
prints exactly the same thing as your example.
- Jonathan M Davis
void main()
{
double d = 151.42499;
assert(d == 151.42499);
}
The rounding occurs in writeln surely.
That's true because _both_ of the floating point values there
get rounded to
151.425, and 151.425 is equal to 151.425. writeln is not doing
anything wrong.
I highly suggest that you read this:
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
- Jonathan M Davis
import std.stdio;
void main()
{
double d = 151.42499;
writefln(%.10f, d);
}
Re: Stop to! rounding?
On Tue, Jul 02, 2013 at 10:14:33PM -0700, Ali Çehreli wrote:
[...]
import std.stdio;
import std.conv;
void main()
{
auto a = to!double(151.42499);
writefln(%.60f, a);
}
I wouldn't write it like that; IMO it's better to write:
writefln(%.*f, double.dig, a);
So that you don't give the wrong impression that there are more digits
than are actually there. Using double.dig also lets you see all the
digits that *are* there, not a rounded value, that the OP was
complaining about.
T
--
The easy way is the wrong way, and the hard way is the stupid way. Pick one.
