parse json-string - operator overload error
Hey guys,
I'm trying to read a JSON-formated file. The parsing of the file seems to be
correct, but I always get the following error:
Error: no [] operator overload for type JSONValue.
For testing purposes, I also tried the code of
http://www.digitalmars.com/d/archives/digitalmars/D/std.json_API_improvement_
-_Request_for_code_review_117261.html#N117302 without success (same error).
My currently code looks like this:
import std.stdio : writeln;
import std.json;
import std.stream;
import std.conv;
void main(string[] args) {
File f = new File(test.json, FileMode.In);
string content = to!(string)(f.readString(f.available()));
JSONValue t = parseJSON(content);
writeln(t[test]);
f.close();
}
I hope anyone can help to find out what's wrong with the code above.
Re: Passing functions to functionals
On Tue, 30 Nov 2010 18:49:56 +0300, Dmitry Olshansky wrote:
On 30.11.2010 14:59, Lars T. Kyllingstad wrote:
In my library I have a lot of functionals (functions that take other
functions as parameters). Here is an example that shows the style I
use to define them:
// Example: Evaluate the function/delegate/functor f at x. auto
eval(F, X)(F f, X x) { return f(x); }
// Test
void main()
{
int add2(int i) { return i + 2; }
assert (eval(add2, 1) == 3);
}
In other words, the function is passed as a run-time parameter. I've
seen this (or similar) style used in Phobos, but there, I've also noted
that functions are sometimes passed as template alias parameters:
// Same as above, using template alias parameter. auto eval(alias
f, X)(X x) { return f(x); }
// Test
void main()
{
int add2(int i) { return i + 2; }
assert (eval!add2(1) == 3);
}
I'd be grateful if people would share their knowledge of the pros and
cons of each method. For instance, are there any situations where
template alias parameters don't work?
Thanks,
-Lars
alias parameters must be know/computable at compile time, quick example
on what you can't do:
import std.stdio;
auto eval(F, X)(F f, X x) { return f(x); } auto eval2(alias f,X)(X x){
return f(x); }
auto summator(int k){
int f(int val){
return k + val;
}
return f;
}
// Test
void main()
{
int add2(int i) { return i + 2; }
int traceAdd2(int i){
writeln(i, -- ,i+2);
return i+2;
}
int delegate(int) getAdd2(){
writeln(Getting add2);
return add2;
}
assert(eval(add2, 1) == 3);
assert(eval2!add2(1) == 3);
assert(eval(summator(2),1) == 3);
//Next one fails with
//Error: closures are not yet supported in CTFE //Error: cannot
evaluate summator(2) at compile time
//assert(eval2!(summator(2))(1) == 3);
assert(eval(traceAdd2,1) == 3);
assert(eval2!traceAdd2(1) == 3); //side effect in call is no
problem
assert(eval(getAdd2,1) == 3);
//Next one fails with
//Error: cannot evaluate writeln(Getting add2) at compile time
//Error: cannot evaluate getAdd2() at compile time
//assert(eval2!(getAdd2())(1) == 3);
}
That's a very good point, and pretty much settles it for me. I'll stay
away from alias parameters, then. Thanks!
-Lars
Why does 'string' alias immutable(char)[] and not immutable(char[]) ?
Well, nearly everything is in the title... I would intuitively opt for the second type if I had to define an immutable string type. Answers from various points of view (semantic, praticality, efficiency...) would be great if ever they may differ. denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Why does 'string' alias immutable(char)[] and not immutable(char[]) ?
On Wednesday 01 December 2010 03:17:48 spir wrote: Well, nearly everything is in the title... I would intuitively opt for the second type if I had to define an immutable string type. Answers from various points of view (semantic, praticality, efficiency...) would be great if ever they may differ. string str = hello; str ~ = world; That's wouldn't be possible if string were fully immutable. And since the fact that the elements of a string are immutable, passing a string to a function is guaranteed not to mess with the original, even if they append to the one passed in. So, making it fully immutable wouldn't really buy you anything anyway. - Jonathan M Davis
utf code unit sequence validity (non-)checking
Hello,
I just noted noted that D's builtin *string types do not behave the same way in
front of invalid code unit sequences. For instance:
void main () {
assert(hæ? == \x68\xc3\xa6\x3f);
// Note: removing \xa6 thus makes invalid utf8.
string s1 = \x68\xc3\x3f;
// == OK, accepted -- but write-ing indeed produces h�?.
dstring s4 = \x68\xc3\x3f;
// == compile-time Error: invalid UTF-8 sequence
}
I guess this is because, while converting from string to dstring, meaning while
decoding code units to code points, D is forced to check sequence validity. But
this is not needed, and not done, for utf8 string. Am I right on this?
If yes, isn't it risky to let utf8 (and wstrings?) unchecked? I mean, to have a
concrete safety difference with dstrings? I know there are utf checking
routines in the std lib, but for dstrings one does not need no call them
explicitely.
(Note that this checking is done at compile-time for source code literals.)
denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
2 little enigmas with is Unqual!
Hello,
1. Why isn't Unqual!(char) == char?
writeln( is( Unqual!(typeof('c')) == char ) ); // false
writeln( is( Unqual!(char) == char ) ); // false
writeln( is( char == char ) ); // true!
(dmd v2.049)
2. Why cannot one write assert(is(Unqual(t1) == t2))?
assert( is( char == char ) ); // OK
assert( is( Unqual!(char) != char ) ); // compile Error
assert( is( Unqual!(typeof('c')) != char ) ); // compile Error
(is() gets on my nerves ;-)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Why does 'string' alias immutable(char)[] and not immutable(char[]) ?
On Wed, 1 Dec 2010 03:25:24 -0800 Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday 01 December 2010 03:17:48 spir wrote: Well, nearly everything is in the title... I would intuitively opt for the second type if I had to define an immutable string type. Answers from various points of view (semantic, praticality, efficiency...) would be great if ever they may differ. string str = hello; str ~ = world; That's wouldn't be possible if string were fully immutable. This, I do not understand. I thought immutable applies to the value, not to the variable. At least, this is what I know from other languages using immutable; but it seems, then, that this term does not mean the same in D. Immutable, for me, mean no reference to the value can change it. Thus, for instance: immutable(char[]) s = abc; immutable(char[])* p = s; *p = def; // Error: *p is not mutable EDIT: All right, got it! I was caught once more by the fact that, for most types, in languages of the traditional imperative kind, a variable maps to a memory cell. Thus, immutability of the value also means unchange-ability of the variable. In other words: s = def; // Error: variable __trials__.main.s cannot modify immutable because there is no way to change or replace s's value without mutating the original one. If I change s, then *p will see it. Is this reasoning correct? (I was mislead because, in functional and dynamic languages from which I learnt the notion of immutability, elements are referenced, so that one can change a variable denoting an immutable value: it just silently points to another place in memory, but the original value never mutates. In such a language, changing s would not affect any other reference to the original value. Eg, python strings are immutable and referenced: s = abc ; t = s s = def print s,t # def abc ) And since the fact that the elements of a string are immutable, passing a string to a function is guaranteed not to mess with the original, even if they append to the one passed in. So, making it fully immutable wouldn't really buy you anything anyway. Yop. - Jonathan M Davis Thank you, Jonathan. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: 2 little enigmas with is Unqual!
spir Wrote:
Hello,
1. Why isn't Unqual!(char) == char?
writeln( is( Unqual!(typeof('c')) == char ) );// false
writeln( is( Unqual!(char) == char ) ); // false
writeln( is( char == char ) );// true!
(dmd v2.049)
Using GCD 4.3.5 ( more precisely on Linux/Debian )
writeln( is( Unqual!(typeof('c')) == char ) );
writeln( is( Unqual!(char) == char ) );
writeln( is( char == char ) );
returns
true
true
true
as expected
2. Why cannot one write assert(is(Unqual(t1) == t2))?
assert( is( char == char ) ); // OK
assert( is( Unqual!(char) != char ) );// compile Error
assert( is( Unqual!(typeof('c')) != char ) ); // compile Error
(is() gets on my nerves ;-)
not sure of that, but I think is is a compile time feature, hence you must
write
static assert( is( char == char ) ); // OK
static assert( is( Unqual!(char) == char ) ); // OK
static assert( is( Unqual!(typeof('c')) == char ) ); // Ok
hope this can help
Denis
-- -- -- -- -- -- --
vit esse estrany â£
spir.wikidot.com
C++ istream / ostream equivalent ?
Is there a canonical way to take into account a new type for I/O using the std
phobos library ?
To be clear I do not know how to translate something like this (in C++) in D :
#include iostream
class A {};
std::ostream operator(std::ostream out,const A a)
{
out \nscreen output routine here\n;
return out;
}
int main()
{
A a;
std::cout a;
}
Do I have to overload some writeln functions ?
any help is welcome :)
Re: 2 little enigmas with is() Unqual!
On Wed, 01 Dec 2010 10:03:57 -0500
vincent picaud vincent.pic...@laposte.net wrote:
spir Wrote:
Hello,
1. Why isn't Unqual!(char) == char?
writeln( is( Unqual!(typeof('c')) == char ) ); // false
writeln( is( Unqual!(char) == char ) ); // false
writeln( is( char == char ) ); // true!
(dmd v2.049)
Using GCD 4.3.5 ( more precisely on Linux/Debian )
writeln( is( Unqual!(typeof('c')) == char ) );
writeln( is( Unqual!(char) == char ) );
writeln( is( char == char ) );
returns
true
true
true
as expected
All right, I do not have the same results using dmd. Seems like abug, doesn't
it?
2. Why cannot one write assert(is(Unqual(t1) == t2))?
assert( is( char == char ) ); // OK
assert( is( Unqual!(char) != char ) ); // compile Error
assert( is( Unqual!(typeof('c')) != char ) ); // compile Error
(is() gets on my nerves ;-)
not sure of that, but I think is is a compile time feature, hence you must
write
static assert( is( char == char ) ); // OK
static assert( is( Unqual!(char) == char ) ); // OK
static assert( is( Unqual!(typeof('c')) == char ) );// Ok
Well, on dmd:
static assert( is( Unqual!(char) == char ) );
raises:
Error: static assert (is(Unqual!(char) == char)) is false
which is at least consistent with the result written above. But strangely, I
cannot reverse the predicate:
static assert( is( Unqual!(char) != char ) );
yields:
found '!=' when expecting ')'
Actually, i even cannot write:
static assert( is( char != dchar ) ); // same error
Is this normal? Doesn't is() allow != at all?
hope this can help
Yes, helps a lot, thank you Vincent.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: 2 little enigmas with is() Unqual!
spir Wrote:
On Wed, 01 Dec 2010 10:03:57 -0500
vincent picaud vincent.pic...@laposte.net wrote:
spir Wrote:
Hello,
1. Why isn't Unqual!(char) == char?
writeln( is( Unqual!(typeof('c')) == char ) );// false
writeln( is( Unqual!(char) == char ) ); // false
writeln( is( char == char ) );// true!
(dmd v2.049)
Using GCD 4.3.5 ( more precisely on Linux/Debian )
writeln( is( Unqual!(typeof('c')) == char ) );
writeln( is( Unqual!(char) == char ) );
writeln( is( char == char ) );
returns
true
true
true
as expected
All right, I do not have the same results using dmd. Seems like abug, doesn't
it?
Perhaps... I will check at home with dmd/windows, here I only gdc/linux
2. Why cannot one write assert(is(Unqual(t1) == t2))?
assert( is( char == char ) ); // OK
assert( is( Unqual!(char) != char ) );// compile Error
assert( is( Unqual!(typeof('c')) != char ) ); // compile Error
(is() gets on my nerves ;-)
not sure of that, but I think is is a compile time feature, hence you
must write
static assert( is( char == char ) ); // OK
static assert( is( Unqual!(char) == char ) ); // OK
static assert( is( Unqual!(typeof('c')) == char ) ); // Ok
Well, on dmd:
static assert( is( Unqual!(char) == char ) );
raises:
Error: static assert (is(Unqual!(char) == char)) is false
which is at least consistent with the result written above. But strangely, I
cannot reverse the predicate:
static assert( is( Unqual!(char) != char ) );
yields:
found '!=' when expecting ')'
Actually, i even cannot write:
static assert( is( char != dchar ) );// same error
Is this normal? Doesn't is() allow != at all?
I think it is the right reason, is() does not support !=, only ==
hope this can help
Yes, helps a lot, thank you Vincent.
Thank, I m a new comer here, :)
Denis
-- -- -- -- -- -- --
vit esse estrany â£
spir.wikidot.com
Re: C++ istream / ostream equivalent ?
Matthias Pleh Wrote:
Am 01.12.2010 16:51, schrieb vincent picaud:
Is there a canonical way to take into account a new type for I/O using the
std phobos library ?
To be clear I do not know how to translate something like this (in C++) in
D :
#includeiostream
class A {};
std::ostream operator(std::ostream out,const A a)
{
out \nscreen output routine here\n;
return out;
}
int main()
{
A a;
std::cout a;
}
Do I have to overload some writeln functions ?
any help is welcome :)
I would make it this way:
module test;
import std.stdio;
class A{}
class B{ string toString() {return screen output routine here;}}
int main(string[] args)
{
A a=new A;
B b=new B;
writeln(a.toString());
writeln(b.toString());
return 0;
}
output:
test.A
screen output routine here
Base-class of all classes is object with have a default-toString()
method, which gives the module.classname.
So you can overwrite this method.
Thank you for your reply and yes that works :)
Now i m facing with the following problem, what is the trick for input stream ?
( something like
std::istream operator(std::istream in,A a)
{
// A.someData in;
return in;
}
in C++ )
I m thinking of the situation when we want to load some data from a file.
The toString() trick is okay for saving the object... but how to load it back
(something like fromString(char[]) would do the job but it does not exist in
Object) ?
Anyway thank you, you solved half of my problem :)
Re: C++ istream / ostream equivalent ?
On 01.12.2010 20:11, Matthias Pleh wrote:
Am 01.12.2010 16:51, schrieb vincent picaud:
Is there a canonical way to take into account a new type for I/O
using the std phobos library ?
To be clear I do not know how to translate something like this (in
C++) in D :
#includeiostream
class A {};
std::ostream operator(std::ostream out,const A a)
{
out \nscreen output routine here\n;
return out;
}
int main()
{
A a;
std::cout a;
}
Do I have to overload some writeln functions ?
any help is welcome :)
I would make it this way:
module test;
import std.stdio;
class A{}
class B{ string toString() {return screen output routine here;}}
int main(string[] args)
{
A a=new A;
B b=new B;
writeln(a.toString());
writeln(b.toString());
Or even more implicit version, since writeln and the likes recognize
toString:
writeln(a);
writeln(b);
return 0;
}
output:
test.A
screen output routine here
Base-class of all classes is object with have a default-toString()
method, which gives the module.classname.
So you can overwrite this method.
Well there is a relatively new proposal which aims to replace toString
with more eficient and flexible function (and was generally accepted):
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
--
Dmitry Olshansky
Re: Why does 'string' alias immutable(char)[] and not immutable(char[]) ?
This, I do not understand. I thought immutable applies to the value, not to the variable. You need to read from right to left. immutable(char)[] is a mutable array of immutable chars. immutable(char[]) is an immutable array of immutable chars. Note the transitivity.
Re: C++ istream / ostream equivalent ?
Matthias Pleh wrote:
class B{ string toString() {return screen output routine here;}}
Isn't the 'override' keyword required? (Perhaps required only in D2?)
I find string.format very helpful in toString() member functions.
Finally, I still don't know whether the 'const'ness of the member
function is required, allowed, or completely wrong. :)
import std.string;
class A
{
override string toString() const
{
return format(My %s formatted string: %s, lovely, 42);
}
}
Ali
Re: C++ istream / ostream equivalent ?
Thank you for your reply and yes that works :)
Now i m facing with the following problem, what is the trick for input stream ?
( something like
std::istream operator(std::istream in,A a)
{
// A.someData in;
return in;
}
in C++ )
I m thinking of the situation when we want to load some data from a file.
The toString() trick is okay for saving the object... but how to load it back
(something like fromString(char[]) would do the job but it does not exist in
Object) ?
Anyway thank you, you solved half of my problem :)
Ther are many posibilities, depending on your further needs! Just have a
look at the online dokumentation:
http://www.digitalmars.com/d/2.0/phobos/phobos.html
But my first try would be such ..
(note: I've leaved out error-handling ...)
module test;
import std.stdio;
import std.file;
class A
{
void writeToFile() { std.file.write(sample.txt,someData); }
void readFromFile() { someData=cast(string)read(sample.txt); }
void clear(){ someData=n/A\n; }
string toString() { return someData; }
private:
string someData=Just some data.
With anohter line of date.
Even more data.!;
}
int main(string[] args)
{
A a=new A;
a.writeToFile();
a.clear();
writeln(a);
a.readFromFile();
writeln(a);
return 0;
}
Re: C++ istream / ostream equivalent ?
Or even more implicit version, since writeln and the likes recognize toString: writeln(a); writeln(b); [...] Well there is a relatively new proposal which aims to replace toString with more eficient and flexible function (and was generally accepted): http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 thanks I wasn't aware of that. :)
Re: C++ istream / ostream equivalent ?
On Wednesday, December 01, 2010 11:40:11 Ali Çehreli wrote:
Matthias Pleh wrote:
class B{ string toString() {return screen output routine here;}}
Isn't the 'override' keyword required? (Perhaps required only in D2?)
I find string.format very helpful in toString() member functions.
Finally, I still don't know whether the 'const'ness of the member
function is required, allowed, or completely wrong. :)
import std.string;
class A
{
override string toString() const
{
return format(My %s formatted string: %s, lovely, 42);
}
}
Ali
override is required if you compile with -w. If you don't use -w, the compiler
won't complain, but I'm not sure that it actually overrides the function in
that
case. So, yes override should be there.
Object's toString() is not currently const-correct. It isn't const. So,
currently, when overriding toString(), you don't have to make it const.
However,
you _can_ make it const if you want to (and honestly, Object's toString()
_should_ be const; it's just among the changes that need to be made to Object
to
make it properly const-correct: http://is.gd/i3KUJ ). Making a non-const
function const when overriding it is adding guarantees, not loosening them, so
it works.
Be forewarned, however, that because of bug http://is.gd/i3Lc2 ), _struct_'s
toString() cannot be const (or at least, you need a non-const version in
addition to a const one if you have a const one). Classes don't have that
problem though.
- Jonathan M Davis
Re: C++ istream / ostream equivalent ?
Am 01.12.2010 20:59, schrieb Jonathan M Davis: override is required if you compile with -w. If you don't use -w, the compiler won't complain, but I'm not sure that it actually overrides the function in that case. So, yes override should be there. I've just tried it out. It is really overridden, even if the override keyword is missing. But the cool thing with override is, when you use it, but mistpyed the methodname or someone else changed one of the methods, the compiler know, you wanted to override something, but there isn't anymore to override! So yes, you're right, override should be used!!
Re: C++ istream / ostream equivalent ?
Jonathan M Davis: override is required if you compile with -w. If you don't use -w, the compiler won't complain, but I'm not sure that it actually overrides the function in that case. So, yes override should be there. override will become obligatory, Andrei and Walter agree with this change, so always (when possible) use it. See also bug 3836. Bye, bearophile
