Re: Associative array on the heap
On Tuesday, 19 May 2015 at 00:31:50 UTC, Freddy wrote:
Sorry mis-phrased my question,
Who do you allocate a pointer to an associative
array(int[string]*).
Ignoring the why for a moment, one trick is to place it in an
array literal so it's heap allocated. This requires writing an
associative array literal with a single key-element pair though.
int[string]* a = [["zero":0]].ptr;
Another trick is to initially define the associative array in a
class. Since classes are heap allocated, you can allocate an
instance of the class and grab a pointer to the associative array.
class HeapAA
{
int[string] a;
}
int[string]*b = &(new HeapAA).a;
Re: Associative array on the heap
On Tuesday, 19 May 2015 at 00:00:30 UTC, Meta wrote:
On Monday, 18 May 2015 at 23:55:40 UTC, Freddy wrote:
How do you allocate an associative array on the heap?
void main(){
alias A=int[string];
auto b=new A;
}
$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays
or class objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]
They are allocated on the heap implicitly; there's no need for
`new`. You actually *can't* use new with an AA, which is what
the compiler is telling you.
void main()
{
alias A = int[string];
A b = []; //No allocation yet, b is null
b["test"] = 1; //b is now non-null
}
Sorry mis-phrased my question,
Who do you allocate a pointer to an associative
array(int[string]*).
Re: Associative array on the heap
On Monday, 18 May 2015 at 23:55:40 UTC, Freddy wrote:
How do you allocate an associative array on the heap?
void main(){
alias A=int[string];
auto b=new A;
}
$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays
or class objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]
They are allocated on the heap implicitly; there's no need for
`new`. You actually *can't* use new with an AA, which is what the
compiler is telling you.
void main()
{
alias A = int[string];
A b = []; //No allocation yet, b is null
b["test"] = 1; //b is now non-null
}
Re: Associative array on the heap
On Mon, 18 May 2015 23:55:38 +, Freddy wrote:
> How do you allocate an associative array on the heap?
>
> void main(){
> alias A=int[string];
> auto b=new A;
> }
>
> $ rdmd test test.d(4): Error: new can only create structs, dynamic
> arrays or class objects, not int[string]'s Failed: ["dmd", "-v", "-o-",
> "test.d", "-I."]
AAs are always allocated on heap, you don't need to do anything special.
signature.asc
Description: PGP signature
Re: Associative array on the heap
On Tuesday, 19 May 2015 at 00:00:30 UTC, Meta wrote: A b = []; //No allocation yet, b is null Whoops, you actually can't assign the empty array literal to an AA. This line should be: A b; Which has the exact same effects.
Associative array on the heap
How do you allocate an associative array on the heap?
void main(){
alias A=int[string];
auto b=new A;
}
$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays or
class objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]
Re: Capturing Caller UDAs as CT Template Function Parameters
On Monday, 18 May 2015 at 21:35:44 UTC, Per Nordlöw wrote:
void yield(T)(ref T value)
{
mixin("alias caller = " ~ caller ~ ";");
}
doesn't work across module boundaries not even for
`__PRETTY_FUNCTION__`.
Do we need need to fix the compiler, Walter?! ;)
You have to import the module, too:
void yield(T, string caller_str = __FUNCTION__)(ref T value)
{
import std.array: join, split;
enum module_str = caller_str.split(".")[0 .. $ - 1].join(".");
mixin("static import " ~ module_str ~ ";");
mixin("alias caller = " ~ caller_str ~ ";");
}
This fails for methods, of course. I guess you could remove
elements from the back of __FUNCTION__ until it compiles as a
module, and then import that.
Re: Capturing Caller UDAs as CT Template Function Parameters
On Monday, 18 May 2015 at 21:30:23 UTC, Per Nordlöw wrote:
On Monday, 18 May 2015 at 21:04:19 UTC, Per Nordlöw wrote:
To clarify: Instead of *string* `__FUNCTION__` I instead want
a reference to the *symbol* of the calling function scope
typically passed as an alias parameter. We could of course
always solve it with a mixin but that is 6+1 characters too
many ;)
I'm gonna try the tips here:
http://forum.dlang.org/thread/mailman.160.1376790770.1719.digitalmars-d-le...@puremagic.com
void yield(T)(ref T value)
{
mixin("alias caller = " ~ caller ~ ";");
}
doesn't work across module boundaries not even for
`__PRETTY_FUNCTION__`.
Do we need need to fix the compiler, Walter?! ;)
Re: Capturing Caller UDAs as CT Template Function Parameters
On Monday, 18 May 2015 at 21:04:19 UTC, Per Nordlöw wrote: To clarify: Instead of *string* `__FUNCTION__` I instead want a reference to the *symbol* of the calling function scope typically passed as an alias parameter. We could of course always solve it with a mixin but that is 6+1 characters too many ;) I'm gonna try the tips here: http://forum.dlang.org/thread/mailman.160.1376790770.1719.digitalmars-d-le...@puremagic.com
Re: Capturing Caller UDAs as CT Template Function Parameters
On Monday, 18 May 2015 at 21:00:20 UTC, Per Nordlöw wrote: Is this doable somehow? To clarify: Instead of *string* `__FUNCTION__` I instead want a reference to the *symbol* of the calling function scope typically passed as an alias parameter. We could of course always solve it with a mixin but that is 6+1 characters too many ;)
Capturing Caller UDAs as CT Template Function Parameters
As a follow up to the most http://forum.dlang.org/thread/miri9k$2p5$1...@digitalmars.com I'm now very much interested in finding a way to make yield() capture the UDAs of its caller. That is instead of void yield(T)(ref T value) I want it to get a hold of the UDAs of the calling function and somehow propagate them as compile-time template arguments. Something like void yield(T, callerAttributes = __traits(getAttributes, __FUNCTION__))(ref T value) The problem with this is that __FUNCTION__ is a string when getAttributes expects a symbol. Can I somehow can a hold of the symbol of the caller. Is this doable somehow?
Re: The analogue of "fill-pointer" in D
On 05/18/2015 11:52 AM, Steven Schveighoffer wrote: > Also note that the longest slice doesn't necessarily have access to > appending. All that is required is that the slice end lands on the array > end: That explains a lot. Thanks. Ali
Re: The analogue of "fill-pointer" in D
On 5/18/15 2:45 PM, Ali Çehreli wrote: Exactly! That recent discovery of mine made me come up with this guideline: "Never append to a parameter slice." I think this may not be an appropriate guideline. It's perfectly fine to append to a parameter slice. You just need to leave it the way you found it. Unless the point of the function is to append to it (maybe you return the result for example). -Steve
Re: ddbc: MySQL/MariaDB: Access Violation
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; p.s. this command return my: "Affected rows: 0 " Do you see some stack trace on crash? No. I checked on 2 PC and it's not look like my issue, because result is totally same. If I change void main() to vibed's static this() I get this error.
Re: The analogue of "fill-pointer" in D
On 5/18/15 2:40 PM, Ali Çehreli wrote:
On 05/18/2015 11:19 AM, John Colvin wrote:> On Monday, 18 May 2015 at
17:43:50 UTC, Ali Çehreli wrote:
>> On 05/18/2015 05:26 AM, John Colvin wrote:
>>> On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
> No, afraid not. Function capacity is not an analogue of
fill-pointers!
It's exactly the same.
>>>
>>> But in D capacity is affected by other things.
>>>
>>> auto a = new int[20];
>>> auto b = arr[0..10];
>>> //can't now append to b without re-allocating or using
assumeSafeAppend.
>>
>> Perfect opportunity to inject my newly-discovered issue with capacity:
>>
>> void main()
>> {
>> auto a = new int[20];
>> foo(a);
>> //can't now append to a
>> }
>>
>> void foo(const(int)[] p)
>> {
>> p ~= 42;
>> }
>>
>> Ali
>
> I don't understand what's counterintuitive here. Slices are just pointer
> and length, everything else is global state.
Nothing counterintuitive. I have discovered recently that when there are
multiple slices with equal length, capacity is shared until one of them
appends, in which case that first appender wins the capacity.
I have always known about non-stomping and why this has to be so. What
was new to me is the initial suspense when we don't know who will win
the capacity. Just news to me.
In all other cases where there is one longest slice (like your example),
then there is only one owner of capacity.
It's no different. No slice "owns" the capacity, the runtime does. There
can be multiple slices that access the capacity.
Also note that the longest slice doesn't necessarily have access to
appending. All that is required is that the slice end lands on the array
end:
int[] arr = new int()[5];
auto arr2 = arr[4..5];
arr = arr[0..3];
assert(arr.length > arr2.length);
assert(arr2.capacity);
assert(arr.capacity == 0);
It is a very difficult concept to conceptualize. I should write a pseudo
array type to demonstrate how the array runtime code works as an object
instead of as a collection of obtuse runtime functions.
-Steve
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 17:14:46 UTC, Steven Schveighoffer wrote: capacity is analogous to the number of elements in the vector (as returned by array-dimension according to https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node162.html). arr.length is analogous to the fill pointer. example: int[] arr = new int[](5); assert(arr.capacity > 5); assert(arr.length == 5); arr.reserve(100); // expand arr memory block to be able to hold *at least* 100 ints assert(arr.capacity >= 100); assert(arr.length == 5); auto ptr = arr.ptr; // for later assert arr ~= 1; // increment length by 1, 'fill in' tail of array with '1' // this should demonstrate how it works assert(arr.length == 6); // new fill pointer assert(arr.capacity >= 100); // capacity unchanged assert(arr.ptr is ptr); // array still lives in same memory block Apologies for not translating to lisp, I don't know it. -Steve Thank you. This is what you need!
Re: The analogue of "fill-pointer" in D
On 05/18/2015 10:52 AM, Steven Schveighoffer wrote:
> On 5/18/15 1:43 PM, Ali Çehreli wrote:
>> void main()
>> {
>> auto a = new int[20];
>> foo(a);
>> //can't now append to a
>
> Well, sure you can :)
>
> a ~= 5; // works fine
>
> But I understand you mean that an append to 'a' will reallocate
>
>> }
>>
>> void foo(const(int)[] p)
>> {
>> p ~= 42;
>> }
> BTW, the way to prevent this is to do something like:
>
> a) dup p on append
> b) const x = p; scope(exit) x.assumeSafeAppend();
Exactly! That recent discovery of mine made me come up with this
guideline: "Never append to a parameter slice."
No, I may not follow that guideline myself but it makes sense to me:
http://forum.dlang.org/thread/mi21dq$l6l$1...@digitalmars.com#post-mi739e:241v83:241:40digitalmars.com
Ali
Re: The analogue of "fill-pointer" in D
On 05/18/2015 11:19 AM, John Colvin wrote:> On Monday, 18 May 2015 at
17:43:50 UTC, Ali Çehreli wrote:
>> On 05/18/2015 05:26 AM, John Colvin wrote:
>>> On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
> No, afraid not. Function capacity is not an analogue of
fill-pointers!
It's exactly the same.
>>>
>>> But in D capacity is affected by other things.
>>>
>>> auto a = new int[20];
>>> auto b = arr[0..10];
>>> //can't now append to b without re-allocating or using
assumeSafeAppend.
>>
>> Perfect opportunity to inject my newly-discovered issue with capacity:
>>
>> void main()
>> {
>> auto a = new int[20];
>> foo(a);
>> //can't now append to a
>> }
>>
>> void foo(const(int)[] p)
>> {
>> p ~= 42;
>> }
>>
>> Ali
>
> I don't understand what's counterintuitive here. Slices are just pointer
> and length, everything else is global state.
Nothing counterintuitive. I have discovered recently that when there are
multiple slices with equal length, capacity is shared until one of them
appends, in which case that first appender wins the capacity.
I have always known about non-stomping and why this has to be so. What
was new to me is the initial suspense when we don't know who will win
the capacity. Just news to me.
In all other cases where there is one longest slice (like your example),
then there is only one owner of capacity.
Ali
Re: -vgc Info ok?
On Mon, 18 May 2015 14:41:19 +, Chris wrote: > On Monday, 18 May 2015 at 14:34:38 UTC, ketmar wrote: >> On Mon, 18 May 2015 14:30:42 +, Chris wrote: >> >>> The following >>> >>> string[string] myarray = ["key":"value"]; >>> string entry; >>> entry = myarray["key"]; // => vgc: indexing an associative array may >>> cause GC allocation >>> >>> Why is _accessing_ an assoc treated as indexing it? >> >> it can throw "out of range" error, which is `new`ed. > > But shouldn't it read "accessing an associative array may cause GC > allocation"? not any access may cause allocation. `auto e = "key" in myarray;` will not allocate, for example. yet it's still accessing the array. it's *indexing* which may end in allocation. > And maybe a hint to the exception that may be thrown. i believe that such explanation is a work for lint-like tool. burden compiler with special cases can lead too far. ;-) > It's not the same as > > myarray["key1] = "some value"; > myarray["key2] = "some other value"; > > A bit confusing. yes, it requires some knowledge of language and libraries. "-vgc" is not a linter, though, it was made with some assumptions about user's knowledge. yet you can open ER in bugzilla, maybe DMD developers will implement it. i'm not a developer, and i can be wrong in reasons behind "-vgc". signature.asc Description: PGP signature
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 17:43:50 UTC, Ali Çehreli wrote:
On 05/18/2015 05:26 AM, John Colvin wrote:
On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
No, afraid not. Function capacity is not an analogue of
fill-pointers!
It's exactly the same.
But in D capacity is affected by other things.
auto a = new int[20];
auto b = arr[0..10];
//can't now append to b without re-allocating or using
assumeSafeAppend.
Perfect opportunity to inject my newly-discovered issue with
capacity:
void main()
{
auto a = new int[20];
foo(a);
//can't now append to a
}
void foo(const(int)[] p)
{
p ~= 42;
}
Ali
I don't understand what's counterintuitive here. Slices are just
pointer and length, everything else is global state.
Re: The analogue of "fill-pointer" in D
On 5/18/15 1:43 PM, Ali Çehreli wrote:
On 05/18/2015 05:26 AM, John Colvin wrote:
On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
No, afraid not. Function capacity is not an analogue of fill-pointers!
It's exactly the same.
But in D capacity is affected by other things.
auto a = new int[20];
auto b = arr[0..10];
//can't now append to b without re-allocating or using assumeSafeAppend.
Perfect opportunity to inject my newly-discovered issue with capacity:
void main()
{
auto a = new int[20];
foo(a);
//can't now append to a
Well, sure you can :)
a ~= 5; // works fine
But I understand you mean that an append to 'a' will reallocate
}
void foo(const(int)[] p)
{
p ~= 42;
}
Not an issue, intended behavior.
For instance if foo did this:
p ~= 42;
someGlobal = p;
Now, if you didn't prevent appending a from stomping on memory, then
someGlobal would be stomped.
BTW, the way to prevent this is to do something like:
a) dup p on append
b) const x = p; scope(exit) x.assumeSafeAppend();
Hm... an interesting wrapper type would be an 'always reallocating'
slice type. It would have an extra boolean to indicate it must realloc
upon append (which would then clear after the first append).
-Steve
Re: The analogue of "fill-pointer" in D
On 05/18/2015 05:26 AM, John Colvin wrote:
On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote:
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
No, afraid not. Function capacity is not an analogue of fill-pointers!
It's exactly the same.
But in D capacity is affected by other things.
auto a = new int[20];
auto b = arr[0..10];
//can't now append to b without re-allocating or using assumeSafeAppend.
Perfect opportunity to inject my newly-discovered issue with capacity:
void main()
{
auto a = new int[20];
foo(a);
//can't now append to a
}
void foo(const(int)[] p)
{
p ~= 42;
}
Ali
Re: Const is already there. It cannot deduce it
On Sunday, 17 May 2015 at 21:34:21 UTC, tcak wrote:
[code]
void test(D)( const D data ) if( is(D: shared(char[]) ) ) { }
void main() {
char[] text = new char[4];
text[0] = 'a'; text[1] = 'b'; text[2] = 'c'; text[3] = 'd';
auto t = cast( shared(const(char[])) )text[1..2];
test( t );
}
[/code]
Error Message:
template main.test cannot deduce function from argument types
!()(shared(const(char[])))
`t` is already shared(const(char[])), and `test` is expecting
const shared(char[]). Aren't they already same?
Per the template constraint, test needs a type D that implicitly
converts to shared(char[]). Even when the top const is removed
from typeof(t), there's still const in there:
shared(const(char)[]). That isn't implicitly convertible to
shared(char[]). Add const in the constraint and it works:
if( is(D: shared(const char[])) )
--
Together with this question, I want to ask whether there is a
way to check only being `shared`,
is(T == shared)
only being `const`,
is(T == const)
or only being `char[]`
I guess you mean to ignore any qualifiers of the array itself and
the element type.
We have std.traits.Unqual, but that only removes qualifiers from
the top level. As far as I know, we don't have anything like a
DeepUnqual which would allow you to write is(DeepUnqual!T ==
char[]). You could write one.
Or you can get into the more advanced versions of the
IsExpression:
is(T == E[], E) && is(Unqual!E == char)
of a template variable (D of `test` in this case)?
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote:
On Monday, 18 May 2015 at 10:14:33 UTC, Kagamin wrote:
On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote:
Hi,
In Common Lisp, there is such a thing as a fill-pointer
(Example 5):
http://www.tutorialspoint.com/lisp/lisp_arrays.htm
Does D some equivalent?
Data stored in the array is indicated by the array length
property, use capacity to figure out extra available space:
http://dlang.org/phobos/object.html#.capacity
No, afraid not. Function capacity is not an analogue of
fill-pointers!
Lisp-programmer explains the usefulness of fill-pointers as
follows:
"Fill pointer "cuts" the tail of the vector. For example,
vector elements 100, but if you set the fill pointer equal to
3, the length of the array (returned by length) will be equal
to 3. The remaining elements are not visible.
It seems to be nonsense. But this is nonsense, ideal for
buffers. If the buffer is implemented as an array, then fill
pointer just marks the boundary of the filled part of the
buffer, and adding a buffer (moving away from the fill
pointer-a) is carried out using the vector-push. Or a buffer
can be filled with the format-a. If you work with the same
buffer C, fill pointer simulates a pointer to the last
completed item."
There are a lot of ways of doing this in D.
std.array.appender makes a good imitation of this, just missing
the vector-push, which can be implemented like this, roughly:
ptrdiff_t putNoAlloc(App, T)(App app, T el)
{
if (app.capacity)
{
app.put(el);
return app.data.length - 1;
}
else
return -1;
}
It would also be trivial to hand-make a type that has whatever
behaviour you want with regards to array appending, lengths etc.
Re: overloading evaluation (treating objects as functions)
On Sunday, 17 May 2015 at 18:49:40 UTC, dan wrote:
Is it possible to define a class F so that
auto f=new F();
writeln("The value of f at 7 is ",f(7));
compiles and works as expected?
So the idea would be to be able to use notation like
f(7)
instead of
f.eval(7)
or something along those lines.
My guess is no, it is impossible to do this, because i can't
find it on the internet or in Alexandrescu's book.
But it is also possible that everybody considers it so obvious
that they just don't elaborate on it. I'd be delighted if
there were the case, at least if somebody would elaborate on it
if so.
TIA for any info!
dan
http://dlang.org/operatoroverloading.html#function-call
Re: How to create a mutable array of strings?
On Monday, 18 May 2015 at 13:14:38 UTC, Steven Schveighoffer wrote: It's annoying to have to dup each one. Yes, it's really annoying. However, the problem can be solved as follows: http://forum.dlang.org/thread/owxweucyzjwugpjwh...@forum.dlang.org?page=2#post-cqjevoldkqdkmdbenkul:40forum.dlang.org On Monday, 18 May 2015 at 13:14:38 UTC, Steven Schveighoffer wrote: But, you do have a couple other possibilities: auto s = ["foo".dup, "bar".dup]; import std.algorithm : map; import std.array : array; auto s = map!(a => a.dup)(["foo", "bar"]).array; // this will needlessly allocate an array for the strings Now imagine that you have a multi-dimensional array of strings. This will not work: auto s = map!(a => a.dup)([["foo", "baz"], ["bar", "test"]]).array; You have to apply to each line .dup :) auto s = [["foo".dup, "baz".dup], ["bar".dup, "test".dup]]; s[1][0][1] = 't'; On Monday, 18 May 2015 at 13:14:38 UTC, Steven Schveighoffer wrote: But really, a string is immutable. There's not a way around that. A string is the most basic level of array primitive, not even mutable arrays of non-char types have that, and it's an annoyance. From there, you have to build the data out of ROM into the heap. Thank you. I do not know. And yet, the problem is easily solved. You just have to add .deepDup Phobos: http://forum.dlang.org/thread/owxweucyzjwugpjwh...@forum.dlang.org?page=2#post-cqjevoldkqdkmdbenkul:40forum.dlang.org
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 11:40:13 UTC, thedeemon wrote: On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote: No, afraid not. Function capacity is not an analogue of fill-pointers! It's exactly the same. But in D capacity is affected by other things. auto a = new int[20]; auto b = arr[0..10]; //can't now append to b without re-allocating or using assumeSafeAppend.
Re: CTFE & enums & static assert
On 2015-05-15 17:26:50 +, Ali Çehreli said:
On 05/15/2015 09:45 AM, Robert M. Münch wrote:
> Is there a way I can build an ENUM from within the FOREACH? What I want
> to achive is, that I would like to use:
>
> final switch (myEnum) ...
Sorry, I don't understand your question. :(
Do you want to define an enum at compile time? Then you can use mixins.
Do you want to build an enum value inside the foreach? Yes, it is
possible as well.
Hi, yes to both. I have solved it now like this:
enum A {a, b, c};
enum members1 = __traits(allMembers, A); // returns TypeTuple
// function that generates a string which is used as a mixin at compile time
// result string must conform to syntax as it was hand-written code
string generateEnum(T...)(string type){
string code = "enum " ~ type ~ " {";
// this is a static foreach (compile time)
foreach(m; T){
debug pragma(msg, m ~ ","); // check what code we get at compile time
code ~= m ~ ",";
}
return(code ~ "}");
}
int main(){
A switch_var_a;
final switch(switch_var_a){
case A.a:
case A.b:
case A.c:
}
mixin(generateEnums!members1("B"));
B switch_var_b;
final switch(switch_var_b){
case B.a:
// case B.b: // if commeted will cause a compiler error
case B.c:
}
return(0);
}
So, the solution was to use a "string mixin".
IMO it's a very powerful pattern to build an ENUM at compile time that
can be used with a FINAL SWITCH.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Const is already there. It cannot deduce it
[code]
void test(D)( const D data ) if( is(D: shared(char[]) ) ) { }
void main() {
char[] text = new char[4];
text[0] = 'a'; text[1] = 'b'; text[2] = 'c'; text[3] = 'd';
auto t = cast( shared(const(char[])) )text[1..2];
test( t );
}
[/code]
Error Message:
template main.test cannot deduce function from argument types
!()(shared(const(char[])))
`t` is already shared(const(char[])), and `test` is expecting
const shared(char[]). Aren't they already same?
--
Together with this question, I want to ask whether there is a way
to check only being `shared`, only being `const`, or only being
`char[]` of a template variable (D of `test` in this case)?
Re: -vgc Info ok?
On Monday, 18 May 2015 at 14:34:38 UTC, ketmar wrote: On Mon, 18 May 2015 14:30:42 +, Chris wrote: The following string[string] myarray = ["key":"value"]; string entry; entry = myarray["key"]; // => vgc: indexing an associative array may cause GC allocation Why is _accessing_ an assoc treated as indexing it? it can throw "out of range" error, which is `new`ed. But shouldn't it read "accessing an associative array may cause GC allocation"? And maybe a hint to the exception that may be thrown. It's not the same as myarray["key1] = "some value"; myarray["key2] = "some other value"; A bit confusing.
Re: 'const' and 'in' parameter storage classes
On 5/15/15 2:19 PM, ref2401 wrote: On Friday, 15 May 2015 at 16:30:29 UTC, Steven Schveighoffer wrote: On 5/15/15 12:04 PM, ref2401 wrote: What is the difference between 'const' and 'in' parameter storage classes? When should I use 'const' or 'in'? The documentation says 'in' is the same as 'const scope' but I can't write 'const scope ref' though it's legal to write 'in ref'. scope ref const still getting the error: Error: scope cannot be ref or out interesting. Seems you would be right then. The only other possibility could be ref scope const, but that doesn't seem right, I'll try it. Nope, so basically there is no way to do in by expanding to scope const. This is something that should be considered if we ever want to modify what 'in' means. I am not sure yet whether "in ref" should be valid or "scope ref" should be valid either. It doesn't seem to me that it should trigger an error. -Steve
overloading evaluation (treating objects as functions)
Is it possible to define a class F so that
auto f=new F();
writeln("The value of f at 7 is ",f(7));
compiles and works as expected?
So the idea would be to be able to use notation like
f(7)
instead of
f.eval(7)
or something along those lines.
My guess is no, it is impossible to do this, because i can't find
it on the internet or in Alexandrescu's book.
But it is also possible that everybody considers it so obvious
that they just don't elaborate on it. I'd be delighted if there
were the case, at least if somebody would elaborate on it if so.
TIA for any info!
dan
control flow with a functional template ?
who's never had to do this:
---
if (comparison)
{
statement;
break;
}
---
ans then thought it's a pity to open/closes the braces just for a
simple statement. Would it be possible to have a template to
simplify this to:
---
if (comparison)
Break!(expression);
---
or even at the language level:
---
if (comparison)
break(expression);
if (comparison)
continue(expression);
---
so far it looks like it's only possible using a string mixin,
which is a quite unelegant solution (because for example you
loose the IDE completion while writting the statement):
---
auto Break(string statement)
{
return format("{%s;break;}", statement);
}
// unelegant but works...
if (condition)
mixin("myVar = 8".Break);
if (condition)
mixin(q{myVar = 8}.Break);
---
Any other solution ?
Re: Convert C array pointer to a D slice without data copy
On Monday, 18 May 2015 at 09:23:26 UTC, tcak wrote: On Monday, 18 May 2015 at 09:18:33 UTC, ParticlePeter wrote: I get the point to an array from a c function, the data size from another function. The data should be only readable at the D side, but I would like to use it as a D slice without copying the data. Is this possible ? char* dataPtr; size_t dataLen; auto data = dataPtr[0 .. dataLen]; This doesn't do any copying. BUT I am not sure what GC would be doing about it. After you use it, you might want to set `data` to null in case of a problem. No need to worry about the GC here, it only scans the stack and its own heap (unless you specifically add a new root).
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote: It seems to be nonsense. But this is nonsense, ideal for buffers. If the buffer is implemented as an array, then fill pointer just marks the boundary of the filled part of the buffer, and adding a buffer (moving away from the fill pointer-a) is carried out using the vector-push. Or a buffer can be filled with the format-a. If you work with the same buffer C, fill pointer simulates a pointer to the last completed item." Filling a buffer is usually done this way: http://dlang.org/phobos/std_stdio.html#.File.rawRead
Re: ddbc: MySQL/MariaDB: Access Violation
still can't get it's work :(
Re: Convert C array pointer to a D slice without data copy
On Monday, 18 May 2015 at 09:23:26 UTC, tcak wrote: On Monday, 18 May 2015 at 09:18:33 UTC, ParticlePeter wrote: I get the point to an array from a c function, the data size from another function. The data should be only readable at the D side, but I would like to use it as a D slice without copying the data. Is this possible ? char* dataPtr; size_t dataLen; auto data = dataPtr[0 .. dataLen]; This doesn't do any copying. BUT I am not sure what GC would be doing about it. After you use it, you might want to set `data` to null in case of a problem. Thanks, works. Should be in the "Interfacing to C" Reference Article.
Re: overloading evaluation (treating objects as functions)
On 05/17/2015 11:49 AM, dan wrote: i can't find it on the internet There is the following short section as well: http://ddili.org/ders/d.en/operator_overloading.html#ix_operator_overloading.opCall Ali
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote: Hi, In Common Lisp, there is such a thing as a fill-pointer (Example 5): http://www.tutorialspoint.com/lisp/lisp_arrays.htm Does D some equivalent? Fill pointers, combined with the various helper functions (e.g. vector-push) and vector-extend, perform tasks that D uses slices for. e.g. vector-push-extend is roughly equivalent to the ~= operator, given a non-aliased array. There are important differences, but the functionality overlaps a lot.
Re: The analogue of "fill-pointer" in D
On 5/18/15 6:24 AM, Dennis Ritchie wrote: On Monday, 18 May 2015 at 10:14:33 UTC, Kagamin wrote: On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote: Hi, In Common Lisp, there is such a thing as a fill-pointer (Example 5): http://www.tutorialspoint.com/lisp/lisp_arrays.htm Does D some equivalent? Data stored in the array is indicated by the array length property, use capacity to figure out extra available space: http://dlang.org/phobos/object.html#.capacity No, afraid not. Function capacity is not an analogue of fill-pointers! capacity is analogous to the number of elements in the vector (as returned by array-dimension according to https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node162.html). arr.length is analogous to the fill pointer. example: int[] arr = new int[](5); assert(arr.capacity > 5); assert(arr.length == 5); arr.reserve(100); // expand arr memory block to be able to hold *at least* 100 ints assert(arr.capacity >= 100); assert(arr.length == 5); auto ptr = arr.ptr; // for later assert arr ~= 1; // increment length by 1, 'fill in' tail of array with '1' // this should demonstrate how it works assert(arr.length == 6); // new fill pointer assert(arr.capacity >= 100); // capacity unchanged assert(arr.ptr is ptr); // array still lives in same memory block Apologies for not translating to lisp, I don't know it. -Steve
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 12:49:56 UTC, Kagamin wrote: Filling a buffer is usually done this way: http://dlang.org/phobos/std_stdio.html#.File.rawRead Here such example, the task. There is a flow stream, associated, for example, with any socket. It wrote several bytes at a time. To once again not to pull the socket, we start buffer as an array with Phill-pointer. Adding byte array - using the vector-push. When the buffer is stuffed, dump it into the stream and moves pointer to zero. How to do it with the help of readRaw or there writeRaw?
Re: ddbc: MySQL/MariaDB: Access Violation
On Sunday, 17 May 2015 at 10:24:43 UTC, Suliman wrote: I am using this driver for access to MariaDB http://code.dlang.org/packages/ddbc The problem that it's work fine when it's used from desktop App, but when I try to run it's from vibed app i get "Access Violation". In my.ini I added string: bind-address = 127.0.0.1 Also I run next command: GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; p.s. this command return my: "Affected rows: 0 " Do you see some stack trace on crash?
Re: How to create a mutable array of strings?
On Monday, 18 May 2015 at 14:43:33 UTC, Steven Schveighoffer
wrote:
Right, you'd apply the map/array combo to each element:
Yes, I knew it.
alias m = map!(a => a.dup); // too bad can't do array as well
auto s = [m(["foo", "baz"]).array, m(["bar", "test"]).array];
Or to get even more crazy:
auto s = map!(a => map!(a => a.dup)(a).array)(/* your input
array */).array;
Imagine a five-dimensional array will be :)
But this means you are duping more of the array literal than
you really should.
It's likely helpful to have somewhere in std.array a dupArray
function that does map!(a => a.dup).array work in one go (and
without making a temporary array):
auto s = [dupArray("foo", "baz"), dupArray("bar", "test")];
Yes, it would be nice. I believe that Phobos need such function.
deepDup would dup the whole thing. All you need to dup is the
string literals, as array literals constructed at runtime are
on the heap (and mutable) already. The literal already is
wasted even in my original suggestion, but this is doubly
wasteful.
Right.
Re: How to create a mutable array of strings?
On 5/18/15 9:55 AM, Dennis Ritchie wrote:
On Monday, 18 May 2015 at 13:14:38 UTC, Steven Schveighoffer wrote:
It's annoying to have to dup each one.
Yes, it's really annoying. However, the problem can be solved as follows:
http://forum.dlang.org/thread/owxweucyzjwugpjwh...@forum.dlang.org?page=2#post-cqjevoldkqdkmdbenkul:40forum.dlang.org
On Monday, 18 May 2015 at 13:14:38 UTC, Steven Schveighoffer wrote:
But, you do have a couple other possibilities:
auto s = ["foo".dup, "bar".dup];
import std.algorithm : map;
import std.array : array;
auto s = map!(a => a.dup)(["foo", "bar"]).array; // this will
needlessly allocate an array for the strings
Now imagine that you have a multi-dimensional array of strings. This
will not work:
auto s = map!(a => a.dup)([["foo", "baz"], ["bar", "test"]]).array;
Right, you'd apply the map/array combo to each element:
alias m = map!(a => a.dup); // too bad can't do array as well
auto s = [m(["foo", "baz"]).array, m(["bar", "test"]).array];
Or to get even more crazy:
auto s = map!(a => map!(a => a.dup)(a).array)(/* your input array */).array;
But this means you are duping more of the array literal than you really
should.
It's likely helpful to have somewhere in std.array a dupArray function
that does map!(a => a.dup).array work in one go (and without making a
temporary array):
auto s = [dupArray("foo", "baz"), dupArray("bar", "test")];
On Monday, 18 May 2015 at 13:14:38 UTC, Steven Schveighoffer wrote:
But really, a string is immutable. There's not a way around that. A
string is the most basic level of array primitive, not even mutable
arrays of non-char types have that, and it's an annoyance. From there,
you have to build the data out of ROM into the heap.
Thank you. I do not know.
And yet, the problem is easily solved. You just have to add ..deepDup
Phobos:
http://forum.dlang.org/thread/owxweucyzjwugpjwh...@forum.dlang.org?page=2#post-cqjevoldkqdkmdbenkul:40forum.dlang.org
deepDup would dup the whole thing. All you need to dup is the string
literals, as array literals constructed at runtime are on the heap (and
mutable) already. The literal already is wasted even in my original
suggestion, but this is doubly wasteful.
-Steve
Re: Convert C array pointer to a D slice without data copy
Am Mon, 18 May 2015 09:51:48 + schrieb "John Colvin" : > No need to worry about the GC here, it only scans the stack and > its own heap (unless you specifically add a new root). And even if you add a root it wont free anything it did not allocate itself! You could even append to your C array. It will check how much capacity the slice still has on the GC heap and after realizing the .ptr is not even in one of its pools, allocate a GC copy of the C array right away. -- Marco
Re: 'const' and 'in' parameter storage classes
Am Mon, 18 May 2015 09:05:51 -0400 schrieb Steven Schveighoffer : > On 5/15/15 2:19 PM, ref2401 wrote: > > On Friday, 15 May 2015 at 16:30:29 UTC, Steven Schveighoffer wrote: > >> On 5/15/15 12:04 PM, ref2401 wrote: > >>> What is the difference between 'const' and 'in' parameter storage > >>> classes? > >>> When should I use 'const' or 'in'? > >>> > >>> The documentation says 'in' is the same as 'const scope' but I can't > >>> write 'const scope ref' though it's legal to write 'in ref'. > >> > >> scope ref const > >> > > > > still getting the error: Error: scope cannot be ref or out > > interesting. Seems you would be right then. > > The only other possibility could be ref scope const, but that doesn't > seem right, I'll try it. > > Nope, so basically there is no way to do in by expanding to scope const. > This is something that should be considered if we ever want to modify > what 'in' means. > > I am not sure yet whether "in ref" should be valid or "scope ref" should > be valid either. It doesn't seem to me that it should trigger an error. > > -Steve Issue 8121 - "scope ref" is perfectly OK https://issues.dlang.org/show_bug.cgi?id=8121 -- Marco
-vgc Info ok?
The following string[string] myarray = ["key":"value"]; string entry; entry = myarray["key"]; // => vgc: indexing an associative array may cause GC allocation Why is _accessing_ an assoc treated as indexing it?
Re: How to create a mutable array of strings?
On 5/17/15 5:15 AM, Dennis Ritchie wrote: This option is also a strange: char[][] s = ["foo".dup, "bar".dup]; s[1][1] = 't'; In my opinion, you need to add to D keyword mutable. It's annoying to have to dup each one. But, you do have a couple other possibilities: auto s = ["foo".dup, "bar".dup]; import std.algorithm : map; import std.array : array; auto s = map!(a => a.dup)(["foo", "bar"]).array; // this will needlessly allocate an array for the strings But really, a string is immutable. There's not a way around that. A string is the most basic level of array primitive, not even mutable arrays of non-char types have that, and it's an annoyance. From there, you have to build the data out of ROM into the heap. -Steve
Re: -vgc Info ok?
On Mon, 18 May 2015 14:30:42 +, Chris wrote: > The following > > string[string] myarray = ["key":"value"]; > string entry; > entry = myarray["key"]; // => vgc: indexing an associative array may > cause GC allocation > > Why is _accessing_ an assoc treated as indexing it? it can throw "out of range" error, which is `new`ed. signature.asc Description: PGP signature
Re: ICE?
On Sun, 17 May 2015 10:09:10 +, Daniel Kozak wrote: > On Sunday, 17 May 2015 at 09:25:33 UTC, Namespace wrote: >> Is this error an ICE? I think so, because I see the internal filename, >> but I'm not sure. >> >> Error: e2ir: cannot cast malloc(length * 8u) of type void* to type >> char[] > > I would say this is not an ICE just normal error message. anything including "e2ir" is definitely an ICE, i believe. it should be catched by frontend. signature.asc Description: PGP signature
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 10:24:25 UTC, Dennis Ritchie wrote: No, afraid not. Function capacity is not an analogue of fill-pointers! It's exactly the same. Lisp-programmer explains the usefulness of fill-pointers as follows: "Fill pointer "cuts" the tail of the vector. In D: .length "cuts" the tail of the vector. For example, vector elements 100, but if you set the fill pointer equal to 3, the length of the array (returned by length) will be equal to 3. The remaining elements are not visible. In D: vector elements 100, but if you set the .length equal to 3, the length of the array (returned by length) will be equal to 3. The remaining elements are not visible. .capacity tells you "real" size of the buffer while .length is like that fill pointer.
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote: Hi, In Common Lisp, there is such a thing as a fill-pointer (Example 5): http://www.tutorialspoint.com/lisp/lisp_arrays.htm Does D some equivalent? Data stored in the array is indicated by the array length property, use capacity to figure out extra available space: http://dlang.org/phobos/object.html#.capacity
Convert C array pointer to a D slice without data copy
I get the point to an array from a c function, the data size from another function. The data should be only readable at the D side, but I would like to use it as a D slice without copying the data. Is this possible ?
Re: The analogue of "fill-pointer" in D
On Monday, 18 May 2015 at 10:14:33 UTC, Kagamin wrote: On Monday, 18 May 2015 at 08:21:38 UTC, Dennis Ritchie wrote: Hi, In Common Lisp, there is such a thing as a fill-pointer (Example 5): http://www.tutorialspoint.com/lisp/lisp_arrays.htm Does D some equivalent? Data stored in the array is indicated by the array length property, use capacity to figure out extra available space: http://dlang.org/phobos/object.html#.capacity No, afraid not. Function capacity is not an analogue of fill-pointers! Lisp-programmer explains the usefulness of fill-pointers as follows: "Fill pointer "cuts" the tail of the vector. For example, vector elements 100, but if you set the fill pointer equal to 3, the length of the array (returned by length) will be equal to 3. The remaining elements are not visible. It seems to be nonsense. But this is nonsense, ideal for buffers. If the buffer is implemented as an array, then fill pointer just marks the boundary of the filled part of the buffer, and adding a buffer (moving away from the fill pointer-a) is carried out using the vector-push. Or a buffer can be filled with the format-a. If you work with the same buffer C, fill pointer simulates a pointer to the last completed item."
Re: Convert C array pointer to a D slice without data copy
On Monday, 18 May 2015 at 09:18:33 UTC, ParticlePeter wrote: I get the point to an array from a c function, the data size from another function. The data should be only readable at the D side, but I would like to use it as a D slice without copying the data. Is this possible ? char* dataPtr; size_t dataLen; auto data = dataPtr[0 .. dataLen]; This doesn't do any copying. BUT I am not sure what GC would be doing about it. After you use it, you might want to set `data` to null in case of a problem.
Re: control flow with a functional template ?
On Monday, 18 May 2015 at 08:46:36 UTC, John Colvin wrote:
On Monday, 18 May 2015 at 06:13:50 UTC, Baz wrote:
who's never had to do this:
---
if (comparison)
{
statement;
break;
}
---
ans then thought it's a pity to open/closes the braces just
for a
simple statement. Would it be possible to have a template to
simplify this to:
---
if (comparison)
Break!(expression);
---
or even at the language level:
---
if (comparison)
break(expression);
if (comparison)
continue(expression);
---
so far it looks like it's only possible using a string mixin,
which is a quite unelegant solution (because for example you
loose the IDE completion while writting the statement):
---
auto Break(string statement)
{
return format("{%s;break;}", statement);
}
// unelegant but works...
if (condition)
mixin("myVar = 8".Break);
if (condition)
mixin(q{myVar = 8}.Break);
---
Any other solution ?
Take a look at lazy function arguments if you really want this.
Personally I think you'll end up saving a small handful of
keystrokes (if any) at the expense of clarity.
Wait no, actually you do need mixins, I wasn't thinking. Unless
you make the if statement a function call / template...
Re: control flow with a functional template ?
On Monday, 18 May 2015 at 06:13:50 UTC, Baz wrote:
who's never had to do this:
---
if (comparison)
{
statement;
break;
}
---
ans then thought it's a pity to open/closes the braces just for
a
simple statement. Would it be possible to have a template to
simplify this to:
---
if (comparison)
Break!(expression);
---
or even at the language level:
---
if (comparison)
break(expression);
if (comparison)
continue(expression);
---
so far it looks like it's only possible using a string mixin,
which is a quite unelegant solution (because for example you
loose the IDE completion while writting the statement):
---
auto Break(string statement)
{
return format("{%s;break;}", statement);
}
// unelegant but works...
if (condition)
mixin("myVar = 8".Break);
if (condition)
mixin(q{myVar = 8}.Break);
---
Any other solution ?
Take a look at lazy function arguments if you really want this.
Personally I think you'll end up saving a small handful of
keystrokes (if any) at the expense of clarity.
The analogue of "fill-pointer" in D
Hi, In Common Lisp, there is such a thing as a fill-pointer (Example 5): http://www.tutorialspoint.com/lisp/lisp_arrays.htm Does D some equivalent?
Re: overloading evaluation (treating objects as functions)
On Sunday, 17 May 2015 at 18:58:32 UTC, Namespace wrote:
http://dlang.org/operatoroverloading.html#function-call
Like this:
module main;
import std.stdio;
class F
{
int opCall(int value)
{
return value * 2;
}
}
void main(string[] args)
{
auto f = new F();
writeln("The value of f at 7 is ", f(7));
}
Re: overloading evaluation (treating objects as functions)
Awesome!!
Thanks Gary and namespace (and obviously i gotta improve my
google-fu).
dan
On Sunday, 17 May 2015 at 19:40:10 UTC, Gary Willoughby wrote:
On Sunday, 17 May 2015 at 18:58:32 UTC, Namespace wrote:
http://dlang.org/operatoroverloading.html#function-call
Like this:
module main;
import std.stdio;
class F
{
int opCall(int value)
{
return value * 2;
}
}
void main(string[] args)
{
auto f = new F();
writeln("The value of f at 7 is ", f(7));
}
