The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

ACE Framework

I am developing a scalable server application that is required to listen on a port waiting for multiple clients to connect. The client to server communication is through a Application layer protocol similar to xml-rpc (with payloads embedded in xml tags). So, I was looking at the ACE framework (the language of choice is C++). I am apprehensive to use it in the first place for reasons;

1. Frameworks are not always beneficial;  this would yield to some learning curve in the team and may not worth the hassles at the end.

2. May not use all the futures of the framework, hence your application ends up as a bloatware.

4. Bugs are difficult to track.

5. A new version might break the code.

So, if you have anything good to say about ACE or any advice why I shouldn't be prejudiced about a framework please do post your comments.
Tony Send private email
Wednesday, June 25, 2008
Having used ACE (and TAO, a derived CORBA suite) extensively at a previous position, here's my take.

1) Yes there's a learning curve.  Yes it's beneficial.  *Especially* for the type of application you describe.

2) The size of the library *may* only be an issue if you distribute your app.

3) The DOC group has been very good with tracking issues.

4) Upgrades to the libraries have been largely transparent.

That's not to say it's all hearts and flowers, either. 

-) This is more of a *framework* as opposed to a suite of libraries.  Meaning you write your app to fit the framework's scaffolding.  If you have a reasonably large body of code that uses a different model than used by ACE, you may have some difficulty meshing the two.

-) The portability macros used throughout the code make it all painful to read.

-) The lib can take a long time to build (although, they've done a lot to speed that up).

-) Much of the documentation is written by academics.  They read like theses.  At least that's what I thought when I could keep my eyes open.

That said, it's a good framework.  They've done a pretty good job at wrapping some low level things that usually trip folks up when developing these sorts of things. 

Were I to write another server application, I'd probably use it again.
Wednesday, June 25, 2008
You bring up very valid points and I think worthy of intellectual honesty in the responses.

ACE runs on just about everything these days - the code reflects that; neither good nor bad only opinion.
ACE is a framework that has been accused of being a great fanework so long as your view is in accordance to the one shared by ACE - not a personal opinion but what framework does this not apply too?
ACE is well known outside of hobbyist programming circles and used extensively in industrial strength solutions - due to age and maturity?

There is also the alter ego POCO Portable C++ Components that is much more modern, modular, easier grok BUT it does not have the age of ACE which also commands the maturity factor.

I would consider either lib based on target deployment, ability to support the lib myself if my application and name are riding on it, etc.  ACE is monolithic where POCO is much smaller in certain circumstances.  In a lot of ways they compete in the same space yet they are very different and there is no overlap.

If you are not familiar with POCO then go grab the tree and quickly examine it for yourself.  The projects that I am invloved with typically use ACE or POCO.  I can't offer one clear choice over the other.  I will also add that as a C++ developer it does not hurt to be familiar with ACE in the professional arena.
Random Observer Send private email
Wednesday, June 25, 2008
+1 to Jason.  I second everything he has stated as well.
Random Observer Send private email
Wednesday, June 25, 2008

I have used ACE. The learning curve is very high even though I bought 3 of their recommended books.

You may be interested in ICE which is very easy to use to build CORBA like applications, but comes with a GPL or a commercial runtime license (last time I spoke to them its % of your sale per unit).

Just looked at POCO, pretty good start to getting the rich libraries that are in .NET and Java.

I've been programming for years in C/C++, .NET and Java on various projects; the right tool for the right job.

I do a lot of server side programming espcially in .NET using sockets & .NET remoting. I find issues hitting me especially with the 25-ish max threads per process.

I would love to see a comeback of C++ with more libraries based on ideas from .NET and Java.

POCO is an inspiring idea; can you show me a link where I can do some sort of remoting with it?


Thursday, June 26, 2008
"...can you show me a link where I can do some sort of remoting with it?"

POCO has an extended version of the core components in a commercial enterprise package which contains, you guessed it, CORBA and RMI support.  There is talk of bringing more components into the community edition but I would not expect it soon.  Scour the homepage and you can find all the details that range from this subject to milestones and roadmap they take seriously.
Random Observer Send private email
Thursday, June 26, 2008
I've been exposed to ACE. Without any books. It's way too monolithic and totalitarian for my tastes.

I think our main problem with ACE is we were trying to code to it without really understanding it. But there were plenty of bright people in the group. If we couldn't grok the beast without a heap of books that's evidence that the design isn't very logical. Something that's logical doesn't need a lot of explaining. It's self evident.

I spent a lot of time trying to chase a memory leak. Every code path wandered through ACE. It wasn't clear which class was responsible for freeing which buffer. Maybe if I'd read the pile of books it would say in there somewhere. I began to suspect the memory leak was in ACE itself but by that time thje project had been disbanded. All I can say for sure is that ACE got in the way of my debugging. It obscured everything.

One guy bought a book on ACE. He still had trouble figuring things out. He didn't find the memory leak either.

Should we have invested in all the books? Probably yes but we were cheapskates and we were in a hurry. But that just raises a further question: Why need so many books?

A good tool shouldn't need much documentation and shouldn't put undue restrictions on how its users can employ it. ACE fails both these requirements.

I'm not completely intolerant of complexity. I use XOOPS a lot in my Web development. I wish it were coded much more straightforwardly but it works so I stick with it.
Thursday, June 26, 2008

Found the link about POCO remoting:



Thursday, June 26, 2008
"I do a lot of server side programming espcially in .NET using sockets & .NET remoting. I find issues hitting me especially with the 25-ish max threads per process."

Sorry, a little off topic, but there's a way around the max thread issue.  Blank, email me if you're interested, I can provide you with a class that lets you change the max threads.
ian Send private email
Friday, June 27, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz