Boost, Networking, DB vis-a-vis Mono (WAS Re: [phil-cug] Re: Looking for C++ people)

2 views
Skip to first unread message

Dean Michael Berris

unread,
Sep 4, 2007, 5:08:48 AM9/4/07
to phil...@googlegroups.com
Hi Roger!

On 9/4/07, Roger Filomeno <aliena...@gmail.com> wrote:
> Hi Dean!
>
> Yeah, Boost is better. I'm stuck to a project that connects to a Windows
> servers so I have to go for Mono to manage all the data transfer object :|
>

Have you seen http://asio.sourceforge.net/ ? It's been accepted into
Boost like early this year (or was it last year? can't remember
exactly when) and it's all about asynchronous IO and network
programming in C++ that's cross platform. If you're talking about
something like CORBA, then it might be good to look at ICE.

I'm not sure what you mean by "data transfer object" but I use
Boost.Serialization to serialize data structures across C++
applications -- along with Boost.Asio to do the asynchronous network
IO.

> Btw, any opinion on LINQ?, its suppose to revolutionize C. IMHO they should
> have kept it with DB related data objects but now its on every collections.
> geex.
>

Haven't taken a look at LINQ yet, but if you're looking for DB related
stuff in C++, you might wanna look at http://soci.sourceforge.net/ .
It's not a Boost library yet, but their effort makes it pretty easy to
do pretty much any DB related stuff you'll need to do in C++.

Do you have a link to LINQ?

Thanks in advance!

--
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Roger Filomeno

unread,
Sep 4, 2007, 5:19:51 AM9/4/07
to phil...@googlegroups.com
Here: http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx

Oh yeah it's MS stuff, but mono isn't far behind. Im looking at asio, looks awesome.

> I'm not sure what you mean by "data transfer object"
Yeah, thats basically serializable objects (without methods). I never tried if they were compatible with Boost. Were using it with Flex so both c# server app and flex shares the same data transfer object code.
--
--
Roger P. Filomeno
TechBiz Asia Group Pte Ltd

My Blog: http://corruptedpartition.blogspot.com/
Via SMS:
MSG GODIE <YOUR MESSAGE>
then send to 2948 for Globe/Sun and 3940 for Smart.

Allister Levi Sanchez

unread,
Sep 4, 2007, 5:21:38 AM9/4/07
to phil...@googlegroups.com
Hey Dean,

Very informative :-)  Thanks!

On 9/4/07, Dean Michael Berris <mikhai...@gmail.com> wrote:



--
Dr. Allister Levi Sanchez ( san...@poly.in2p3.fr / allister...@gmail.com )
CNRS Postdoctoral Research Associate
Laboratoire Leprince-Ringuet, École Polytechnique, 91128 Palaiseau CEDEX, France

Dean Michael Berris

unread,
Sep 4, 2007, 5:34:43 AM9/4/07
to phil...@googlegroups.com
Hi Roger!

On 9/4/07, Roger Filomeno <aliena...@gmail.com> wrote:
> Here:
> http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx
>
> Oh yeah it's MS stuff, but mono isn't far behind. Im looking at asio, looks
> awesome.
>

Ah, yeah. I think this is what SOCI is trying to accomplish as well. I
haven't dug deeper than the page you linked, but I'm pretty confident
it shouldn't be hard to pick this up and run away with.

Although SOCI is doing a very good job of the same thing in standard C++.

> > I'm not sure what you mean by "data transfer object"
> Yeah, thats basically serializable objects (without methods). I never tried
> if they were compatible with Boost. Were using it with Flex so both c#
> server app and flex shares the same data transfer object code.
>

Hmmm... I haven't seen any static (compiled) languages be able to
serialize method implementations over the wire, and even with
reflection/introspection recreating the object on the other end would
be a PITA unless you're going to be doing some funky JIT compilation
and tons and tons of virtual runtime linkage. Though I've seen this
done with languages like JavaScript and Python (even Java), I doubt it
would be easy to accomplish that.

Though data serialization has been an interesting field for the
longest time. Lots of people have hand-rolled their own (mostly
targeted) implementations but Boost.Serialization does a good job of
providing a good "general case" implementation. Though it's not the
easiest thing to extend, it's doable -- so making a C++ implementation
of your own serialization format/protocol would be achievable by
playing nicely with Boost.Serialization.

Though I may be wrong, Boost.Serialization already supports
serialization into and deserialization from XML. Might be something
worth looking at if you're interested in doing XML serialization of
objects (and standard containers!) over the wire.

