• Advertisement
Sign in to follow this  

A cross-platform C++ systems library for game development

This topic is 3734 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've written a cross-platform C++ library that works on Linux/UNIX, Mac, and Windows...it provides abstractions for threads, mutexes, sockets, buffers, streams, loadable modules, and lots of other stuff. It was originally designed to be a framework specifically for building an MMO game engine, though now I use it quite a bit for unrelated projects at work. Check it out at http://freshmeat.net/projects/commoncpp/ This project has nothing to do with the "GNU Common C++" project...this library provides a much richer set of classes. Cheers, M.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Kylotan
Do you have a description of the benefits that these classes have over, for example, Boost equivalents?


If I may add my 2 cents, boost isn't the end to C++ programming. It provides neccessary additions and improvements to the STL, but it's still low level stuff.

A lot of (commercial) libraries use neither STL nor boost, Qt for example.

Share this post


Link to post
Share on other sites
After a quick look, I would have to say that it's "cleaner-looking" (superficial, I know) than boost. Ultimately, performance considerations would trump anything, but I, for one, am sick of ugly C++ naming conventions and heavy use of templates.

I've wondered many times why someone didn't write a C++ equivilent of the JDK, or something like that--of course, I never looked, thinking that I surely would have heard of it--but yours looks nice.

Share this post


Link to post
Share on other sites
mesmerism,

I'm looking at the API documentation snapshot and I have to say that I'm very impressed! Does this really work on all the mentioned platforms? I'm very interested in the MD5 and Timer functionality.

Share this post


Link to post
Share on other sites
Quote:
Original post by smitty1276
After a quick look, I would have to say that it's "cleaner-looking" (superficial, I know) than boost. Ultimately, performance considerations would trump anything, but I, for one, am sick of ugly C++ naming conventions and heavy use of templates.

I've wondered many times why someone didn't write a C++ equivilent of the JDK, or something like that--of course, I never looked, thinking that I surely would have heard of it--but yours looks nice.


I am thinking about a new Front End for C++, one that allows you to use template magic etc. in a more accessible way. Would make even boost fun.

Or just a new (or heavily extended) preprocessor.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Of course, but it's still a valid question for the parts that do overlap with Boost.


Coherence?

Share this post


Link to post
Share on other sites
Quote:
Original post by Paradoxia
mesmerism,

I'm looking at the API documentation snapshot and I have to say that I'm very impressed! Does this really work on all the mentioned platforms? I'm very interested in the MD5 and Timer functionality.

The canonical MD5 code is platform agnostic and free - no need to wait for an encapsulation [smile].

Anyway, I had to congratulate mesmerism: its seems to be a great library, with a lot of features (Base64 encoding! Sockets! XML! JNI! Persistence!). Getting everything to a workable state must have been quite long.

I would say only one thing: putting everything in one single namespace is not a good idea (not to mention that the namespace name is not that great: it's a bit too long. What about ccpp?). I would have prefered to see multiple sub-namespaces: jni, thread, xml, db, and so on...).

But still: good work, mesmerism. And r++.

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
I would say only one thing: putting everything in one single namespace is not a good idea (not to mention that the namespace name is not that great: it's a bit too long. What about ccpp?). I would have prefered to see multiple sub-namespaces: jni, thread, xml, db, and so on...).

But still: good work, mesmerism. And r++.


I second that.

Share this post


Link to post
Share on other sites
Quote:
Original post by Konfusius
Quote:
Original post by Spoonbender
Of course, but it's still a valid question for the parts that do overlap with Boost.

Coherence?

If one wants coherence, then one would presumably use a library which was designed to look and feel like the standard library... as Boost was.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Konfusius
Quote:
Original post by Spoonbender
Of course, but it's still a valid question for the parts that do overlap with Boost.

Coherence?

If one wants coherence, then one would presumably use a library which was designed to look and feel like the standard library... as Boost was.


Well, it started as a framework, and as such it presumably has its own abstractions and look and feel.

Share this post


Link to post
Share on other sites
I think your library is fantastic! I really hate boost and stl because of their syntax and calling conventions. I've always wanted something with the same feel as the .NET libraries and yours is exactly that. Great job!

Share this post


Link to post
Share on other sites
Yes, I don't mean to start a Boost vs. Commonc++ argument. I just think it would be great if the author could share some of his opinions on why he reimplemented some of these constructs, and any areas where he thinks his approach is better than that taken by Boost. This would help others in choosing which to use.

Share this post


Link to post
Share on other sites
Quote:
Original post by soconne
I really hate boost and stl because of their syntax and calling conventions.

Uh... their calling conventions? What problem do you have with __thiscall?

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by soconne
I really hate boost and stl because of their syntax and calling conventions.

Uh... their calling conventions? What problem do you have with __thiscall?
Real programs only use __fastcall.

Share this post


Link to post
Share on other sites
Well, as others have pointed out, boost is a rat's nest of templates and cryptic symbols. The boost libraries are modeled after STL which itself has, in my opinion, an ugly API. I modeled commonc++ after Qt and the Java core APIs, which I've used extensively and which I believe are much more intuitive, more "elegant" (aesthetically, if not functionally) and much easier to wrap one's head around than boost.

commonc++ was designed to be a reasonably complete and self-contained wrapper around non-portable operating system APIs. It is meant to serve the same role for C++ programs as APR (the Apache Portable Runtime) does for C programs: it hides the messiness (particularly on Windows) of said system APIs, making it possible to write complex systems software that will run on all of the supported platforms without changes to the code.

There is indeed overlap in functionality but I think in general commonc++ provides portable access to a wider range of OS functionality than the equivalent boost libraries. For example how do you set a thread's scheduling priority or create a detached thread with Boost.Thread? And of course there is a whole lot of systems-level functionality in commonc++ for which there is no equivalent in boost.

I think both commonc++ and boost have their place. I wrote commonc++ because I'd looked at Boost (and other similar libraries) and none of them really suited my needs. It was open sourced with the hope that others might also find it useful.




Share this post


Link to post
Share on other sites
Well that looks pretty durn sweet. I am installing it on my MacOSX box as we speak. Sure will make future projects a lot easier!

Thanks for all the hard work there mate! I will definitely keep coming back for the updates!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement