jsoncpp-devel — Mailing list to discuss development and usage of json-cpp.

[Jsoncpp-devel] Writing UTF-8 json

[J <pro...@gm...>]

Hi,

I am having a problem writing a json stream as UTF8 on Windows.

The file I am reading is encoded as UTF8, reading the file works as expected:

By reading a tag as a string and passing it to MultiByteToWideChar, I
am able to reconstitute the correct Unicode output.

However, if I take the stream (which is already in UTF8) and simply
try to write it back out, it results in an ASCII or ANSI (not sure)
encoded file that contains lots of string entries with things like
\u00f1 in them.

The following is an abrdged example.

        Json::StreamWriterBuilder Writer;
        stream.write( root.toStyledString().c_str(),
root.toStyledString().size() );

Any help is appreciated.
Thank you

[Jsoncpp-devel] How to remove an element from arrayValue object

[Vivekkumar G. <viv...@hc...>]

Hi,

I want to know how can I remove/delete an element from arrayValue JSON object. I found no API/direct method to do this in Json::Value class.

Thanks,
Vivek


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------

[Jsoncpp-devel] Parsing encoded binary data

[Abhishek N. <ab...@ym...>]

Hi all,
I am trying to parse a json string which contains some binary data encoded as '\U0xx' format. JsonCpp is stripping out the whole content and just returns "null". Is there any way to get it as a array of bytes instead?
Sample json text:
{"bytes":"\U0008\U00bd\U00e4\U00f6\U00af\U0005\U0010\U00fa\U00c2\U0097\U00b3\U0005\U001a\U0015\U0008\U00ff\U00ff\U00ff\U00ff\U00ff\U00ff\U00ff\U00ff\U00ff\U0001\U0010\U0000\U0018\U0001\U0020\U0001\U0028\U0000\U0030\U0000\U0032\U0007\U0008\U00f9\U00c4\U00e8\U0009\U0018\U0001\U0032\U0007\U0008\U00b4\U00f0\U00e5\U0009\U0018\U0001"}
When I parse it and print it back, I get this:
{"bytes":null}
Regards,Abhi.

[Jsoncpp-devel] how to install question

[Leandro <ing...@gm...>]

Hello guys , Im trying to get the jsoncpp library working in my centos box
Can anyone point me some documentation about how to install the library, 
include in my code and compile ?
So far I founded some examples abut the code but not how to install the 
library and then compile.
Regards.
Leandro.

Re: [Jsoncpp-devel] Getting an object's name

[J (Jean-C. Gervais) <pro...@gm...>]

On Fri, 2015-05-15 at 14:45 -0600, David Sankel wrote:
> On 05/15/2015 11:47 AM, J (Jean-Claude Gervais) wrote:
> >
> > I have a Json::Value which contains an object like
> >
> > "SOMEOBJECT":{
> >
> >      "OTHEROBJECT": {
> >                 "VAL1": "string value a",
> >                 "VAL2": 25,
> >                 "VAL3": 10,
> >                 "VAL4": "string value w",
> >                 "VAL5": 1,
> >                 "VAL6": "string value x"
> >      }
> >
> > }
> >
> > Given the Json::Value, I know how to obtain the names of its internal
> > objects: getMemberNames
> >
> > But how can I obtain the name of the object itself (SOMEOBJECT) ?
> 
> In JSON, objects don't have names.
> 
> { ... } is an object
> "asdf":... is an entry within an object.
> 

David, thank you for taking the time to reply.
I thought surely the object would know what its label is.
The code that obtained the Json::Value did it by asking for it by its
name, I assumed this bit of data would be copied.

Thanks

Re: [Jsoncpp-devel] Getting an object's name

[David S. <da...@st...>]

On 05/15/2015 11:47 AM, J (Jean-Claude Gervais) wrote:
> Hi!
>
> Newbie question:
>
> I have a Json::Value which contains an object like
>
> "SOMEOBJECT":{
>
>      "OTHEROBJECT": {
>                 "VAL1": "string value a",
>                 "VAL2": 25,
>                 "VAL3": 10,
>                 "VAL4": "string value w",
>                 "VAL5": 1,
>                 "VAL6": "string value x"
>      }
>
> }
>
> Given the Json::Value, I know how to obtain the names of its internal
> objects: getMemberNames
>
> But how can I obtain the name of the object itself (SOMEOBJECT) ?

In JSON, objects don't have names.

{ ... } is an object
"asdf":... is an entry within an object.

-- David


-- 
David Sankel <da...@st...>
Stellar Science Ltd Co - Stellar Scientific Software Solutions

[Jsoncpp-devel] Getting an object's name

[J (Jean-C. Gervais) <pro...@gm...>]

Hi!

Newbie question:

I have a Json::Value which contains an object like

"SOMEOBJECT":{

    "OTHEROBJECT": {
               "VAL1": "string value a",
               "VAL2": 25,
               "VAL3": 10,
               "VAL4": "string value w",
               "VAL5": 1,
               "VAL6": "string value x"
    }

}

Given the Json::Value, I know how to obtain the names of its internal
objects: getMemberNames

But how can I obtain the name of the object itself (SOMEOBJECT) ?

Thanks

[Jsoncpp-devel] [PATCH] Fix to minor cmake issue

[David S. <da...@st...>]

The attached patch fixes a minor issue where the 'INCLUDE_DIRECTORIES' 
call uses 'CMAKE_SOURCE_DIR' instead of 'CMAKE_CURRENT_SOURCE_DIR'. This 
fix allows one to use the cmake build as part of a larger cmake build 
through the use of 'add_subdirectory'.

Thanks,

David Sankel

-- 
David Sankel <da...@st...>
Stellar Science Ltd Co - Stellar Scientific Software Solutions

[Jsoncpp-devel] escaped unicode output

