Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Boost

Reply
Thread Tools

Boost

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-28-2014
On Tue, 2014-01-28, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
....
>> Personally I suspect a (possibly gzipped) text stream is good enough
>> almost all the time.
>>

>
> I think those working on scientific apps would disagree.
> The serialization of their data is faster with binary and
> there's probably no need for an additional compression step.


Quite possible for some kinds of scientific apps -- I think my "almost
all the time" gets me off that particular hook!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      01-29-2014
On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
> (E-Mail Removed) wrote:
>
> > If you had said --
> >
> > it sometimes has to inter-operate
> >

>
> > I'd agree. I know of a few companies that write C++
> > programs that communicate with each other. That's
> > not exactly unheard of.

>
> Probably the most common type of "service" these days is the web
> service. Web services almost exclusively use SOAP. If you are going to
> write the back ends for web pages in C++, you will probably have to use
> JSON to communicate with the client JavaScript.



I've been reading about JSON some. The following is
maybe due to some misunderstanding, but it seems
JSON can only deal with user defined objects.

I have a message template (not a C++ template) that
looks like this:

@out (::cmw::marshalling_integer, const char*)

(A function is generated based on that.)

IIuc, with JSON, I'd have to create a class that has
those two types in it and then marshal an instance of
that type. I like not having to do that as there's
no need currently for such a class. Those two pieces
of data are from the command line and I just forward
them to the marshalling function without having to
create an object that's only use would be marshalling
it's data members. I will admit it wouldn't take long
to construct such an object, but there's a wrinkle.
If the class were:

class front_tier_type
{
cmw::marshalling_integer account_number;
char* path;
};

That class won't work for me in my middle tier where
it doesn't hurt to store the data from the path variable
in a std::string. I have to store it somewhere in the
middle tier so I choose to put it in a std::string.

Constructing a front_tier_type would be fast, but if
I changed it to have a std:string instead of a char*
it gets more expensive. I don't want to have to pay
for that in the front tier. So iiuc, JSON based
approach would have one class on sending side and
another on the receiving side. The other approach I
described is also different on the sending and receiving
ends, but is more efficient.

If there were more than two pieces of data, constructing
an object becomes more of a waste.

The C++ route seems to offer more flexibility than
the JSON approach.


>
>
> > And as I said I'm open to working on adding support
> > for another language, but I don't think that language
> > will be Java. Python or C# is more likely.
> >

>
> > I think scientific apps and games often use binary serialization.
> >


> By using a proprietary binary format,


The format isn't a secret.

> you are restricting yourself to a
> narrow range of applications. The easiest way to support other
> languages is to use a well known on wire format.


I may go back to this angle.

Brian
Ebenezer Enterprises
http://webEbenezer.net
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      01-30-2014
(E-Mail Removed) wrote:
> On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
>> (E-Mail Removed) wrote:
>>
>>> If you had said --
>>>
>>> it sometimes has to inter-operate
>>>
>>> I'd agree. I know of a few companies that write C++
>>> programs that communicate with each other. That's
>>> not exactly unheard of.

>>
>> Probably the most common type of "service" these days is the web
>> service. Web services almost exclusively use SOAP. If you are going to
>> write the back ends for web pages in C++, you will probably have to use
>> JSON to communicate with the client JavaScript.

>
> I've been reading about JSON some. The following is
> maybe due to some misunderstanding, but it seems
> JSON can only deal with user defined objects.


It depends on how you use JSON and your chosen library. I would write
something like:

json::Object blob;
blob["number"] = accountNumber;
blob["name"] = accountName;

std::cout << blob;

<snip>

> Constructing a front_tier_type would be fast, but if
> I changed it to have a std:string instead of a char*
> it gets more expensive. I don't want to have to pay
> for that in the front tier. So iiuc, JSON based
> approach would have one class on sending side and
> another on the receiving side. The other approach I
> described is also different on the sending and receiving
> ends, but is more efficient.
>
> If there were more than two pieces of data, constructing
> an object becomes more of a waste.
>
> The C++ route seems to offer more flexibility than
> the JSON approach.


In cases where speed of serialisation isn't critical (most cases I'd
suggest), the flexibility and interoperability of text on the wire wins out.

I often use all or part of the received JSON object directly in the
sever code, so it never gets converted to something else. I guess this
habit comes form having written a lot of JavaScript.

>>> And as I said I'm open to working on adding support
>>> for another language, but I don't think that language
>>> will be Java. Python or C# is more likely.
>>>

>>
>>> I think scientific apps and games often use binary serialization.

>
>> By using a proprietary binary format,

>
> The format isn't a secret.


But you's have to convince others to adopt it.

--
Ian Collins
 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      01-30-2014
On Wednesday, January 29, 2014 6:32:30 PM UTC-6, Ian Collins wrote:
> (E-Mail Removed) wrote:
>
> > On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:

>
> >> Probably the most common type of "service" these days is the web

>
> >> service. Web services almost exclusively use SOAP. If you are going to

>
> >> write the back ends for web pages in C++, you will probably have to use

>
> >> JSON to communicate with the client JavaScript.

>
> >

>
> > I've been reading about JSON some. The following is
> > maybe due to some misunderstanding, but it seems
> > JSON can only deal with user defined objects.

>
> It depends on how you use JSON and your chosen library. I would write
> something like:
>
> json::Object blob;
> blob["number"] = accountNumber;
> blob["name"] = accountName;
>
> std::cout << blob;
>


That kind of helps, but the indices ("number" and "name")
are a problem. I don't have a means of getting that
information from a user like I do if they provide a header
file with data member names.

Let me change the messsage template a little

@out (int, const char*)

The generated function for that will have a1 and a2
for the names of the arguments. So

json::Object blob;
blob["a1"] = a1;
blob["a2"] = a2;

That doesn't work for me on the receiving side where
I have a user defined type.

>
>
> > The C++ route seems to offer more flexibility than
> > the JSON approach.

>
> In cases where speed of serialisation isn't critical (most cases I'd
> suggest), the flexibility and interoperability of text on the wire wins out.
>


Well where speed is critical, there's a good chance they'll
be using C++ so that much is promising from my perspective.

> I often use all or part of the received JSON object directly in the
> sever code, so it never gets converted to something else. I guess this
> habit comes form having written a lot of JavaScript.
>


I recall your saying something like that previously. I'd like
to know how accessing a JSON object compares to accessing a C++
object. Is it a lot slower? I recall Juha talking about
something that may have been similar with Objective C.


Brian
Ebenezer Enterprises
http://webEbenezer.net
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-30-2014
(E-Mail Removed) wrote:
> On Wednesday, January 29, 2014 6:32:30 PM UTC-6, Ian Collins wrote:
>
>> I often use all or part of the received JSON object directly in the
>> sever code, so it never gets converted to something else. I guess this
>> habit comes form having written a lot of JavaScript.
>>

>
> I recall your saying something like that previously. I'd like
> to know how accessing a JSON object compares to accessing a C++
> object. Is it a lot slower? I recall Juha talking about
> something that may have been similar with Objective C.


Given a JSON object is a C++ object, the access will depend on the
complexity of the object. My library is designed for programmer
convenience first, efficiency a close second. I wanted to support
arbitrary nesting, such as

json::Object blob;

blob["one"]["two"]["three"]["four"] << 1 << 2 << "hello";

which creates this object:

{"one":{"two":{"three":{"four":[1,2,"hello"]}}}}

This requires a degree of indirection than a more basic implementation
would.

If I want to use an internal C++ object, I code generate (usually from
an Open Office document) to/from JSON methods for the object's data.

--
Ian Collins
 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      01-31-2014
On Monday, January 27, 2014 5:55:11 AM UTC-6, Jorgen Grahn wrote:
>
> Personally I suspect a (possibly gzipped) text stream is good enough
> almost all the time.
>


What about streaming video?
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      02-01-2014
Op 26-Jan-14 23:46, (E-Mail Removed) schreef:
> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
>> (E-Mail Removed) wrote:
>>>
>>> Do you disagree with my claim that C++ is most important
>>> language for services?

>>
>> While C++ is an important language for services, it has to inter-operate
>> with servers and clients written in other languages.

>
> If you had said --
>
> it sometimes has to inter-operate
>
> I'd agree. I know of a few companies that write C++
> programs that communicate with each other. That's
> not exactly unheard of.
>
> And as I said I'm open to working on adding support
> for another language, but I don't think that language
> will be Java. Python or C# is more likely.


When communicating with a web server chances are it is written in Java.
Python has its own serialization facilities as does .NET, as does Java.
Focusing on one or a very few languages puts your solution at a
disadvantage compared to the more established alternatives. If you want
people to convince to use your solution over the well known, proven,
well supported and industry standard solutions (SOAP, JSON, BSON...etc),
you have to provide some compelling reason, i.e. a unique selling point,
which as of yet I haven't seen in spite of your frequent postings
promoting your library. I think you need to do a bit more market
research before investing in reinventing the wheel.

 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      02-01-2014
