Re: "Best" way of passing in a big struct to a function?
On Wednesday, 10 October 2012 at 04:55:48 UTC, Val Markovic wrote:
Oh, and a related question: what is the best way to pass in an
associative array like CustomStruct[string]? I can't say I'm
too clear on how AA's are managed/implemented. Do they have
value semantics or reference semantics?
Good question, I'd like to get some clarification on it too.
Because it doesn't behave like, for example, class which surely
has reference semantics.
When I've got a class
class C {
int m;
}
and pass an object of this class to a function,
void mutate_C(C c)
{
c.m = 5;
}
it follows reference semantics and its contents gets changed.
However if I pass an assoc. array to a function which changes its
contents
void mutate_AA(string[int] aa)
{
foreach(i; 0..10)
aa[i*10] = "hi";
}
Then this code
string[int] aa;
mutate_AA(aa);
writeln(aa);
outputs "[]" - changes are not applied.
It's only after I change parameter to "ref string[int] aa" its
value get changed successfully.
Re: "Best" way of passing in a big struct to a function?
On Wednesday, October 10, 2012 08:59:54 thedeemon wrote:
> On Wednesday, 10 October 2012 at 04:55:48 UTC, Val Markovic wrote:
> > Oh, and a related question: what is the best way to pass in an
> > associative array like CustomStruct[string]? I can't say I'm
> > too clear on how AA's are managed/implemented. Do they have
> > value semantics or reference semantics?
>
> Good question, I'd like to get some clarification on it too.
> Because it doesn't behave like, for example, class which surely
> has reference semantics.
>
> When I've got a class
>
> class C {
>int m;
> }
>
> and pass an object of this class to a function,
>
> void mutate_C(C c)
> {
>c.m = 5;
> }
>
> it follows reference semantics and its contents gets changed.
>
> However if I pass an assoc. array to a function which changes its
> contents
>
> void mutate_AA(string[int] aa)
> {
>foreach(i; 0..10)
> aa[i*10] = "hi";
> }
>
> Then this code
>
>string[int] aa;
>mutate_AA(aa);
>writeln(aa);
>
> outputs "[]" - changes are not applied.
> It's only after I change parameter to "ref string[int] aa" its
> value get changed successfully.
The exact same thing would happen with a class. The problem is that the aa
that you pass in is null, so if you assign anything to it within the function
or otherwise mutate it, it doesn't affect the original. Making it ref fixes the
problem, because then anything which affects the AA variable inside of the
called function is operating on a reference to the original AA variable rather
than just operating on what the original AA variable pointed to. Making sure
that the aa has been properly initialized before passing it to a function
(which would mean giving it at least one value) would make the ref completely
unnecessary.
- Jonathan M Davis
Re: "Best" way of passing in a big struct to a function?
On Wednesday, 10 October 2012 at 07:28:55 UTC, Jonathan M Davis wrote: Making sure that the aa has been properly initialized before passing it to a function (which would mean giving it at least one value) would make the ref completely unnecessary. - Jonathan M Davis Ah, thanks a lot! This behavior of a fresh AA being null and then silently converted to a non-null when being filled confused me.
Re: Unexpected OPTLINK termination
On 2012-10-09 22:59, Andrei Alexandrescu wrote: I'd be bummed because that's quite a logical decision, and how other interpreters do it. GDB uses the --args approach. -- /Jacob Carlborg
Re: "Best" way of passing in a big struct to a function?
On 10/10/12 09:12, thedeemon wrote: On Wednesday, 10 October 2012 at 07:28:55 UTC, Jonathan M Davis wrote: Making sure that the aa has been properly initialized before passing it to a function (which would mean giving it at least one value) would make the ref completely unnecessary. - Jonathan M Davis Ah, thanks a lot! This behavior of a fresh AA being null and then silently converted to a non-null when being filled confused me. Yes, it's confusing and annoying. This is something in the language that we keep talking about fixing, but to date it hasn't happened.
Best way to store postgresql's "numeric" type in D?
It is up to 131072 digits before the decimal point; up to 16383 digits after the decimal point.
Re: "Best" way of passing in a big struct to a function?
On Wed, Oct 10, 2012 at 10:40:24AM +0200, Don Clugston wrote: > On 10/10/12 09:12, thedeemon wrote: > >On Wednesday, 10 October 2012 at 07:28:55 UTC, Jonathan M Davis wrote: > >>Making sure that the aa has been properly initialized before passing > >>it to a function (which would mean giving it at least one value) > >>would make the ref completely unnecessary. > >> > >>- Jonathan M Davis > > > >Ah, thanks a lot! This behavior of a fresh AA being null and then > >silently converted to a non-null when being filled confused me. > > Yes, it's confusing and annoying. This is something in the language > that we keep talking about fixing, but to date it hasn't happened. How would it be fixed, though? T -- Let X be the set not defined by this sentence...
Unable to understand this compiler error
Hi,
I discovered this while playing with DGUI's treeview module. Here is a
program that generates exactly the same error that looks weird to me:
module a;
import std.stdio;
alias void* pvoid;
enum E : pvoid {
a=cast(pvoid)-1,
b=cast(pvoid)-2,
}
void foo(E e=E.a) {
writeln("Hello from foo");
}
void main() {
foo();
}
a.d(11): Error: no property 'a' for type 'void'
I see no "void" there, except that foo has a return type of void.
Re: Best way to store postgresql's "numeric" type in D?
On Wed, Oct 10, 2012 at 11:35:11AM +0200, denizzzka wrote: > It is up to 131072 digits before the decimal point; up to 16383 > digits after the decimal point. Sounds like a case for BigFloat (which isn't part of the standard library yet; somebody's working on it and it's about 95% complete now, from what I last heard). T -- Who told you to swim in Crocodile Lake without life insurance??
Re: Why are scope variables being deprecated?
Jonathan M Davis wrote:
On Thursday, July 26, 2012 21:09:09 Chad J wrote:
I keep hearing that scope variables are going away. I missed the
discussion on it. Why is this happening?
When I read about this, I have these in mind:
void someFunc()
{
// foo is very likely to get stack allocated
scope foo = new SomeClass();
foo.use();
// ~foo is called.
}
It's inherently unsafe. What happens if you returned a reference to foo from
someFunc? Or if you assigned a reference to foo to anything and then tried to
use it after someFunc has returned?
Why scope parameters are not deprecated then? It's the same situation.
You get undefined behavior, because foo
doesn't exist anymore.
Excuse me, but no, compiler should prevent escaping scope references
just like it does with scope parameters (I know it's currently
implemented just for delegates).
If you really need foo to be on the stack, then maybe
you should make it a struct.
Then you lose some useful class features.
scope on local variables is going away for pretty much the same reason that
delete is. They're unsafe, and the fact that they're in the core language
encourages their use.
That's not convincing for me. Pointers are also unsafe, and they're in
the core language.
> However, if you really do need scope for some
> reason, then you can use std.typecons.scoped, and it'll do the same
thing.
scoped is more dangerous than language solution. See:
class A { }
__gshared A globalA;
static this()
{
auto a = scoped!A;
globalA = a;
}
and this compiles (http://dpaste.dzfl.pl/6c078e66). With scope storage
class compiler would prevent this escaping assignment. It seems that we
ended up with a solution that was meant to fix a language builtin but
appears to be worse than that.
Re: Unable to understand this compiler error
On Wednesday, 10 October 2012 at 14:52:00 UTC, Lubos Pintes wrote:
Hi,
I discovered this while playing with DGUI's treeview module.
Here is a program that generates exactly the same error that
looks weird to me:
module a;
import std.stdio;
alias void* pvoid;
enum E : pvoid {
a=cast(pvoid)-1,
b=cast(pvoid)-2,
}
void foo(E e=E.a) {
writeln("Hello from foo");
}
void main() {
foo();
}
a.d(11): Error: no property 'a' for type 'void'
I see no "void" there, except that foo has a return type of
void.
I'm guessing a compiler bug. Looks to me as though it is
confusing E to be of type void (you declared it to be enumeration
of void*)
Re: Why are scope variables being deprecated?
Piotr Szturmaj: It seems that we ended up with a solution that was meant to fix a language builtin but appears to be worse than that. This is true, currently the library solution is worse (more dangerous and more broken) than the precedent built-in feature. But there is hope to have a good solution someday (mixing library code and some kind of built-support), while a broken built-in is not good. Andrei did the right thing: if you don't have a feature it's kind of easy to add something, while fixing some bad built-in is rather harder. Bye, bearophile
Re: not expected pointers for struct members from foreach
Struct pointers are useful and reliable, but before using them you need to know the difference between heap and stack, what a stack frame is, and how structs are handled when they are on the stack. Learning the basics of such things ideas requires only few minutes and it will be useful for many years. Bye, bearophile Thanks for useful feedback.
Re: Unable to understand this compiler error
Lubos Pintes:
I see no "void" there, except that foo has a return type of
void.
Minimized:
enum Foo : void* {
a = null
}
void main() {
auto f = Foo.a;
}
enums are good for ints, ubytes, longs, chars, etc. The more
types you try to put in them, the more compiler holes you will
find.
Bye,
bearophile
Re: Why are scope variables being deprecated?
bearophile wrote: Piotr Szturmaj: It seems that we ended up with a solution that was meant to fix a language builtin but appears to be worse than that. This is true, currently the library solution is worse (more dangerous and more broken) than the precedent built-in feature. But there is hope to have a good solution someday (mixing library code and some kind of built-support), while a broken built-in is not good. Andrei did the right thing: if you don't have a feature it's kind of easy to add something, while fixing some bad built-in is rather harder. Wasn't it broken because preventing escaping of scoped references was not implemented?
Re: Unable to understand this compiler error
Interesting. In treeview module I mentioned, there is an enum containing
some numeric values cast from HTREEITEM, which is in fact HANDLE, which
is void* if I understand properly.
I tried to convert DGUI to use dsource' WindowsAPI project, and at least
from compiler perspective, everything worked except this TreeView
weirdness...
Dňa 10. 10. 2012 17:51 bearophile wrote / napísal(a):
Lubos Pintes:
I see no "void" there, except that foo has a return type of void.
Minimized:
enum Foo : void* {
a = null
}
void main() {
auto f = Foo.a;
}
enums are good for ints, ubytes, longs, chars, etc. The more types you
try to put in them, the more compiler holes you will find.
Bye,
bearophile
non-const reference to const instance of class
Hi!
I thought that this should compile:
class Foo{}
const(Foo) foo = new Foo;// the same that const Foo foo?
foo = new Foo;
but compiler say that foo is const reference and it can't modify
it.
It is normally?If yes,how can I declare non-const reference to
const instance of class?
Re: non-const reference to const instance of class
On Wednesday, October 10, 2012 19:02:31 Zhenya wrote:
> Hi!
>
> I thought that this should compile:
> class Foo{}
>
> const(Foo) foo = new Foo;// the same that const Foo foo?
> foo = new Foo;
>
> but compiler say that foo is const reference and it can't modify
> it.
> It is normally?If yes,how can I declare non-const reference to
> const instance of class?
const Foo and const(Foo) are the same thing. They both create a const
reference to const data. This is in contrast to a pointer where const Bar* and
const(Bar)* are different. With a reference, there is no way to indicate that
the object is const but not the reference. The type system just doesn't
support the idea of a class object existing separately from a reference, so
there's no way to make that distinction.
If you want to have a mutable reference to a const object, then you need a
wrapper around the reference where the wrapper is mutable but the reference
isn't. std.typecons.Rebindable does this. It's what you should use.
- Jonathan M Davis
Re: Why are scope variables being deprecated?
On Wednesday, October 10, 2012 17:04:41 Piotr Szturmaj wrote:
> Jonathan M Davis wrote:
> > On Thursday, July 26, 2012 21:09:09 Chad J wrote:
> >> I keep hearing that scope variables are going away. I missed the
> >> discussion on it. Why is this happening?
> >>
> >> When I read about this, I have these in mind:
> >>
> >> void someFunc()
> >> {
> >>
> >> // foo is very likely to get stack allocated
> >> scope foo = new SomeClass();
> >> foo.use();
> >> // ~foo is called.
> >>
> >> }
> >
> > It's inherently unsafe. What happens if you returned a reference to foo
> > from someFunc? Or if you assigned a reference to foo to anything and then
> > tried to use it after someFunc has returned?
>
> Why scope parameters are not deprecated then? It's the same situation.
No. scope on parameters is completely different from scope on local variables.
scope on local variables puts the variable on the stack - even if it's a
class.
scope on function parameters is supposed to make it so that the compiler
prevents any references escaping (which potentially really restricts how you
can use the parameter). The only case where that would affect where a variable
is placed is that it makes it so that a closure isn't created for delegates
(which is the one place that scope on parameters actually works semi-
properly). So, the two uses of scope do completely different things.
> > If you really need foo to be on the stack, then maybe
> > you should make it a struct.
>
> Then you lose some useful class features.
What you lose is polymorphism, which doesn't work on the stack anyway.
Polymorphism is only applicable when you have a reference which could be of a
base class type rather than the derived type that the object actually is.
Objects on the stack must be their exact type.
> > scope on local variables is going away for pretty much the same reason
> > that
> > delete is. They're unsafe, and the fact that they're in the core language
> > encourages their use.
>
> That's not convincing for me. Pointers are also unsafe, and they're in
> the core language.
Pointers aren't unsafe. Certain operations are unsafe. Note that pointers are
perfectly legal in @safe code. It's pointer arithmetic which isn't.
> and this compiles (http://dpaste.dzfl.pl/6c078e66). With scope storage
> class compiler would prevent this escaping assignment. It seems that we
> ended up with a solution that was meant to fix a language builtin but
> appears to be worse than that.
It may very well be more dangerous, and that may or may not be fixable, but if
it's at the language level, then a lot more people are likely to use it, and
it's dangerous no matter where it is and shouldn't be used under normal
circumstances. Providing the feature is one thing. Making it easy to use is
another. It's like delete. It's dangerous and shouldn't be used normally, so
having it in the language where everyone will use it is too dangerous, so a
library solution is used instead. It therefore becomes more of a power user
feature (as it should be).
But regardless of the various pros and cons, it was decided ages ago that
it was not worth have scope on local variable be part of the language any
more. So, it's definitely going away.
- Jonathan M Davis
Re: non-const reference to const instance of class
On Wednesday, 10 October 2012 at 17:35:48 UTC, Jonathan M Davis
wrote:
On Wednesday, October 10, 2012 19:02:31 Zhenya wrote:
Hi!
I thought that this should compile:
class Foo{}
const(Foo) foo = new Foo;// the same that const Foo foo?
foo = new Foo;
but compiler say that foo is const reference and it can't
modify
it.
It is normally?If yes,how can I declare non-const reference to
const instance of class?
const Foo and const(Foo) are the same thing. They both create a
const
reference to const data. This is in contrast to a pointer where
const Bar* and
const(Bar)* are different. With a reference, there is no way to
indicate that
the object is const but not the reference. The type system just
doesn't
support the idea of a class object existing separately from a
reference, so
there's no way to make that distinction.
If you want to have a mutable reference to a const object, then
you need a
wrapper around the reference where the wrapper is mutable but
the reference
isn't. std.typecons.Rebindable does this. It's what you should
use.
- Jonathan M Davis
Thank you)
Re: Unable to understand this compiler error
Lubos Pintes: Interesting. In treeview module I mentioned, there is an enum containing some numeric values cast from HTREEITEM, which is in fact HANDLE, which is void* if I understand properly. I tried to convert DGUI to use dsource' WindowsAPI project, and at least from compiler perspective, everything worked except this TreeView weirdness... Anyway, this seems a compiler bug, so probably it should be added to bugzilla. Bye, bearophile
Re: Best way to store postgresql's "numeric" type in D?
On 10/10/12 5:35 AM, denizzzka wrote: It is up to 131072 digits before the decimal point; up to 16383 digits after the decimal point. For now, I guess string would be it. Andrei
Re: Why are scope variables being deprecated?
Jonathan M Davis wrote:
On Wednesday, October 10, 2012 17:04:41 Piotr Szturmaj wrote:
Jonathan M Davis wrote:
On Thursday, July 26, 2012 21:09:09 Chad J wrote:
I keep hearing that scope variables are going away. I missed the
discussion on it. Why is this happening?
When I read about this, I have these in mind:
void someFunc()
{
// foo is very likely to get stack allocated
scope foo = new SomeClass();
foo.use();
// ~foo is called.
}
It's inherently unsafe. What happens if you returned a reference to foo
from someFunc? Or if you assigned a reference to foo to anything and then
tried to use it after someFunc has returned?
Why scope parameters are not deprecated then? It's the same situation.
No. scope on parameters is completely different from scope on local variables.
scope on local variables puts the variable on the stack - even if it's a
class.
Yes, I know the difference between scope parameters and variables, but I
thought that they both can be considered "scope references" which can't
be escaped.
I don't support restoring scope variables in their previous state. But I
think I know a way to make scope variables safe by default.
scope on function parameters is supposed to make it so that the compiler
prevents any references escaping (which potentially really restricts how you
can use the parameter). The only case where that would affect where a variable
is placed is that it makes it so that a closure isn't created for delegates
(which is the one place that scope on parameters actually works semi-
properly). So, the two uses of scope do completely different things.
Could you give me an example of preventing closure allocation? I think I
knew one but I don't remember now...
With regards to escaping scope reference parameters, I hope that
eventually they all will be blocked by the compiler, not only
delegate/closure case.
If you really need foo to be on the stack, then maybe
you should make it a struct.
Then you lose some useful class features.
What you lose is polymorphism, which doesn't work on the stack anyway.
Polymorphism is only applicable when you have a reference which could be of a
base class type rather than the derived type that the object actually is.
Objects on the stack must be their exact type.
I know, class on the stack really become a "value" type. But it's still
useful. You can use non-scope classes with polymorhism as usual, but
when needed you can allocate one concrete class on the stack. You can't
assign subclass reference to scope class variable, but you still can
assign scope class reference to non-scope ancestor class references.
This may or may _not_ escape. I'm proposing that escaping assignments
should be blocked.
scope on local variables is going away for pretty much the same reason
that
delete is. They're unsafe, and the fact that they're in the core language
encourages their use.
That's not convincing for me. Pointers are also unsafe, and they're in
the core language.
Pointers aren't unsafe. Certain operations are unsafe. Note that pointers are
perfectly legal in @safe code. It's pointer arithmetic which isn't.
OK.
and this compiles (http://dpaste.dzfl.pl/6c078e66). With scope storage
class compiler would prevent this escaping assignment. It seems that we
ended up with a solution that was meant to fix a language builtin but
appears to be worse than that.
It may very well be more dangerous, and that may or may not be fixable, but if
it's at the language level, then a lot more people are likely to use it, and
it's dangerous no matter where it is and shouldn't be used under normal
circumstances. Providing the feature is one thing. Making it easy to use is
another. It's like delete. It's dangerous and shouldn't be used normally, so
having it in the language where everyone will use it is too dangerous, so a
library solution is used instead. It therefore becomes more of a power user
feature (as it should be).
I agree about delete operator, but as I wrote above, I'm not sure, but I
might know a way to make scope variables safe. I need to think about this :)
But regardless of the various pros and cons, it was decided ages ago that
it was not worth have scope on local variable be part of the language any
more. So, it's definitely going away.
I see, but scope might be also used in other scenarios, like emplacing
classes inside other classes.
Re: Why are scope variables being deprecated?
On Thursday, October 11, 2012 01:24:40 Piotr Szturmaj wrote: > Could you give me an example of preventing closure allocation? I think I > knew one but I don't remember now... Any time that a delegate parameter is marked as scope, the compiler will skip allocating a closure. Otherwise, it has to copy the stack from the caller onto the heap to create a closure so that the delegate will continue to work once the caller has completed (e.g. if the delegate were saved for a callback and then called way later in the program). Otherwise, it would refer to an invalid stack and really nasty things would happen when the delegate was called later. By marking the delegate as scope, you're telling the compiler that it will not escape the function that it's being passed to, so the compiler then knows that the stack that it refers to will be valid for the duration of that delegate's existence, so it knows that a closure is not required, so it doesn't allocate it, gaining you efficiency. - Jonathan M Davis
Re: Why are scope variables being deprecated?
Jonathan M Davis wrote:
On Thursday, October 11, 2012 01:24:40 Piotr Szturmaj wrote:
Could you give me an example of preventing closure allocation? I think I
knew one but I don't remember now...
Any time that a delegate parameter is marked as scope, the compiler will skip
allocating a closure. Otherwise, it has to copy the stack from the caller onto
the heap to create a closure so that the delegate will continue to work once
the caller has completed (e.g. if the delegate were saved for a callback and
then called way later in the program). Otherwise, it would refer to an invalid
stack and really nasty things would happen when the delegate was called later.
>
By marking the delegate as scope, you're telling the compiler that it will not
escape the function that it's being passed to, so the compiler then knows that
the stack that it refers to will be valid for the duration of that delegate's
existence, so it knows that a closure is not required, so it doesn't allocate
it, gaining you efficiency.
Thanks, that's clear now, but I found a bug:
__gshared void delegate() global;
void dgtest(scope void delegate() dg)
{
global = dg; // compiles
}
void dguse()
{
int i;
dgtest({ writeln(i++); });
}
I guess it's a known one.
How many std.concurrency receivers?
I haven't been able to get an idea of how many std.concurrency receivers is reasonable. Is it a reasonable way to implement a cellular automaton (assume each cell has a float number of states)...it isn't exactly a cellular automaton, but it isn't exactly a neural network, either. (I was considering Erlang, but each cell has variable state, which Erlang doesn't have a nice way to do.) TDPL quotes the recommendation from an Erlang book "Have LOTS of threads!", but doesn't really say how to guess at an order of magnitude of what's reasonable for D std.concurrency. People on Erlang say that 100's of thousands of threads is reasonable. Is it the same for D?
Re: Splitting a string on multiple tokens
On Wednesday, 10 October 2012 at 02:21:05 UTC, jerro wrote: On Wednesday, 10 October 2012 at 00:18:17 UTC, ixid wrote: Is there an effective way of splitting a string with a set of tokens? Splitter feels rather limited and multiple passes gives you an array of arrays of strings rather than an array of strings. I'm not sure if I'm missing an obvious application of library methods or if this is absent. You can use std.regex.splitter like this: auto r = regex(`,| |(--)`); auto str = "string we,want--to,split"; writeln(splitter(str, r)); //will pring ["string", "we", "want", "to", "split"] Thank you, though that removes the tokens and being varied those would be messy to replace. Is there a way that lets you cut on tokens and keep those tokens at the ends of the statements they cause to get cut? This seem like basic parsing features that are absent.
Linking with phobos on compiled dmd, osx 64bit
Hello all! I've been hacking on dmd, and something hasn't been working. This is how I compile it: cd dmd/src make -f posix.mak cd ../../druntime make -f posix.mak cd ../phobos make -f posix.mak MODEL=64 cp generated/osx/release/64/libphobos2.a /usr/local/lib/ cd ../dmd/src ./dmd file.d This is the error I get: ld: warning: ignoring file /usr/local/lib/libphobos2.a, file was built for archive which is not the architecture being linked (i386) Undefined symbols for architecture i386: "_main", referenced from: start in crt1.10.6.o (maybe you meant: _D4file7no_mainFAAyaZv) "_D3std5stdio12__ModuleInfoZ", referenced from: _D4file12__ModuleInfoZ in file.o "_D3std5stdio6stdoutS3std5stdio4File", referenced from: _D3std5stdio16__T7writelnTAyaZ7writelnFAyaZv in file.o "_D15TypeInfo_Struct6__vtblZ", referenced from: _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ in file.o "_D3std9exception7bailOutFNaNfAyakxAaZv", referenced from: _D3std9exception14__T7enforceTbZ7enforceFbLAxaAyakZb in file.o Any ideas on what's wrong? Thanks, NMS
Re: Linking with phobos on compiled dmd, osx 64bit
On Thursday, October 11, 2012 07:20:54 Nathan M. Swan wrote: > Any ideas on what's wrong? You're building a 32-bit dmd and a 32-bit druntime with a 64-bit Phobos. Use MODEL=64 on all of them. - Jonathan M Davis