[Ondrej T. <kon...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

is there some choice, how to generate json output with right escaped
unicode output like json in python.

Here is my code:

#include <stdio.h>
#include <json/writer.h>
#include <json/reader.h>
#include <json/value.h>

int main () {
    Json::FastWriter    writer;
    Json::Reader        reader;
    Json::Value         root;

    const char * raw = "{\"Age\":34,\"Name\":\"Ond\\u0159ej T\\u016fma\"}";
    
    if ( !reader.parse(raw, root)) { fprintf(stderr,
        "Json::Failed to parse data: %s",
        reader.getFormatedErrorMessages().c_str());
        return 1;
    }

    printf("raw : %s\n", raw);
    printf("root: %s\n", writer.write(root).c_str());

    return 0;
}  

and here is my bad output:

raw : {"Age":34,"Name":"Ond\u0159ej T\u016fma"}
root: {"Age":34,"Name":"Ondřej Tůma"}

How can i generate right output like in first line ?

Thanks a lot!

- -- 
Ondřej Tůma <mc...@ze...>
www: http://ipv6.mcbig.cz   jabber: mc...@ja...   twitter: mcbig_cz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlNFHegACgkQBmNIPxOnb/KrPgCdHRkFw85o68RC5HLbhTtqkISt
kPIAn0GZJG9NamNyv9xG7Qkt/H4NXHo8
=no8F
-----END PGP SIGNATURE-----

[Jsoncpp-devel] FW: Powerful Json::Path

[王远天 <xia...@ho...>]

From: xia...@ho...
To: jso...@li...
Subject: Powerful Json::Path
Date: Tue, 1 Apr 2014 09:54:45 +0000




Json::Value v;v["a"]["b"][0u] = 1;
Json::Path p("a.b.c");const Json::Value &ref = p.resolve(v);// assert
The above code with course an assert when call "resolve".That is because "resolve" do not process except conditions.
const Value &Path::resolve( const Value &root ) const{   const Value *node = &root;   for ( Args::const_iterator it = args_.begin(); it != args_.end(); ++it )   {      const PathArgument &arg = *it;      if ( arg.kind_ == PathArgument::kindIndex )      {         if ( !node->isArray()  ||  node->isValidIndex( arg.index_ ) )         {            // Error: unable to resolve path (array value expected at position...         }         node = &((*node)[arg.index_]);      }      else if ( arg.kind_ == PathArgument::kindKey )      {         if ( !node->isObject() )         {            // Error: unable to resolve path (object value expected at position...)         }         node = &((*node)[arg.key_]);         if ( node == &Value::null )         {            // Error: unable to resolve path (object has no member named '' at position...)         }      }   }   return *node;}

Users call "resolve" means they must take the risk of fatal error.so "Path" is useless. But Json::Path should be more powerfull.Suppose we have a function named "bad" in class Value, which specified the value itself is bad. User shall check it like below:
Json::Value v;v["a"]["b"][0u] = 1;
Json::Path p("a.b.c");const Json::Value &ref = p.resolve(v);// will not assert
if (ref.bad()){    std::cout << "ref is bad." << std::endl;    ref = 2; // any operation to bad value will cause assert}
all we need to do is two step:1,declare a static member in Json::Value:	static Value bad;	bool bad() const	{	  return &bad == this;	}2,replace each "// Error: *" line to 	return Value::bad;

further morewe could use Json::Path to resolve the exact type value, Like this:
Json::Value v;v["a"]["b"][0u] = 1;
Json::Path p("a.b[0]");Json::Integer i = p.resolveInt(v);
if (i.bad()){	//do something}
Wish this features will be added to new version. 		 	   		   		 	   		  

[Jsoncpp-devel] Get unconverted string value of double?

[Hobin Y. <hob...@gm...>]

Is there a way to get a double value as an unmodified string? I have double
values that I want to parse without losing any precision.

Json::Value v;
double longi = v.asDouble();
string longi = v.asUnconvertedString();  // something like this?

Hobin

Re: [Jsoncpp-devel] g++ version problem??

[Joakim H. <jo...@st...>]

Thank you for the suggestion;

I must admit I gave up on Jconcpp and instead tried the very simple cJSON which worked for me.

Joakim

From: Baptiste Lepilleur [mailto:bap...@gm...]
Sent: 5. august 2013 13:59
To: Joakim Hove
Cc: jso...@li...
Subject: Re: [Jsoncpp-devel] g++ version problem??

I'm also in a corporate environment with an old RedHat and stuck with gcc 4.1.2.  I do not have this issue, but I'm using our own project build system to build jsoncpp (trunk) amalgamated sources.

The crash stack has the smell of incompatible compiler settings, but I don't know enough to about gcc to say for sure.

I would recommend that you try using the amalgamated sources and compile with your own build system to confirm to origin of the issue.

Baptiste.

2013/7/28 Joakim Hove <jo...@st...<mailto:jo...@st...>>
Hello,

I have downloaded jsoncpp and successfully built it; I also issued the command “scons platform=linux-gcc check” to run the tests – the all passed.

I then created my own program to actually test this; the program compiles and links fine – but it goes down witn SIGSEGV when running. My program is

#include <json/json.h>

void parseJson() {
    Json::Reader reader;
}

int main(int argc , char ** argv) {
    parseJson();
    exit(0);
}

I.e. it is very simple stuff. When I try putting the Json::Reader instance in the boyd of main{…} it seems to work.  A backtrace from gdb is inlined below:

#0  0x0000003a560b7672 in __gnu_cxx::__exchange_and_add () from /usr/lib64/libstdc++.so.6
#1  0x0000000000403313 in std::string::_Rep::_M_dispose (this=0xffffffffffffffe9, __a=@0x7fff7fb14957)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:232
#2  0x0000000000403360 in ~basic_string (this=0x7fff7fb14ab0)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:478
#3  0x00000000004039fe in ~Reader (this=0x7fff7fb149b0) at /private/joaho/Parser/opm-parser/external/json/json-cpp/include/json/reader.h:23
#4  0x0000000000402aba in parseJson () at /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:50
#5  0x0000000000402ad5 in main (argc=1, argv=0x7fff7fb14bc8)
    at /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:55

As you can see I have a very old version of g++ (4.1.2). I am in a corporate environment and it is quite painful to get a newer version – do you think this can be the problem?

Regards Joakim



-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Jsoncpp-devel mailing list
Jso...@li...<mailto:Jso...@li...>
https://lists.sourceforge.net/lists/listinfo/jsoncpp-devel


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you

Re: [Jsoncpp-devel] g++ version problem??

[Baptiste L. <bap...@gm...>]

I'm also in a corporate environment with an old RedHat and stuck with gcc
4.1.2.  I do not have this issue, but I'm using our own project build
system to build jsoncpp (trunk) amalgamated sources.

The crash stack has the smell of incompatible compiler settings, but I
don't know enough to about gcc to say for sure.

I would recommend that you try using the amalgamated sources and compile
with your own build system to confirm to origin of the issue.

Baptiste.


2013/7/28 Joakim Hove <jo...@st...>

>  Hello,****
>
> ** **
>
> I have downloaded jsoncpp and successfully built it; I also issued the
> command “scons platform=linux-gcc check” to run the tests – the all passed.
> ****
>
> ** **
>
> I then created my own program to actually test this; the program compiles
> and links fine – but it goes down witn SIGSEGV when running. My program is
> ****
>
> ** **
>
> #include <json/json.h>****
>
> ** **
>
> void parseJson() {****
>
>     Json::Reader reader;****
>
> }****
>
> ** **
>
> int main(int argc , char ** argv) {****
>
>     parseJson();****
>
>     exit(0);****
>
> }****
>
> ** **
>
> I.e. it is very simple stuff. When I try putting the Json::Reader instance
> in the boyd of main{…} it seems to work.  A backtrace from gdb is inlined
> below:****
>
> ** **
>
> #0  0x0000003a560b7672 in __gnu_cxx::__exchange_and_add () from
> /usr/lib64/libstdc++.so.6****
>
> #1  0x0000000000403313 in std::string::_Rep::_M_dispose
> (this=0xffffffffffffffe9, __a=@0x7fff7fb14957)****
>
>     at
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:232
> ****
>
> #2  0x0000000000403360 in ~basic_string (this=0x7fff7fb14ab0)****
>
>     at
> /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:478
> ****
>
> #3  0x00000000004039fe in ~Reader (this=0x7fff7fb149b0) at
> /private/joaho/Parser/opm-parser/external/json/json-cpp/include/json/reader.h:23
> ****
>
> #4  0x0000000000402aba in parseJson () at
> /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:50
> ****
>
> #5  0x0000000000402ad5 in main (argc=1, argv=0x7fff7fb14bc8)****
>
>     at
> /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:55
> ****
>
> ** **
>
> As you can see I have a very old version of g++ (4.1.2). I am in a
> corporate environment and it is quite painful to get a newer version – do
> you think this can be the problem?****
>
> ** **
>
> Regards Joakim****
>
> ** **
>
> ** **
>
> -------------------------------------------------------------------
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination of the
> information or copying of this message is prohibited. If you are not the
> addressee, please notify the sender immediately by return e-mail and delete
> this message.
> Thank you
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Jsoncpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsoncpp-devel
>
>

Re: [Jsoncpp-devel] g++ version problem??

[Stephan B. <sg...@go...>]

On Sun, Jul 28, 2013 at 8:01 PM, Joakim Hove <jo...@st...> wrote:

>  As you can see I have a very old version of g++ (4.1.2). I am in a
> corporate environment and it is quite painful to get a newer version – do
> you think this can be the problem?
>

i don't know if this will help, but a quick google reveals several people
complaining of buggy gcc 4.1 behaviours at specific optimization levels.
Maybe try with, e.g. -O0 and -O2?

http://de.comp.lang.c.narkive.com/dl6LsJPL/ot-gcc-4-1-1-buggy-optimierungsstufe-3

that thread has a bit about "the optimizing away of a function which
provably has no side effect":

'Das "wegoptimieren von Funktionen, die gemaess ihrer Spezifikation keine
Nebenwirkungen haben" ist kein Fehler.'

(sorry, didn't find a decent english one.)

which might be what's happening to you? That shouldn't cause a segfault,
but it might be related.

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal

[Jsoncpp-devel] g++ version problem??

[Joakim H. <jo...@st...>]

Hello,

I have downloaded jsoncpp and successfully built it; I also issued the command "scons platform=linux-gcc check" to run the tests - the all passed.

I then created my own program to actually test this; the program compiles and links fine - but it goes down witn SIGSEGV when running. My program is

#include <json/json.h>

void parseJson() {
    Json::Reader reader;
}

int main(int argc , char ** argv) {
    parseJson();
    exit(0);
}

I.e. it is very simple stuff. When I try putting the Json::Reader instance in the boyd of main{...} it seems to work.  A backtrace from gdb is inlined below:

#0  0x0000003a560b7672 in __gnu_cxx::__exchange_and_add () from /usr/lib64/libstdc++.so.6
#1  0x0000000000403313 in std::string::_Rep::_M_dispose (this=0xffffffffffffffe9, __a=@0x7fff7fb14957)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:232
#2  0x0000000000403360 in ~basic_string (this=0x7fff7fb14ab0)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:478
#3  0x00000000004039fe in ~Reader (this=0x7fff7fb149b0) at /private/joaho/Parser/opm-parser/external/json/json-cpp/include/json/reader.h:23
#4  0x0000000000402aba in parseJson () at /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:50
#5  0x0000000000402ad5 in main (argc=1, argv=0x7fff7fb14bc8)
    at /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:55

As you can see I have a very old version of g++ (4.1.2). I am in a corporate environment and it is quite painful to get a newer version - do you think this can be the problem?

Regards Joakim



-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you

[Jsoncpp-devel] Fwd: SourceForge Project Upgrade - Code Repo Complete

[Baptiste L. <bap...@gm...>]

FY,. Project migration completed.

Repository access is still possible through HTTPS:
https://svn.code.sf.net/p/jsoncpp/code/trunk/jsoncpp

(see code tab for all access mode of project's repository)

Baptiste.

---------- Forwarded message ----------
From: SourceForge.net <nor...@in...>
Date: 2013/4/22
Subject: SourceForge Project Upgrade - Code Repo Complete
To: no...@in...


Your code repository in upgraded project jsoncpp is now ready for use.

Old repository url: http://jsoncpp.svn.sourceforge.net/svnroot/jsoncpp

New repository checkout command: svn checkout --username=blep svn+ssh://
bl...@sv.../p/jsoncpp/code/ jsoncpp-code

You should do a checkout using the new repository location.  The old
repository is read-only now.

For more detailed instructions on migrating to your new repo, please see
https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/

[Jsoncpp-devel] Fwd: SourceForge project upgrades start April 22

[Baptiste L. <bap...@gm...>]

FYI, sourceforge plan to upgrade project to their new platform.

I already tested on another projects and it seems to be harmless.

According to documentation, main will probably be that URL used to access
the subversion repository changes.

I plan to trigger the migration on 2013/04/16.

Baptiste.

---------- Forwarded message ----------
From: SourceForge.net Team <no...@so...>
Date: 2013/4/5
Subject: SourceForge project upgrades start April 22
To: bap...@gm...


Dear SourceForge project member,

As you're no doubt already aware, we're in the process of upgrading
projects to our new developer platform. The new platform is named Allura,
and is in incubation at the Apache Software Foundation
(http://incubator.apache.org/allura/).

In recent weeks, we've been upgrading projects that have been inactive for
a while. Now, it's time to start upgrading everyone else. As you can no
doubt understand, we're anxious to complete this process so we can spend
less time maintaining the old platform, and more time improving the new
one. However, we also want to be sure that you have plenty of time to check
out the new platform and have your concerns, if any, addressed.

We're going to start upgrading active projects starting on Monday, April
22, starting with the longest-inactive and moving forward. Since each
upgrade takes a different amount of time, depending on the size of the
repositories, mailing list archives, and so on, we can't tell for sure when
we'll get to your project.

If you're ready to go ahead and upgrade your project now, you can do that
at http://sf.net/p/upgrade/

If you have a specific concern about the upgrade, or need to delay the
upgrade of your project, due to a release or other project activity, please
get in touch NOW, at com...@so... so that we can work
something out.

--
SourceForge Community Team
com...@so...
http://sourceforge.net/

[Jsoncpp-devel] please support unsigned long and long variable !

[t. <tan...@qq...>]

please help me !

Re: [Jsoncpp-devel] Patch adding CMakeFiles: cross-compilation & integration in CMake project

[Damien B. <dam...@le...>]

Hi Francis Bolduc,

I agree with the fact that it's integrable in any way with any build 
system because of the simplicity and portability of the library, it's 
even because of that that I was able to write easily the CMakeLists :).

The fact that it always works with any compiler is why I think CMake is 
a good choice, because CMake just want to know which compiler to use and 
search for the libs itself. There isn't any platform condition in the 
CMakeLists I wrote and the one I write generally, I prefer to abstract 
that in the code, if really needed, but I come across such case not so 
often.

I think the advantages of CMake comes when you are not tied to any 
compiler, I'm in this case I have to build same projects on windows with 
MinGW & MSVC following for which components it goes and on linux with 
g++ and for the different embedded platforms.

CMake is great in this way that it can from one configuration generates 
either Unix Makefiles, eclipse projects, Visual Studio projects, MinGW 
makefiles and the list is longer. :) I'm usually developing on Linux 
with Vim and the Unix Makefiles CMake generates, but I have other people 
in the team using eclipse and when I go on windows I just eventually 
recompile and make some fix directly with gvim and the MinGW makefiles 
or with MSVC with Visual Studio.

Additionnally there is an important point that I find necessary: finding 
dependent libraries, because when you build complex systems or whole OS 
with multiple components developed separately, like in my case, you 
cannot have all the libs in your project, you rather install them all in 
an install prefix which plays the role of sysroot and which gathers all 
the produced binaries and headers. That's why the CMake find_package is 
highly needed, to let the makefile tell if it found the library or not. 
It makes it easier also for other peoples to recompile later by 
retrieving the dependencies, instead of just getting a linker error that 
most of the beginners don't understand.

> And
> for those of us who know what we're doing, we don't even need a build
> system for working with jsoncpp.
That's right, because we can recompile it without too much work but in 
this case we still need to write our own makefiles. So I think that one 
flexible build system is needed, if the lib already ships with a 
configure script or better with CMake files it makes it recompilable 
without any additional work for any platform : the library user just has 
to type : "mkdir build && cd build && cmake .. && make -j3" and because 
CMake search for the dependencies and so on, we can simply integrates it 
in a complex build system and in a flexible way.

It's also easier to maintain, you don't have to adapt your project build 
system if the lib has to be compiled another way due to some new 
version, you simply tell it to be built, and eventually pass some 
compiler flags if you are not happy with the default ones :). (e.g. Our 
build server is configured to pass to all libraries makefiles the -Wall 
-Werror for linux)

And embedded build systems like yocto or ptxdist automagically makes the 
command for you, there is only the need to tell : "hey I want json-cpp 
0.6.0 on the produced linux system, do it for arm and ppc please", it 
will simply tell then to CMake where to find the compiler and what 
install prefix to use and everything will be done.

If you don't already have CMake files in the project or an autoreconf 
script (which are less portable than CMake, needs MSYS on windows which 
isn't cool for MSVC) then you have to write it, and I don't think a 
library user should bother about that, it should be able to integrates 
it in it's build system like he wants to, and that's why I find the 
flexibility of CMake a great choice. :) But anything could be great if 
it is flexible and accepts any platforms and works on any platforms, I 
personally only know CMake, autoreconf and scons.

Thank you for your reaction and explanations on this point :)
Cheers,
--
daminetreg
alias Damien Buhl

On 05/17/2012 02:41 AM, Francis Bolduc wrote:
> The good thing about jsoncpp is that there's almost no OS-dependent
> bits and it has only a few files. And it gets even better with the
> nice Python script that packages it up in even fewer files. This makes
> it a marvel to work with compared to most other 3rdparty library I
> have to deal with.
>
> So, because of that, I don't really feel the need to use the build
> system that comes with it. In fact, I think of it more as a tutorial
> than an official way of building jsoncpp. The build system could even
> be removed entirely from the repository and I would not even notice
> because I added the jsoncpp to my own SCons build system that I use
> for all my projects.
>
> jsoncpp just always works, whatever compiler I use, or whatever
> compiler flags I throw at it... and I need to support multiple version
> of GCC on both Linux and MacOS as well as 3 versions of MSVC. Shared
> libraries, static libraries, optimizations, instrumentation... you
> name it, I tried. Seriously, it just works flawlessly every time.
> Kudos to the developers. This is real portable C++.
>
> But then, I also realize that there are newcomers to software
> engineering that don't know anything about build systems and are tied
> to a specific IDE (like Microsoft Visual Studio users for example).
> For those people, I think CMake is a good choice, because it will
> generate some IDE-specific projects that can be used right away. And
> for those of us who know what we're doing, we don't even need a build
> system for working with jsoncpp.
>
> On Wed, May 16, 2012 at 6:27 PM, Damien Buhl<dam...@le...>  wrote:
>> Hello dear json_cpp developers,
>>
>> I worked recently with json-rpc-cpp based on json_cpp and I wrote
>> CMakeFile support for both. I wanted to provide my small contribution to
>> this nice library by sending you this patch.
>>
>> I was wondering if it could be integrated in the mainline or if you want
>> to keep it as a patch aside, but I have the feeling that it should be
>> mainline, because CMake is really one of the best choice for cross
>> compilation and recompilation on any platform. It has an advantage over
>> scons in the fact that cross compilation is generically and uniformly
>> supported. This makes any CMake project cross compilable seamlessly for
>> any platform without any specificf platform configuration in the
>> makefile other than a cross cmake toolchain file provided by the user or
>> by the toolchain itself.
>>
>> However I don't think it shoud replace scons, because certainly many
>> project have based their integration of your project with it. I just
>> think it could come additionally to ease building and integration for
>> CMake based projects. Especially for embedded and multiplatform projects
>> I think (e.g. I use it in a ptxdist and a yocto project for cross
>> compiling for ARM Cortex A8, PPC, Windows 7 and Linux i386, this is for
>> building automation softwares and devices).
>>
>> I added the patch on sourcefore at this address :
>> https://sourceforge.net/tracker/?func=detail&atid=758828&aid=3527408&group_id=144446
>>
>> Cheers,
>> --
>> daminetreg
>> alias Damien Buhl
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Jsoncpp-devel mailing list
>> Jso...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsoncpp-devel
>
>

Re: [Jsoncpp-devel] Patch adding CMakeFiles: cross-compilation & integration in CMake project

[Francis B. <fra...@cm...>]

The good thing about jsoncpp is that there's almost no OS-dependent
bits and it has only a few files. And it gets even better with the
nice Python script that packages it up in even fewer files. This makes
it a marvel to work with compared to most other 3rdparty library I
have to deal with.

So, because of that, I don't really feel the need to use the build
system that comes with it. In fact, I think of it more as a tutorial
than an official way of building jsoncpp. The build system could even
be removed entirely from the repository and I would not even notice
because I added the jsoncpp to my own SCons build system that I use
for all my projects.

jsoncpp just always works, whatever compiler I use, or whatever
compiler flags I throw at it... and I need to support multiple version
of GCC on both Linux and MacOS as well as 3 versions of MSVC. Shared
libraries, static libraries, optimizations, instrumentation... you
name it, I tried. Seriously, it just works flawlessly every time.
Kudos to the developers. This is real portable C++.

But then, I also realize that there are newcomers to software
engineering that don't know anything about build systems and are tied
to a specific IDE (like Microsoft Visual Studio users for example).
For those people, I think CMake is a good choice, because it will
generate some IDE-specific projects that can be used right away. And
for those of us who know what we're doing, we don't even need a build
system for working with jsoncpp.

On Wed, May 16, 2012 at 6:27 PM, Damien Buhl <dam...@le...> wrote:
> Hello dear json_cpp developers,
>
> I worked recently with json-rpc-cpp based on json_cpp and I wrote
> CMakeFile support for both. I wanted to provide my small contribution to
> this nice library by sending you this patch.
>
> I was wondering if it could be integrated in the mainline or if you want
> to keep it as a patch aside, but I have the feeling that it should be
> mainline, because CMake is really one of the best choice for cross
> compilation and recompilation on any platform. It has an advantage over
> scons in the fact that cross compilation is generically and uniformly
> supported. This makes any CMake project cross compilable seamlessly for
> any platform without any specificf platform configuration in the
> makefile other than a cross cmake toolchain file provided by the user or
> by the toolchain itself.
>
> However I don't think it shoud replace scons, because certainly many
> project have based their integration of your project with it. I just
> think it could come additionally to ease building and integration for
> CMake based projects. Especially for embedded and multiplatform projects
> I think (e.g. I use it in a ptxdist and a yocto project for cross
> compiling for ARM Cortex A8, PPC, Windows 7 and Linux i386, this is for
> building automation softwares and devices).
>
> I added the patch on sourcefore at this address :
> https://sourceforge.net/tracker/?func=detail&atid=758828&aid=3527408&group_id=144446
>
> Cheers,
> --
> daminetreg
> alias Damien Buhl
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Jsoncpp-devel mailing list
> Jso...@li...
> https://lists.sourceforge.net/lists/listinfo/jsoncpp-devel



-- 
Francis Bolduc, B.Sc.
CM-Labs Simulation Inc.

[Jsoncpp-devel] Patch adding CMakeFiles: cross-compilation & integration in CMake project

[Damien B. <dam...@le...>]

Hello dear json_cpp developers,

I worked recently with json-rpc-cpp based on json_cpp and I wrote 
CMakeFile support for both. I wanted to provide my small contribution to 
this nice library by sending you this patch.

I was wondering if it could be integrated in the mainline or if you want 
to keep it as a patch aside, but I have the feeling that it should be 
mainline, because CMake is really one of the best choice for cross 
compilation and recompilation on any platform. It has an advantage over 
scons in the fact that cross compilation is generically and uniformly 
supported. This makes any CMake project cross compilable seamlessly for 
any platform without any specificf platform configuration in the 
makefile other than a cross cmake toolchain file provided by the user or 
by the toolchain itself.

However I don't think it shoud replace scons, because certainly many 
project have based their integration of your project with it. I just 
think it could come additionally to ease building and integration for 
CMake based projects. Especially for embedded and multiplatform projects 
I think (e.g. I use it in a ptxdist and a yocto project for cross 
compiling for ARM Cortex A8, PPC, Windows 7 and Linux i386, this is for 
building automation softwares and devices).

I added the patch on sourcefore at this address : 
https://sourceforge.net/tracker/?func=detail&atid=758828&aid=3527408&group_id=144446

Cheers,
--
daminetreg
alias Damien Buhl

[Jsoncpp-devel] Missing header inclusion in amalgamate.py

[Francis B. <fra...@cm...>]

assertions.h is missing. Here's the patch:

Index: amalgamate.py
===================================================================
--- amalgamate.py	(revision 248)
+++ amalgamate.py	(working copy)
@@ -66,6 +66,7 @@
     header.add_text( '/// If defined, indicates that the source file
is amalgated' )
     header.add_text( '/// to prevent private header inclusion.' )
     header.add_text( '#define JSON_IS_AMALGAMATION' )
+    header.add_file( 'include/json/assertions.h' )
     header.add_file( 'include/json/config.h' )
     header.add_file( 'include/json/forwards.h' )
     header.add_file( 'include/json/features.h' )

Re: [Jsoncpp-devel] Creating JSON with jsoncpp

[Andris P. <and...@ik...>]

On 10/19/2011 04:58 PM, Matt Berlin wrote:
> I am having difficulty creating a JSON object with jsoncpp.
>
> I have managed to get an array in the form [...[...]...], but I require the data to be int he form
> {...{...}...}
>
>  From the documentation, I believe this would be done using Json::ObjectValue, but I have not been
> able to find any examples of how to get this working -- all examples I've been able to find rely on
> pre-created JSON.
>
> Thank you,
>

Json::Value x;
x["a"]["b"] = "c";
x["a"]["d"] = 1;
std::cout << x << std::endl;

[Jsoncpp-devel] Creating JSON with jsoncpp

[Matt B. <mb...@im...>]

I am having difficulty creating a JSON object with jsoncpp.

I have managed to get an array in the form [...[...]...], but I require the
data to be int he form {...{...}...}

>From the documentation, I believe this would be done using
Json::ObjectValue, but I have not been able to find any examples of how to
get this working -- all examples I've been able to find rely on pre-created
JSON.

Thank you,

Matt Berlin

-- 
-------------------------------------------*
Matthew Berlin*
*Web Developer
*Latman Interactive

*Website*: latman.com <http://www.latman.com/>

Re: [Jsoncpp-devel] Patch to fix amalgamate.py

[Joseph G. <jos...@gm...>]

Improved patch, also fixes missing assertions header. Without it there
are lots of errors about JSON_FAIL_MESSAGE and others being undefined.
Also, I'm manually specifying -DJSON_IS_AMALGAMATION as part of my
build, but it sounds like I'm not supposed to need to do that?

-Joe G.

On Sat, Jun 11, 2011 at 1:54 PM, Joseph Garvin
<jos...@gm...> wrote:
> amalgamate.py currently doesn't work on Linux because some paths are
> done using backslashes instead of forward slashes. I think the Right
> Way (TM) to do this is to use os.path, but here's a lazy patch that
> just swaps the slashes.
>
> -Joe G.
>