HTH!

Roger Filomeno

unread,
Sep 4, 2007, 6:58:46 AM9/4/07
to phil...@googlegroups.com
Thanks I will definitely look into that, some of our kiosk uses embedded c and they communicate using strings similar to URL query structure. We have been looking for something that's relatively manageable to replace those.


On 9/4/07, Dean Michael Berris <mikhai...@gmail.com> wrote:

Hi Roger!

On 9/4/07, Roger Filomeno <aliena...@gmail.com> wrote:
> Here:
> http://msdn2.microsoft.com/en-us/netframework/aa904594.aspx
>
> Oh yeah it's MS stuff, but mono isn't far behind. Im looking at asio, looks
> awesome.
>

Ah, yeah. I think this is what SOCI is trying to accomplish as well. I
haven't dug deeper than the page you linked, but I'm pretty confident
it shouldn't be hard to pick this up and run away with.

Although SOCI is doing a very good job of the same thing in standard C++.

> > I'm not sure what you mean by "data transfer object"
> Yeah, thats basically serializable objects (without methods). I never tried
> if they were compatible with Boost. Were using it with Flex so both c#
> server app and flex shares the same data transfer object code.
>

Hmmm... I haven't seen any static (compiled) languages be able to
serialize method implementations over the wire, and even with
reflection/introspection recreating the object on the other end would
be a PITA unless you're going to be doing some funky JIT compilation
and tons and tons of virtual runtime linkage. Though I've seen this
done with languages like JavaScript and Python (even Java), I doubt it
would be easy to accomplish that.

Were using Cairngorm which automatically "translate"(im not really sure if it serializes the object) C and Java data objects along with the RPC via AMF into Flash object and back, see: http://labs.adobe.com/wiki/index.php/Cairngorm:Cairngorm2.2:Release_Notes


--
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459


Dean Michael Berris

unread,
Sep 4, 2007, 7:17:58 AM9/4/07
to phil...@googlegroups.com
Hi Roger,

On 9/4/07, Roger Filomeno <aliena...@gmail.com> wrote:
> Thanks I will definitely look into that, some of our kiosk uses embedded c
> and they communicate using strings similar to URL query structure. We have
> been looking for something that's relatively manageable to replace those.
>

This is interesting... I've also been working on a cross-platform
networking library built on top of Boost.Asio --
http://sourceforge.net/projects/cpp-netlib -- but currently I haven't
been putting much time into that. Might be something you'd be
interested in taking a look at -- or even contributing to. :)

>
> On 9/4/07, Dean Michael Berris <mikhai...@gmail.com> wrote:
> >
> > Hmmm... I haven't seen any static (compiled) languages be able to
> > serialize method implementations over the wire, and even with
> > reflection/introspection recreating the object on the other end would
> > be a PITA unless you're going to be doing some funky JIT compilation
> > and tons and tons of virtual runtime linkage. Though I've seen this
> > done with languages like JavaScript and Python (even Java), I doubt it
> > would be easy to accomplish that.
>
> Were using Cairngorm which automatically "translate"(im not really sure if
> it serializes the object) C and Java data objects along with the RPC via AMF
> into Flash object and back, see:
> http://labs.adobe.com/wiki/index.php/Cairngorm:Cairngorm2.2:Release_Notes
>

I highly doubt that the actual method implementations are serialized
and executed in the client side. I can see though how something like
RPC can be used, but the method gets executed in the remote machine
(server usually). The data interchange can very well use some sort of
"message type", basically encapsulating information that's essential
to the RPC call.