On Saturday, February 1, 2014 8:02:27 AM UTC-6, Dombo wrote:
> Op 26-Jan-14 23:46, (E-Mail Removed) schreef:
>
> > On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:

>
> >> (E-Mail Removed) wrote:

>
> >>>

>
> > And as I said I'm open to working on adding support
> > for another language, but I don't think that language
> > will be Java. Python or C# is more likely.

>
> When communicating with a web server chances are it is written in Java.
> Python has its own serialization facilities as does .NET, as does Java.
> Focusing on one or a very few languages puts your solution at a
> disadvantage compared to the more established alternatives. If you want
> people to convince to use your solution over the well known, proven,
> well supported and industry standard solutions (SOAP, JSON, BSON...etc),
> you have to provide some compelling reason, i.e. a unique selling point,
> which as of yet I haven't seen in spite of your frequent postings
> promoting your library. I think you need to do a bit more market
> research before investing in reinventing the wheel.


I'm pioneering on line code generation. These people
http://springfuse.com

are also working on on line code generation, but
they use Java. Most of what they say in terms of
marketing their service is also true of the C++
Middleware Writer.

10 years ago there was some doubt about the
path, but I don't think there's any doubt today.
On line code generation is here to stay.

Brian
Ebenezer Enterprises - "Imitation is the sincerest
form of flattery."
http://webEbenezer.net
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      02-01-2014
Op 01-Feb-14 17:16, (E-Mail Removed) schreef:
> On Saturday, February 1, 2014 8:02:27 AM UTC-6, Dombo wrote:
>> Op 26-Jan-14 23:46, (E-Mail Removed) schreef:
>>
>>> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:

>>
>>>> (E-Mail Removed) wrote:

>>
>>> And as I said I'm open to working on adding support
>>> for another language, but I don't think that language
>>> will be Java. Python or C# is more likely.

>>
>> When communicating with a web server chances are it is written in Java.
>> Python has its own serialization facilities as does .NET, as does Java.
>> Focusing on one or a very few languages puts your solution at a
>> disadvantage compared to the more established alternatives. If you want
>> people to convince to use your solution over the well known, proven,
>> well supported and industry standard solutions (SOAP, JSON, BSON...etc),
>> you have to provide some compelling reason, i.e. a unique selling point,
>> which as of yet I haven't seen in spite of your frequent postings
>> promoting your library. I think you need to do a bit more market
>> research before investing in reinventing the wheel.

>
> I'm pioneering on line code generation. These people
> http://springfuse.com are also working on on line code
> generation, but they use Java.


I'd hardly call that pioneering.

> Most of what they say in terms of
> marketing their service is also true of the C++
> Middleware Writer.


Springfuse makes rather generic claims, the kind of marketing speak one
expects for just about any software development tool. And above all it
still not answers the questions how your product differentiates itself
from competing, well established, solutions.

> 10 years ago there was some doubt about the
> path, but I don't think there's any doubt today.
> On line code generation is here to stay.


Ask yourself what is the benefit of online code generation for the
client. If it is the only option for code generation it would be a
considered to be a serious disadvantage by many because:
1. It undesirable to make your build process dependant on some external
service not under your own control;
2. But more importantly...what if the company that provides the online
service goes out of business or just decides to pull the plug?


 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      02-01-2014
On Fri, 2014-01-31, (E-Mail Removed) wrote:
> On Monday, January 27, 2014 5:55:11 AM UTC-6, Jorgen Grahn wrote:
>>
>> Personally I suspect a (possibly gzipped) text stream is good enough
>> almost all the time.

>
> What about streaming video?


No. But it seems to me that's a different problem compared to the
ones discussed so far.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Boost::any and boost::lambda with std::find_if Misiu C++ 3 01-31-2007 05:46 PM
#include <boost/shared_ptr.hpp> or #include "boost/shared_ptr.hpp"? Colin Caughie C++ 1 08-29-2006 02:19 PM
Problems mixing boost::lambda::bind and boost::shared_ptr.. Toby Bradshaw C++ 6 06-02-2006 04:12 PM
Any Boost Experts out there for Boost.Regex? Richard Latter C++ 2 05-17-2004 03:12 PM
Boost + Python C/API: Mixing python return types with boost return types Steve Knight Python 2 10-10-2003 10:11 AM



Advertisments