Re: 2 bool optional params
On Tuesday 09 November 2010 23:55:26 spir wrote:
> Hello,
>
> Is there a way for a func to hold 2 optional params of the same type?
> void f(int p, bool b1=false, bool b2=false) {
> writefln("p=%s b1=%s b2=%s", p,b1,b2);
>}
> Or is there a workaroud?
Try compiling it. It works just fine.
You should be able to have multiple optional parameters, and their types
shouldn't matter. Where you get into trouble is if that function has overloads
which conflict. Since, in effect, by declaring
void f(int p, bool b1 = false, bool b2 = false)
you've declared
void f(int p, bool b1, bool b2)
void f(int p, bool b1)
void f(int p)
So, trying to declare any of those three separately won't work because your
first
definition covers them all.
- Jonathan M Davis
Re: std.json
To answer my own question 'value.object["mode"].str' gets me there.
bob
On 09/11/2010 21:12, Bob Cowdery wrote:
> Hi
>
> I'm trying to decode some json using std.json. I have figured out how to
> get at primitives out but can't get to a dictionary object.
>
> If I send something like {"mode":"am"} from my javascript and then say:
> value = parseJSON(message);
> I get a JSONValue struct. I can't find any documentation for this. Can
> anyone help?
>
> bob
Re: 2 bool optional params
On Wed, 10 Nov 2010 08:55:26 +0100, spir wrote:
> Hello,
>
> Is there a way for a func to hold 2 optional params of the same type?
> void f(int p, bool b1=false, bool b2=false) {
> writefln("p=%s b1=%s b2=%s", p,b1,b2);
>}
> Or is there a workaroud?
I'm not sure I understand what you're asking for here. Your example
works for me.
-Lars
segfault
Hello D programmers,
I'm blocked by a mysterious segfault I seem to be unable to diagnose. There is
probably some point of D I have not yet understood. Below relevant piece of
code; "***" marks debug instructions.
The constructor works fine, assertions pass, and writeln writes:
([0-9]+ ("+" [0-9]+)*)
But when I call the method 'check', writeln writes
(null null)
Which means that this.pattern's sub-patterns have disappeared. See line
constructing this.pattern in constructor to have an idea (I even tried to
replace sep & element by this.sep & this.element, but this does not help).
When matching with this.pattern later in check(), I get a segfault because the
code tries to recursively match its sub-patterns (the null items).
Denis
class List : Pattern {
// ...
Pattern element;
Pattern sep;
Tuple pattern;
uint min;
this (Pattern element, Pattern sep, uint min=2) {
this.min = min;
// for output
this.element = element;
this.sep = sep;
// construct pattern
this.pattern = new Tuple(
element,
new ZeroOrMore(new Tuple(sep,element))
);
assert ((this.element !is null) && (this.sep !is null));// ***
assert (this.pattern !is null); // ***
writeln(this.pattern); // ***
}
override Result check (Source source) {
assert (this.pattern !is null); // ***
writeln(this.pattern); // ***
// ...
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: ponce
On Tue, 09 Nov 2010 15:42:06 -0500, bearophile wrote: Don: Yes. The rules will be: * no globals (same as pure). * no unsafe features (eg, no asm). * source code must be available. Everything else should work. If a class is instantiated at compile-time the memory of its instance goes in the static mutable memory, but then the GC has to manage it differently, because you can't deallocate that memory. Is this a problem? It looks a little like the problems with scoped classes (that are now deprecated by Andrei). The problem with scoped classes are that they are reference types allocated on the stack. This is highly prone to memory problems, especially when classes are usually expected to be in the heap (less care about storing into a global). I'm assuming compile-time classes will be reference types allocated in the data segment. This is more similar to string literals than scope classes. I'm guessing that the resulting class must be immutable, no? Otherwise, how do you allow mutable functions on a class allocated in ROM? FWIW, I like scope classes for optimization (I use them a few places in dcollections), but emplace should be sufficient to replace it. -Steve
Re: 2 bool optional params
On Wed, 10 Nov 2010 08:54:20 + (UTC)
"Lars T. Kyllingstad" wrote:
> On Wed, 10 Nov 2010 08:55:26 +0100, spir wrote:
>
> > Hello,
> >
> > Is there a way for a func to hold 2 optional params of the same type?
> > void f(int p, bool b1=false, bool b2=false) {
> > writefln("p=%s b1=%s b2=%s", p,b1,b2);
> > }
> > Or is there a workaroud?
>
> I'm not sure I understand what you're asking for here. Your example
> works for me.
See answer to Jonathan; I should have insisted on "optional".
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: 2 bool optional params
On Wed, 10 Nov 2010 00:30:55 -0800
Jonathan M Davis wrote:
> On Tuesday 09 November 2010 23:55:26 spir wrote:
> > Hello,
> >
> > Is there a way for a func to hold 2 optional params of the same type?
> > void f(int p, bool b1=false, bool b2=false) {
> > writefln("p=%s b1=%s b2=%s", p,b1,b2);
> > }
> > Or is there a workaroud?
>
> Try compiling it. It works just fine.
>
> You should be able to have multiple optional parameters, and their types
> shouldn't matter. Where you get into trouble is if that function has
> overloads
> which conflict. Since, in effect, by declaring
>
> void f(int p, bool b1 = false, bool b2 = false)
>
> you've declared
>
> void f(int p, bool b1, bool b2)
> void f(int p, bool b1)
> void f(int p)
Precisely, what a clear exposure of the issue! Sorry, my question was far to
imprecise. I cannot have
void f(int p, bool b2) {}
If I call it with a single bool param, then D logically maps it to b1. In a
language with named params, one would simply write
f(whatever, b2=true);
Is there any workaround?
I thought at replacing b2 by a variable external to the func itself. Eg instead
void test (args, failure=false, silent=false) {}
have
SILENT_TEST = false;
void test (args, failure=false) {... also use SILENT_TEST ...}
But I find the solution a bit weird, it breaks lexical scoping, and forces the
user to overwrite a variable in the func's original scope (module).
(Is this at all possible:
import foo;
foo.K = true;
I'll try...)
> So, trying to declare any of those three separately won't work because your
> first
> definition covers them all.
Right, thank you, Jonathan.
> - Jonathan M Davis
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: ponce
On Tue, 09 Nov 2010 17:14:33 -0500, Don wrote:
bearophile wrote:
Jonathan M Davis:
it would be possible to make it so that any objects allocated with new
during CTFE would be in the dynamic heap during runtime.
This is possible, but it doesn't seem what you usually desire when you
allocate an object at compile time.
Bye,
bearophile
If it's mutable, it'll go on the heap. If it's immutable, it could
optionally go into read-only memory (it will be exactly like the .init
of a class instance). Classes which are used only during execution of
CTFE functions will not be instantiated at runtime.
Pardon my ignorance, but how can something evaluated at compile time go on
the heap? The heap doesn't exist yet!
e.g.:
class C
{
int[] buffer;
this() pure { buffer = new int[125];}
}
C c = new C;
How does c go on the heap at compile time? Won't you have to re-run the
constructor at runtime to get the right result? Not only that, but even
if you did run the ctor at compile time, how do you make a copy of c for
every thread without re-running the ctor?
-Steve
Memory allocation faile on string concat
Can't run a simple program. What's wrong, GC?
import std.stdio;
import std.date;
void f0()
{
wstring a[];
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(1);
writeln(r, "ms");
}
DMD 2.047
Re: 2 bool optional params
On Wed, 10 Nov 2010 09:16:05 -0500, spir wrote:
On Wed, 10 Nov 2010 00:30:55 -0800
Jonathan M Davis wrote:
On Tuesday 09 November 2010 23:55:26 spir wrote:
> Hello,
>
> Is there a way for a func to hold 2 optional params of the same type?
>void f(int p, bool b1=false, bool b2=false) {
>writefln("p=%s b1=%s b2=%s", p,b1,b2);
> }
> Or is there a workaroud?
What about using a bitfield?
enum : ubyte
{
b1 = 1;
b2 = 2;
}
void f(int p, ubyte flags = 0)
{
bool _b1 = flags & b1;
bool _b2 = flags & b2;
...
}
f(x, b1);
f(x, b2);
f(x, b1|b2);
-Steve
Re: 2 bool optional params
On Wed, 10 Nov 2010 11:03:27 -0500
"Steven Schveighoffer" wrote:
> On Wed, 10 Nov 2010 09:16:05 -0500, spir wrote:
>
> > On Wed, 10 Nov 2010 00:30:55 -0800
> > Jonathan M Davis wrote:
> >
> >> On Tuesday 09 November 2010 23:55:26 spir wrote:
> >> > Hello,
> >> >
> >> > Is there a way for a func to hold 2 optional params of the same type?
> >> > void f(int p, bool b1=false, bool b2=false) {
> >> > writefln("p=%s b1=%s b2=%s", p,b1,b2);
> >> > }
> >> > Or is there a workaroud?
>
> What about using a bitfield?
>
> enum : ubyte
> {
> b1 = 1;
> b2 = 2;
> }
>
> void f(int p, ubyte flags = 0)
> {
> bool _b1 = flags & b1;
> bool _b2 = flags & b2;
> ...
> }
>
> f(x, b1);
> f(x, b2);
> f(x, b1|b2);
>
> -Steve
Oh, yes, thank you! That's a very good idea.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Converting Fuse headers
On 10/11/2010 06:21, Jesse Phillips wrote:
I have some good news! It works (Simplest test case). I spent several hours
trying to track down where my code translation could be causing problems. And
have concluded that core.sys.posix.sys.stat.stat_t is not correct for my 32bit
Debian Linux machine.
I realize this is a big claim, so I'm going to look into it some more. But to
get my code working I moved the getattr function into a C file and called that
instead of using it from D. I also noticed that the value set to stat_t.st_mode
would not be returned when requesting it back.
Thank you Simen and div0.
1. https://github.com/he-the-great/Fused
Well done, glad you proved me wrong.
It does seem unlikely that size_t is wrong,
though you can test it easily enough:
compile a test C program to see what size it is and compare it to the D
version:
void main() {
printf("sizeof: %d", sizeof(size_t));
}
It should be 4 on a 32 bit system & 8 for 64 bit.
--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Re: ponce
On Wednesday, November 10, 2010 07:55:42 Steven Schveighoffer wrote:
> On Tue, 09 Nov 2010 17:14:33 -0500, Don wrote:
> > bearophile wrote:
> >> Jonathan M Davis:
> >>> it would be possible to make it so that any objects allocated with new
> >>> during CTFE would be in the dynamic heap during runtime.
> >>>
> >> This is possible, but it doesn't seem what you usually desire when you
> >>
> >> allocate an object at compile time.
> >>
> >> Bye,
> >>
> >> bearophile
> >
> > If it's mutable, it'll go on the heap. If it's immutable, it could
> > optionally go into read-only memory (it will be exactly like the .init
> > of a class instance). Classes which are used only during execution of
> > CTFE functions will not be instantiated at runtime.
>
> Pardon my ignorance, but how can something evaluated at compile time go on
> the heap? The heap doesn't exist yet!
>
> e.g.:
>
> class C
> {
>int[] buffer;
>this() pure { buffer = new int[125];}
> }
>
> C c = new C;
>
> How does c go on the heap at compile time? Won't you have to re-run the
> constructor at runtime to get the right result? Not only that, but even
> if you did run the ctor at compile time, how do you make a copy of c for
> every thread without re-running the ctor?
You likely end up essentially serializing it. You then deserialized it and
bring
it into the heap when the program loads. It's not a particularly pretty
problem,
but it should be quite doable. You certainly wouldn't rerun the constructor or
whatnot. What you need is to just transfer its saved state onto the heap,
translating any pointers and references that it has to whatever they should be
in the current heap.
- Jonathan M Davis
Re: 2 bool optional params
On Wednesday, November 10, 2010 06:16:05 spir wrote:
> On Wed, 10 Nov 2010 00:30:55 -0800
>
> Jonathan M Davis wrote:
> > On Tuesday 09 November 2010 23:55:26 spir wrote:
> > > Hello,
> > >
> > > Is there a way for a func to hold 2 optional params of the same type?
> > >
> > > void f(int p, bool b1=false, bool b2=false) {
> > >
> > > writefln("p=%s b1=%s b2=%s", p,b1,b2);
> > >
> > >}
> > >
> > > Or is there a workaroud?
> >
> > Try compiling it. It works just fine.
> >
> > You should be able to have multiple optional parameters, and their types
> > shouldn't matter. Where you get into trouble is if that function has
> > overloads which conflict. Since, in effect, by declaring
> >
> > void f(int p, bool b1 = false, bool b2 = false)
> >
> > you've declared
> >
> > void f(int p, bool b1, bool b2)
> > void f(int p, bool b1)
> > void f(int p)
>
> Precisely, what a clear exposure of the issue! Sorry, my question was far
> to imprecise. I cannot have void f(int p, bool b2) {}
> If I call it with a single bool param, then D logically maps it to b1. In a
> language with named params, one would simply write f(whatever, b2=true);
>
> Is there any workaround?
I'm sure that you could find various ways to get around specific examples (such
as
using Steve's proposal of a bitfield for bools), but generally, that's just not
how things work. D doesn't have named parameters. The type and order of
parameters are what determines which function overload to use.
The best general case solution that I can think of is to use a struct that
holds
the parameters that you want to pass in. Have its fields default to whatever
you
want as the default and only set the fields that you want to set.
In the case of bools, you could use a bitfield as Steve suggests, or you could
use named enums instead with yes and no (like Phobos does in several places)
and
then declare multiple versions of the functions where one takes both enums and
one takes only the second one that the first takes. So, if your two bools
indicated that you should go south and you should go fast, you'd do something
like
enum GoSouth {no, yes};
enum GoFast {no, yes};
func(int p, GoSouth gs = GoSouth.no, GoFast gf = GoFast.no) { ... }
func(int p, GoFast gf) { ... } // likely assumes GoSouth.no
That doesn't really scale very well though. Using named enums instead of bools
in some cases though can make code clearer.
In any case, the struct solution is the best that I can suggest for the general
case, but really, D doesn't have named parameters. Things just don't work that
way. So, trying to make things work that way is going to require bending over
backwards on some level.
- Jonathan M Davis
Re: Memory allocation faile on string concat
On Wednesday, November 10, 2010 08:33:45 Xie wrote:
> Can't run a simple program. What's wrong, GC?
>
> import std.stdio;
> import std.date;
>
> void f0()
> {
> wstring a[];
>
> foreach(i; 0 .. 100_000_000)
> {
> a ~= " "w;
> }
> }
>
> void main()
> {
> auto r = benchmark!(f0)(1);
> writeln(r, "ms");
> }
>
> DMD 2.047
You just tried to create an array with 100_000_000 elements, and arrays try and
maintain extra capacity for extra appending, so you're actually trying to
create
one bigger than that. That's a _lot_ of memory, and it's _contiguous_ memory.
You probably hit some sort of memory limit in there somewhere and would have
the
same problem if you tried to create an array that large in C or C++. That's an
_enormous_ array. Maybe it's a 32-bit barrier which will go away once 64-bit
dmd
is complete, but it's not exactly normal to try and use an array wich 100
million elements in it. The computer does have limits you know.
- Jonathan M Davis
Re: Memory allocation faile on string concat
On Wed, 10 Nov 2010 11:33:45 -0500, Xie wrote:
Can't run a simple program. What's wrong, GC?
import std.stdio;
import std.date;
void f0()
{
wstring a[];
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(1);
writeln(r, "ms");
}
The results on my machine with 1G of memory is that it consumes 2G of
memory and the system starts thrashing. I changed the value to
10_000_000, and it runs in a couple seconds, I change it to 50_000_000 and
it runs in 200 seconds.
Something is definitely amiss here, because the following doesn't help (it
still consumes 1.2GB of memory):
void f0()
{
wstring a[];
a.reserve(100_000_000);
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
This should take the explosive nature of appending out of the equation,
because a reallocation should never occur.
I'll look into it.
-Steve
Re: ponce
On Wed, 10 Nov 2010 13:08:10 -0500, Jonathan M Davis
wrote:
On Wednesday, November 10, 2010 07:55:42 Steven Schveighoffer wrote:
Pardon my ignorance, but how can something evaluated at compile time go
on
the heap? The heap doesn't exist yet!
e.g.:
class C
{
int[] buffer;
this() pure { buffer = new int[125];}
}
C c = new C;
How does c go on the heap at compile time? Won't you have to re-run the
constructor at runtime to get the right result? Not only that, but even
if you did run the ctor at compile time, how do you make a copy of c for
every thread without re-running the ctor?
You likely end up essentially serializing it. You then deserialized it
and bring
it into the heap when the program loads. It's not a particularly pretty
problem,
but it should be quite doable. You certainly wouldn't rerun the
constructor or
whatnot. What you need is to just transfer its saved state onto the heap,
translating any pointers and references that it has to whatever they
should be
in the current heap.
Wow, this seems like a lot of extra effort for zero gain. Is this really
the direction we are going? Why can't we just say anything decided at
compile time must be immutable or implicitly converted to immutable, and
anything else you have to do in a static constructor?
-Steve
Re: Memory allocation faile on string concat
On Wed, 10 Nov 2010 13:33:11 -0500, Steven Schveighoffer
wrote:
On Wed, 10 Nov 2010 11:33:45 -0500, Xie wrote:
Can't run a simple program. What's wrong, GC?
import std.stdio;
import std.date;
void f0()
{
wstring a[];
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(1);
writeln(r, "ms");
}
The results on my machine with 1G of memory is that it consumes 2G of
memory and the system starts thrashing. I changed the value to
10_000_000, and it runs in a couple seconds, I change it to 50_000_000
and it runs in 200 seconds.
Something is definitely amiss here, because the following doesn't help
(it still consumes 1.2GB of memory):
void f0()
{
wstring a[];
a.reserve(100_000_000);
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
This should take the explosive nature of appending out of the equation,
because a reallocation should never occur.
I'll look into it.
Wit a second, a is not a wstring, it's an *array* of wstrings. That's
completely different.
This all makes sense now. It's not 200MB, it's 800MB your code is asking
for. This might be a bit much for a test, a 32-bit system only supports
4GB of address space, and usually 1GB is reserved, so you are trying to
allocate about 1/3 of the memory you could possibly allocate.
Is there any reason you expect this to perform well?
-Steve
Re: Memory allocation faile on string concat
On 11/10/2010 11:33 AM, Xie wrote:
Can't run a simple program. What's wrong, GC?
import std.stdio;
import std.date;
void f0()
{
wstring a[];
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(1);
writeln(r, "ms");
}
DMD 2.047
In addition to what everybody else is suggesting you look at, you may
want to look into using an appender (defined in std.array). Not sure if
it will help with the memory usage, but it's supposed to be faster for
appending data to an array.
Casey
Re: Memory allocation faile on string concat
On Wed, 10 Nov 2010 13:55:26 -0500, sybrandy wrote:
On 11/10/2010 11:33 AM, Xie wrote:
Can't run a simple program. What's wrong, GC?
import std.stdio;
import std.date;
void f0()
{
wstring a[];
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(1);
writeln(r, "ms");
}
DMD 2.047
In addition to what everybody else is suggesting you look at, you may
want to look into using an appender (defined in std.array). Not sure if
it will help with the memory usage, but it's supposed to be faster for
appending data to an array.
Just tried it, Appender is actually slower. This *is* a problem, it
should be way faster than builtin array appending.
I will look into it.
-Steve
Re: Memory allocation faile on string concat
On Wed, 10 Nov 2010 14:06:40 -0500, Steven Schveighoffer wrote: Just tried it, Appender is actually slower. This *is* a problem, it should be way faster than builtin array appending. I will look into it. More data, Appender taking an array of elements is significantly slower than taking a single element (by an order of magnitude). I'll try to figure out why. BTW, if you append individual wchars instead of a string of a single wchar, Appender does beat the pants off of builtin appends. -Steve
Re: Memory allocation faile on string concat
Sorry, it a mistypo (i began from wchar[], later changed to wstring)
Real problem can be seen here
import std.stdio;
import std.date;
void f0()
{
wstring a;
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(10);
writeln(r, "ms");
}
Re: Memory allocation faile on string concat
On Wed, 10 Nov 2010 14:38:02 -0500, Xie wrote:
Sorry, it a mistypo (i began from wchar[], later changed to wstring)
Real problem can be seen here
import std.stdio;
import std.date;
void f0()
{
wstring a;
foreach(i; 0 .. 100_000_000)
{
a ~= " "w;
}
}
void main()
{
auto r = benchmark!(f0)(10);
writeln(r, "ms");
}
OK, this actually makes sense to me.
It's a manifestation of this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=3929
In essence, in order to aid performance, there is an 8-element cache of
arrays that are being appended. At the moment, the append code relies on
this cache keeping the array from being collected to remain sane.
However, as I wrote in the last message on that bug report, I think I can
fix it so the cache is not considered a pointer to the memory, and it
should be collected. But I haven't done that yet.
So what's happening in your code is the first 8 times executing that
function, the memory is not collected. This results in you allocating
actually 800 million wchars, or 1.6GB before anything can be collected.
So in the meantime, jump on the CC for that bug, and I hope to get to it
sometime in the near future (maybe by 2.051-2.052).
-Steve
Re: Converting Fuse headers
div0 Wrote:
> Well done, glad you proved me wrong.
>
> It does seem unlikely that size_t is wrong,
> though you can test it easily enough:
>
> compile a test C program to see what size it is and compare it to the D
> version:
>
> void main() {
> printf("sizeof: %d", sizeof(size_t));
> }
>
> It should be 4 on a 32 bit system & 8 for 64 bit.
Hope I didn't say size_t. stat_t, a very complicated struct known as struct
stat in C. I don't know for sure that it is wrong, but at this point it is the
most likely candidate.
Also none of the changes I made related to the question affected the ability of
the program to work (maybe a more complicated one). Just glad I wasn't to far
off in my translation.
Re: 2 bool optional params
Jonathan M Davis: > In any case, the struct solution is the best that I can suggest for the > general > case, but really, D doesn't have named parameters. Things just don't work > that > way. Named arguments is among my top four enhancement requests :-) They help. Hopefully in D3. Bye, bearophile
Re: 2 bool optional params
On Wednesday 10 November 2010 12:24:01 bearophile wrote: > Jonathan M Davis: > > In any case, the struct solution is the best that I can suggest for the > > general case, but really, D doesn't have named parameters. Things just > > don't work that way. > > Named arguments is among my top four enhancement requests :-) They help. > Hopefully in D3. I expect that that's one of those things that those who have never used them don't see the point and those who have hate not having them. Personally, I've never used a language that had them, and I don't really care about them. I'd say that if you have parameter lists long enough to care, then your parameter lists are too long and you need to find ways to reduce them (like encapsulating related parameters into struct - using a point struct instead of separate x, y, and z values would be a great example of that). Maybe my opinion would be different if I had extensively used a language with named parameters, but I haven't yet. Now, that doesn't mean that D definitely shouldn't have them - it could be that I'd love them once I had them - but as someone who hasn't used them, they don't seem at all necessary. So, I really think that it primarily comes down to people not being used to them seeing no need and people being used to them wanting them. Whether they are actually worth having, I really can't say. - Jonathan M Davis
Re: Converting Fuse headers
On 10/11/2010 20:15, Jesse Phillips wrote:
div0 Wrote:
Well done, glad you proved me wrong.
It does seem unlikely that size_t is wrong,
though you can test it easily enough:
compile a test C program to see what size it is and compare it to the D
version:
void main() {
printf("sizeof: %d", sizeof(size_t));
}
It should be 4 on a 32 bit system& 8 for 64 bit.
Hope I didn't say size_t. stat_t, a very complicated struct known as struct
stat in C. I don't know for sure that it is wrong, but at this point it is the
most likely candidate.
Also none of the changes I made related to the question affected the ability of
the program to work (maybe a more complicated one). Just glad I wasn't to far
off in my translation.
Sorry, me misreading.
You can still do the size check for the stat_t struct as well,
I always double check the size of structs when doing those conversions
as it's very easy to get it wrong.
--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Re: Converting Fuse headers
div0 Wrote: > You can still do the size check for the stat_t struct as well, > I always double check the size of structs when doing those conversions > as it's very easy to get it wrong. Ah, good idea. The test I have planned will be to set some values in the D struct, and see what is read by the C struct. The size thing will definitely be a simple give away if it differs. I might try to use some reflection to see what the structure D creates looks like, so that it will be easier to compare the D code with the C header. (Lots of version statements in the D version, might be some macros in C too.)
Re: ponce
Steven Schveighoffer wrote:
On Tue, 09 Nov 2010 17:14:33 -0500, Don wrote:
bearophile wrote:
Jonathan M Davis:
it would be possible to make it so that any objects allocated with
new during CTFE would be in the dynamic heap during runtime.
This is possible, but it doesn't seem what you usually desire when
you allocate an object at compile time.
Bye,
bearophile
If it's mutable, it'll go on the heap. If it's immutable, it could
optionally go into read-only memory (it will be exactly like the .init
of a class instance). Classes which are used only during execution of
CTFE functions will not be instantiated at runtime.
Pardon my ignorance, but how can something evaluated at compile time go
on the heap? The heap doesn't exist yet!
e.g.:
class C
{
int[] buffer;
this() pure { buffer = new int[125];}
}
C c = new C;
How does c go on the heap at compile time? Won't you have to re-run the
constructor at runtime to get the right result? Not only that, but even
if you did run the ctor at compile time, how do you make a copy of c for
every thread without re-running the ctor?
-Steve
The situation isn't any different to what we already have. You can
already do:
struct F
{
int [] w;
}
F[] foo() {
F[] x = new F[6];
foreach(i; 0..x.length)
x[i].w = new int[20];
return x;
}
and foo() can be run at compile time.
OTOH, I don't know if there is any case where a CTFE value can actually
end up on the heap at runtime. CTFE only kicks in when you need a
manifest constant, and AFAIK there's no way to require a class manifest
constant -- just an element of one.
Re: Converting Fuse headers
On 10/11/2010 21:02, Jesse Phillips wrote: div0 Wrote: You can still do the size check for the stat_t struct as well, I always double check the size of structs when doing those conversions as it's very easy to get it wrong. Ah, good idea. The test I have planned will be to set some values in the D struct, and see what is read by the C struct. The size thing will definitely be a simple give away if it differs. I might try to use some reflection to see what the structure D creates looks like, so that it will be easier to compare the D code with the C header. (Lots of version statements in the D version, might be some macros in C too.) Also another thing to make life easier, use gcc's only preprocess the file option (-E ?) and save the result. That way you can look at the raw struct after all the CPP macros have been applied/stripped out. That's very handy with complicated C structs. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: 2 bool optional params -- named parameters
On Wed, 10 Nov 2010 12:39:15 -0800 Jonathan M Davis wrote: > On Wednesday 10 November 2010 12:24:01 bearophile wrote: > > Jonathan M Davis: > > > In any case, the struct solution is the best that I can suggest for the > > > general case, but really, D doesn't have named parameters. Things just > > > don't work that way. > > > > Named arguments is among my top four enhancement requests :-) They help. > > Hopefully in D3. +++ > I expect that that's one of those things that those who have never used them > don't see the point and those who have hate not having them. Personally, I've > never used a language that had them, and I don't really care about them. I'd > say > that if you have parameter lists long enough to care, then your parameter > lists > are too long and you need to find ways to reduce them (like encapsulating > related > parameters into struct - using a point struct instead of separate x, y, and z > values would be a great example of that). I fully agree with your struct example for (x,y,z). But this is an example where names, precisely, are not a real gain. The real point is not to reduce the size of a param list (they make it longer!). The real point, in my opinion, is also not avoiding the need to remember param order (and for x,y,z it's not an issue). Why I love named parameters is that they bring embedded documentation for free; provided names are sensibly chosen, indeed. They make code much easier to read, even for the author. We don't spend our valuable time & attention in "computing" information that should be available (what's that param?). Our brain can then better work on what's important, namely the app's logics. But maybe it's only me. > Maybe my opinion would be different if > I had extensively used a language with named parameters, but I haven't yet. I first discovered named parameters with python, and loved them before having used them even once. The idea is simply good for me. Either you care for what they bring, or not. It's not a question of beeing used to using them or not. Probably you give more importance to other aspects of code, and less to the one (say, clarity) greatly enhanced by this feature, than I do. I'm not sure this would change with, for instance, beeing forced to use a language with _only_ named parameters (my dream language *). > [...] Denis From an OO perpective, this is much easier to envision, snce the target, on which a method applies, is already told apart. Then, remaining data are really parameters in the plain sense of the term; and are usually very few. Naming them is thus less a trouble, and more helpful: names.sort(ALPHA, true); names.sort(order=ALPHA, reverse=true); -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: 2 bool optional params
Jonathan M Davis wrote: > Whether they are actually worth having, I really can't say. They are not worth it. Without optional parameters it is already dificult enough to remember for each name of a function the length of the formal parameter list and the sequence of types and meanings for each formal parameter. This are at least two dimensions. Optional parameters add a second such sequence or a third dimension _and_ a fourth dimension: the sequence of the default values. Named parameters add a fifth dimension and in addition this fifth dimension is to be exported if it should be usefull. Once exported and used it becomes unchangeable. On evaluating an actual parameter list, every opening paratheses also opens a further local name space, which vanishes only if the according closing paranthesis is reached. Human brains are currently not able to cope with complex hierarchies of more than ten chunks and probably they will never be able to do so. This restricts the usability of named parameters to such easy cases like the OP used: two or three named parameters and no function calls as actual parameters. -manfred
Re: struct constructors and function parameters
Simen kjaeraas wrote:
> Adam Burton wrote:
>
>> I looked into alias this and it does indeed work, unless the alias is to
>> a
>> function. That has been reported as a bug though
>> http://d.puremagic.com/issues/show_bug.cgi?id=2814
>
> Wouldn't that be the opposite of what you were discussing earlier?
> alias this lets a struct behave as an or whatever, not the other way
> around.
>
You've lost me. I think you are getting at the fact that alias this isn't
exactly the same as structs using constructors for implicit casts. I was
just acknowledging I have looked into it (I am using it for something else
but that bug gets in my way :-(). That being said if you make the alias this
a factory method for your implicit casts it could be used to do so. For
example
struct D
{
int i;
alias implicitCast this;
E implicitCast()
{
return E(i);
}
}
struct E
{
int i;
}
void main()
{
E e = E(1);
D d = D(2);
e = d;
writefln(to!string(e.i)); // 2
}
As stated by the bug this doesn't work for function parameters. With member
variables it is ok though.
Mentioning our earlier discussion I don't see why the implicit casts
couldn't be handled in the same manner as below.
interface A
{}
interface B
{}
class C : B, A
{}
void foo(A a){}
void foo(B b){}
void main()
{
foo(new C());
}
test2.d(15): Error: function test2.foo called with argument types:
((C))
matches both:
test2.foo(A a)
and:
test2.foo(B b)
Re: Memory allocation faile on string concat
>OK, this actually makes sense to me. >It's a manifestation of this issue: >http://d.puremagic.com/issues/show_bug.cgi?id=3929 I'm think - it's truth but not at all. Sorry, but i'm give incomplete data. My example run fine, when benchmark(1), (2), but not 10. This means, that memory not collected _between_ calls.
Re: segfault
What happens if you make pattern const?