This definitely looks interesting, but I'm looking forward to a stable
release of Adobe AIR (http://labs.adobe.com/technologies/air/) which
can very well be the Java killer from Adobe. Granted that this Flex
thing can run on AIR, it sure looks like Rich Internet Applications
(RIA) will be the next big thing not only on the enterprise but for
the mass market as well.

me22

unread,
Sep 4, 2007, 10:21:31 AM9/4/07
to phil...@googlegroups.com
On 04/09/07, Dean Michael Berris <mikhai...@gmail.com> wrote:
> Hi Roger,
> [...]

Just for the record, I haven't gotten any of Roger's emails apart from
the first, which makes the conversation rather more difficult to
follow...

~ Scott

--
La vendetta è un piatto che va servito freddo

Dean Michael Berris

unread,
Sep 4, 2007, 11:05:32 AM9/4/07
to phil...@googlegroups.com
It might have something to do with an issue with gmail/google groups.
Allister replied as well, and even though I've approved his posting I
have yet to see his mail delivered.

It may also be possible the messages are being marked as spam. Of
course you woul've already checked that. ;-)

Allister Levi Sanchez

unread,
Sep 4, 2007, 11:11:23 AM9/4/07
to phil...@googlegroups.com
Maybe he didn't notice the other (original) thread?


On 9/4/07, Dean Michael Berris <mikhai...@gmail.com > wrote:

It might have something to do with an issue with gmail/google groups.
Allister replied as well, and even though I've approved his posting I
have yet to see his mail delivered.

It may also be possible the messages are being marked as spam. Of
course you woul've already checked that. ;-)



Gil Prudente

unread,
Sep 5, 2007, 5:55:13 AM9/5/07
to phil...@googlegroups.com
Hi,
 
ICE looks okay except that it's GPL. Commercial licensing is available but you have to contact them to for the pricing... which probably means it is expensive :) ACE has a more permissive license. It's been around for quite some time but it is still in active development.
 
Regards,
Gil
 
On 9/4/07, Dean Michael Berris <mikhai...@gmail.com> wrote:

Dean Michael Berris

unread,
Sep 5, 2007, 11:07:53 PM9/5/07
to phil...@googlegroups.com
Hi sir Gil!

On 9/5/07, Gil Prudente <gilpr...@gmail.com> wrote:
> Hi,
>
> ICE looks okay except that it's GPL. Commercial licensing is available but
> you have to contact them to for the pricing... which probably means it is
> expensive :) ACE has a more permissive license. It's been around for quite
> some time but it is still in active development.
>

I agree that the GPL license is a bit iffy -- I personally like the
New BSD license and the Apache License as far as open source licenses
are concerned (I also like the simple Boost Software License which I
think is very very permissive).

Building commercial software in the sense that it will be sold to the
masses (or to some customers) makes the GPL a non-option. Although if
it's under the LGPL, there might still be a way to have binaries link
to it without having to expose the sources of the actual software
using the library.

However, if you're building software that's going to be used/kept
in-house then using a GPL'ed library shouldn't be a problem. The GPL
will only take effect upon (re)distribution of the software anyway and
not the actual usage.

IANAL though, so consult with your legal counsel before dealing with
license related issues. :D

As for ACE, I think my personal apprehension to it is that it's a
Framework instead of a Library (or toolbox). All the ACE'isms that
your code should abide by makes it very hard (and almost impossible)
to design your application in a manner which you _know_ or would like
to see would be faster/better. What appeals to me OTOH in Boost is
that it's a collection of utilities which allow you to be as creative
and unbound as you can be when coming up with solutions in many
different frontiers.

This doesn't even mention the modern C++ approaches that allow
developers to make use of the powerful language features of C++
(templates, standards-compliant optimizations, reasonably efficient
RTTI (in some cases, and only when necessary), and object oriented
(yes!) as well as functional (yes!) programming).

All in all, ACE is great if you've already invested time and effort in
mastering the workings and patterns that are available in the
Framework -- and the platform you're building in isn't supported by
Boost explicitly. It's also great if you don't mind the performance
hit of dynamic polymorphism especially in network code. But if you
need to start from scratch, I'd recommend Boost for much (if not all)
your C++ development needs -- along with the STL which almost always
comes with your favorite C++ compiler.

Just my $0.02. :)

Rafael Sevilla

unread,
Sep 5, 2007, 11:39:06 PM9/5/07
to phil...@googlegroups.com, mikhai...@gmail.com
On Wed, 5 Sep 2007 20:07:53 -0700

"Dean Michael Berris" <mikhai...@gmail.com> wrote:
> Building commercial software in the sense that it will be sold to the
> masses (or to some customers) makes the GPL a non-option.

Only if you don't want to give the source to your customers.
Commercial != Proprietary! We have no qualms about selling GPLed code
which we have hacked to our customers, as we give them an offer of the
source if they want it (most of them don't bother) and as such remain
in perfect compliance with the GPL.

Let's get the idea that you must turn code proprietary in order to
sell it out of the way. That simply isn't true. You personally might
have a problem sharing your code with your customers, but that doesn't
mean that it's impossible to make a living by doing just that.

--
Any sufficiently advanced incompetence is indistinguishable from malice.
http://stormwyrm.blogspot.com

signature.asc
Reply all
Reply to author
Forward
0 new messages