Slashdot Mirror

RAII, smart pointers, and scope guards all contribute towards making manual resource tracking a problem of the past in C++. Raw pointer newing in general should get you fired in most workplaces today.

malloc and free should never be used in C++ code. It won't construct the object, and an overloaded new/delete will not be called. If for some reason you desire non-constructed object allocation, you should prefer ::operator new(size_t) and ::operator delete (not to be confused with new and delete operators).

I thought of a second good example: smart pointers.

Something like Boost's scoped_ptr is simple, as fast as, and no more memory hungry than a built-in pointer.

His C# example was one of bad code. Good code is self-documentating, making named parameters redundant.

For instance, obj.save_to_directory("location") is clear already.

obj.CrapInShed(true, "hrm") could be clarified to obj.CrapInShed(LargeDump, Shed("shed_name")).

When you have multiple parameters in a function call, using multiple rvalues in that call generally makes it unreadable. So, you could also use lvalues for this instead.
auto shed_name = "name";
obj.CrapInShed(SmallDump, shed_name);

Incidentally, C++ has a named parameter library in the Boost set. I haven't used it... usually this issue can be solved by redesign.

I don't believe I have ever, as in once, read a GPLed codebase that was not of utter crap quality. (Some do undoubtedly exist of course.) So no, this doesn't apply. And everything I create is in public domain or licensed BSD.

Boost is probably the most influential library ever written. And it has no terms. If it had been released into GPL, its status today as a semi-standardized C++ library would not be in effect.

You could also use SigC++ or Boost.Bind, or even std::mem_fun in modern C++...

This happens sometimes when I screw up doing pointer arithmetics or when I do not check array bounds.

To cure this, I started designing a system were I will abstract pointers with my own custom library. It will also automatically free the memory from unused objects. I will call it "memory recollection".

I am also designing my own custom third party library to automatically check array bounds ;-))

You mean like boost::shared_ptr and std::vector::at() ?

Hi, I have tried different socket libraries for Windows and Linux applications. SharkEngine is a free C++ library for network, file and multi threading support. There are also higher level protocol classes so you don't need to reinvent HTTP and SMTP for example. Otherwise QT and Boost are obviously good choices, then there is "Alhem's C++ Sockets Library". I never used ACE, the documentation is confusing and I think John Snader warns in his TCP/IP Programming book about it. Here is a list with contenders:

* SharkEngine http://www.pichat.net/documentation/pichat_sdk_sharkengine
* QT http://doc.trolltech.com/2.3/network.html
* Boost http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio.html
* Alhem http://www.alhem.net/Sockets/

When it comes to small databases I know only SQLite, which is programmed in C and more powerfull than Berkeley-DB. See http://www.sqlite.org./

Boost ... is the basis for the threading capabilities in the forthcoming revision of the C++ standard.

It's probably the other way around, see the Boost thread documentation. In any case, it's much easier than using pthreads' C API, and I think the feature set is approximately the same as pthreads.

Boost ( http://www.boost.org/ ) is good I also hear nice things about POCO http://pocoproject.org/

1. Use Boost. It's a very liberally-licensed, high-quality library from the people who created the C++ language itself. It contains a ton of cross-platform libraries that do lots of useful things, from threads to regular expressions to writing testsuites and parsing command-line options. If Boost provides a piece of functionality, there's very little reason not to use its version.
2. See rule #1.
3. If you need cross-platform code that isn't in Boost, at least use the following approach:
   • Create a common interface definition
   • In separate files, implement the interface in terms of various platforms' primitives
   • Keep platform-specific code out of the rest of your program; if you can help it, don't even include platform headers in most of your program
4. Use autoconf to handle platform idiosyncrasies. There are a ton of available macros to help detect things about a build platform.
5. Write testcases. You should write tests for all your programs, but it's especially important to do it for cross-platform code because it's easy to break something and not notice.

Boost has pretty strong threading support, which is the basis for the threading capabilities in the forthcoming revision of the C++ standard. Boost also has cross-platform IPC and socket libraries. It would be a good choice for the OP, I think.

Boost has pretty strong threading support, which is the basis for the threading capabilities in the forthcoming revision of the C++ standard. Boost also has cross-platform IPC and socket libraries. It would be a good choice for the OP, I think.

Boost has pretty strong threading support, which is the basis for the threading capabilities in the forthcoming revision of the C++ standard. Boost also has cross-platform IPC and socket libraries. It would be a good choice for the OP, I think.

NSPR, APR, boost system, threads

Show me their standardized network...

http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio.html

...threading...

http://www.boost.org/doc/libs/1_40_0/doc/html/thread.html

...GUI...

*shrug* There's not a *standard* GUI, but there are a few high-quality ones:
http://qt.nokia.com/
http://www.wxwidgets.org/
http://www.fltk.org/

Show me their standardized network...

http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio.html

...threading...

http://www.boost.org/doc/libs/1_40_0/doc/html/thread.html

...GUI...

*shrug* There's not a *standard* GUI, but there are a few high-quality ones:
http://qt.nokia.com/
http://www.wxwidgets.org/
http://www.fltk.org/

C++ has the disadvantages of both C and object-orienting combined.

Wrong. C++ has advantages of both C and object-orienting combined. And some really nice libraries such as boost. That comes at a cost of pretty steep learning curve which IMO is worth it.

First -- Is "modern" C++ (with STL and possibly boost) a larger beast than "modern" Java? Haven't they both been inflated to the point that 50%+ of the language is deprecated, and whenever you bring one of them up you have to "be more specific" about "which C++" or "which Java" you're referring to?

Modern C++, even C++0x, does not have many deprecated features. pair, bind1st, etc. are the only things I can think of off the top of my head that will be entirely replaceable in C++0x (by tuples and bind/lambdas). C++'s mantra of "don't pay for what you don't use" makes a lot of deprecation unlikely -- for instance, a Java developer may see std::function as a sensible replacement for function pointers, but it can still have higher overhead so function pointers are here to stay.

I don't know Java, I can't directly compare the two. I do know C# which I understand is very similar, so I would guess that C++ has many more unique patterns than Java. Run-time code is only part of it, in C++ -- once you learn that, you've got a very different compile-time feature set to master. And then you've got even crazier things like Fusion, which blur the line between run-time and compile-time. Most C++ devs, 10 years into learning it and using it for big real-world projects, will still acknowledge that they don't know it completely and be amazed at some new technique they see.

Second -- I use both C and C++ for different needs, and while it's true that C can be "kept simple" in some environments, any project of meaningful scale will become a nightmare to maintain/debug. Whenever I have a choice to skip-to-C++ (usually in embedded programming, where speed and program size are still a big issue) I do so just to I can use containers and avoid throwing pointers around. While it maybe possible to argue that C is simpler, it's also one of the languages that makes it the easiest thing in the world to shoot yourself in the foot with a 12-gauge. I'll use C when there's no other choice (again, embedded systems), but I'll switch to C++ as soon as the architecture is large/fast enough to support it.

I usually skip straight to C++ too. I think it can usually accomplish the same thing C can, but more easily and/or more efficiently. But I also think it doesn't make much difference in management and maintainability of large-scale projects. When you get to that level, it's more about how you organize your code than how you implement it.

The pattern is known as "Resource Acquisition is Initialization", or RAII. Search for that and you'll get a ton of hits. Simple rule of thumb: new in constructors, delete in destructors. There are smart pointer classes available to help you do this.Boost provides a set of them and it sounds like Qt has something similar.

The problem is that you can't do what you were doing before, just by not calling it finalize. In C++ it is a common practice to rely on the stack for resource management (this is where it differs from C), and the reason that you can do this is because you have destructors. And yes, you can do this even when you allocate on the heap (see scoped_ptr). There is no equivalent way to track resources in Java.

Now, you might say that this is not an issue, since the GC will reclaim all memory anyway. But what you have overlooked is that heap space is not the only resource you have to manage. There are various other types of resources (file handles, network connections, hardware interfaces, to name a few). So, ironically, the garbage collection approach in Java actually results in most types of resources becoming explicit in Java where they are, in essence, implicit C++.

I'm not saying that this is a huge problem, but it is something I find lacking when I develop in Java and other GC based languages.

moc exists only because older c++ compilers could not compile anything like boost's "signals2" library. Now every c++ compiler available supports templates enough to make moc redundant and silly. And in fact signals2 is more featureful than moc's signals and slots implementation.

--jeffk++

Unmanaged code might very well utilize garbage collection through compiler or library support.

That leaves the advantage of providing selective garbage collection in languages supporting manual memory allocation, which can leverage software architecture and performance.

Your statement, as well as the general notion of this thread, that writing code in languages enforcing global garbage collection, is faster or cheaper, is false. Given the situation of enforced vs selective garbage collection, I might even argue to the contrary.

Again, zero logic here. Boost is just another C++ library. It is not any more or less standard than Qt.

We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2.

Boost is more standard than Qt.

Combining of C++ and Python works really smoothly with Boost.Python. C++ objects can look and feel like Python objects, and vice versa.

Same here. The language looks fairly nice, but right now with ACE, Boost and Qt in my C++ toolbox, I'm doing alright. And I already develop, test, and deploy code that runs on MacOSX, Linux, Solaris, and supposedly Windows -- I have not actually tried there, but ACE, Boost, and Qt have abstractions that attempt to isolate developers from the OS. I'm curious if my Qt OpenGL stuff would work. I love using my Apple laptop for development. I'm more of an GNU Emacs fanboy than Apple (though I did buy a chunk of Apple back at $18 pre-split), so I do everything there, including having multiple shells open in it for command-line use. I even have a Platypus script that I can drag files onto and edit in GNU Emacs. I just take my GNU Emacs customization files to other platforms so I always have the same editing environment.

...Linux and OSX which run on several different and totally alien architectures.

Linux and OS X run on x86 just like MS Windows. I doubt Google will be releasing a PPC build for Mac or any of a number of other architectures available on Linux.

I agree with you about IPC not being the easiest cross platform thing to do. However, it is not terribly hard if you follow POSIX and wrap for Win32. As pointed out there are already cross platform IPC libraries like Boost and D-Bus, etc.

Chrome also relies heavily on inter-process communication (since each tab in each window has its own process). I'm betting good money that this is very hard to do properly cross-platform.

Not if it's already done for you.

Well, if it's for C++, why not using boost::thread instead?

``It is unfortunate that the mono is so closely associated with Windows, if the mono team had created/implemented a
completely new set of cross-platform libraries (that bore no relation to Microsoft's framework) it would be more accepted.''

But then they would just have done what various others have already done, wouldn't they?

C
    The GNU C Library
    http://www.gnu.org/software/libc/manual/

C++
    Standard Template Library Programmer's Guide
    http://www.sgi.com/tech/stl/

    Boost C++ Libraries
    http://www.boost.org/doc/libs

Java
    Java(TM) Platform, Standard Edition 6 API Specification
    http://java.sun.com/javase/6/docs/api/

Perl
    Perl version 5.10.0 documentation
    http://perldoc.perl.org/

Python
    Python Library Reference
    http://docs.python.org/lib/lib.html

For learning C and C++, I recommend these books:

    Kernighan, Ritchie: The C Programming language
    Kernighan, Pike: The Practice Of Programming
    Koenig, Moo: Accelerated C++: Practical Programming by Example
    Sutter, Alexandrescu: C++ Coding Standards

Standard Template Library:

• SGI reference - readable, comes with informative explanations of concepts
• libstdc++ reference - less readable, but it may have some non-standard things that aren't in the SGI docs, useful if you're using libstd++

Boost libraries:
For anything not present in the standard library, these are the next place to check. They're freely usable in commercial projects.

SGI's STL site is excellent, though I'm not not sure how up-to-date it is.

The C++ Programming Language , by Bjarne Stroustrup, is the only essential and authoritative language reference, other than the standard itself. It isn't a web site, but programming in C++ isn't something you pick up on a whim.

And of course Boost, the first place to look when you think, "There should be a library for this."

Theoretically, you are correct. But there is no time to read everything, especially when under pressure to finish a project on time.

Yeah, I'm just crazy that I read the boost docs for fun ;)

I am talking specifically about C++, which has most values allocated in the stack. That's the reason C++ produces the fastest code anyway.

The use of the stack in C++ is fairly limited. It's really only for small objects that can be passed around by value, and not for long-lived objects. Like I was saying, anything complex enough to have a non-trivial destructor is probably going to be too complex to be useful allocated on the stack.

The one great thing in C++, and the reason I don't give up on it, it's that destructors are called at procedure exit. That's so great! it helps with a lot of problems.

Well, that's the whole point of smart pointers. You get the EXACT same kind of determinism with your destruction, without having to use only local variables.

Your definition of RAII is wider than mine.

That's Bjarne Stroustrup's definition. He coined it as a general design pattern that should be used whenever possible.

Smart pointers are not for collections only. I am surprised that almost everyone has such a narrow scope, as if no one has ever made a complex program.

For example, in my current project...

Memory pools? Now clearly you know the project better than I do, but for situations like you describe, I don't think standard smart pointers OR garbage collection are really appropriate. Large scale allocation/deallocation of homogenous data types, that really sounds like something where you want all those resources in a pre-allocated memory pool that you can just draw from and release to at a whim with virtually no overhead compared to memory allocation in either system. Then again, maybe there are factors preventing the system being designed around memory pools? Anyway, that's certainly the solution I would choose given those criteria.

Well, I hope that after reading this last post of mine, you understand what kind of situation I am into. C++ is considered a systems language, and so our customers demand it. But their problems are big and complex, and if C++ had GC, the solutions would be better from all perspectives (faster coding, less debugging, less expensive, etc).

Is there a reason you can't use the very excellent Boehm garbage collector library for C++? Obviously if there's a reason your particular project will benefit from it, it might be worth considering. My argument is really only against how appropriate that functionality would be as a core feature of C++.

The nice thing about boost signals though is you can pass ANY functor (functions, member functions, function objects) through them

It goes without saying that function binding and lambda functions is THE most important feature of any programming language. I like boost for this, and I think it should be in the STL, but my comment was about how integrating boost with other libs may not be as easy as it sounds. Or any other two c++ libs, for that matter. You see, in C++, every toolkit/library/framework is its own universe.

Regarding your other post, while I'm not 100% sure what you're getting at, if it is what I think it is, then you are actually incorrect. See here. I can certainly understand being averse to Boost's smart pointer implementation if you weren't aware of this functionality.

Indeed, I was not aware of it. But the docs don't have it. Where I was supposed to find it? I went on and did my own implementation, complete with a SharedObject base class that does just this.

But then you're more or less defeating the entire point of garbage collection, which is not having to worry about manually releasing any resources when they go out of scope.

That's not the point of GC. The point of GC is to have complex object relationships, i.e. to manage memory, without worrying too much about how the memory is freed.

Once you start requiring that resources be manually deallocated before being let out of scope, you've just lost any real benefit of using a GC model in the first place.

Nope, you use RAII for that. You use RAII to manage resources deterministically, except for memory.

Sure GC *can* work with non-trivial destructors, but in doing so you lose the real benefits you've gotten from GC in the first place, which is why I claim that smart pointers are actually much more suited to such a situation because they retain that same benefit.

No, you don't lose anything. With GC, you can do things like circular references and stuff without having to think about them. And a whole bunch of other stuff smart pointers can't do. And then there is the problem of performance: all those increments and decrements that are also atomic put a serious constraint in performance.

I do concede that cyclic references are the weakest aspect of smart pointers, and do require a little more work in the design of your software to avoid them. I will admit though, if you have a situation where cyclic references are legion, then GC might be a superior choice. With limited cyclic references, however, weak smart pointers are a perfectly elegant solution. It's usually obvious from a design perspective which pointers should be made weak.

Ok, smart pointers are not that bad. In my current project, around 50,000 lines of code, I don't have any deletes. But I had to be really careful not to introduce any cyclic references. And the performance is not what it could have been. There are lost CPU cycles in atomic increments and decrements. And the code is on the ugly side...

That is, until you try to combine it with other libraries, like Qt, for example. Boost has a namespace signals, Qt has a #define signals. Yes, you can solve the problem using the preprocessor, but boost was supposed to be 'plug-n-play'...

That's really the case with any situation where you have two libraries which implement the same functionality though. It's hardly a problem that's confined to Boost, or even C++. The nice thing about boost signals though is you can pass ANY functor (functions, member functions, function objects) through them.

Smart pointers are difficult to manage in the context of complex object relationships. See my other post for more info.

Regarding your other post, while I'm not 100% sure what you're getting at, if it is what I think it is, then you are actually incorrect. See here. I can certainly understand being averse to Boost's smart pointer implementation if you weren't aware of this functionality.

The idea that destructors don't play well with GC is largely a myth. Non-trivial jobs should not be done in destructors. But even if they are done in destructors, they should be invoked using RAII style. The destructor is only a function, so it can be called normally just like any other C++ function.

But then you're more or less defeating the entire point of garbage collection, which is not having to worry about manually releasing any resources when they go out of scope. Once you start requiring that resources be manually deallocated before being let out of scope, you've just lost any real benefit of using a GC model in the first place. Sure GC *can* work with non-trivial destructors, but in doing so you lose the real benefits you've gotten from GC in the first place, which is why I claim that smart pointers are actually much more suited to such a situation because they retain that same benefit.

As I explain in my other post, the problems of cyclic references introduced indirectly, the situation where you only have 'this' and you should use shared_ptrs, etc are great problems and you should not underestimate them.

I do concede that cyclic references are the weakest aspect of smart pointers, and do require a little more work in the design of your software to avoid them. I will admit though, if you have a situation where cyclic references are legion, then GC might be a superior choice. With limited cyclic references, however, weak smart pointers are a perfectly elegant solution. It's usually obvious from a design perspective which pointers should be made weak.

1. you are partially wrong:
here's the compression http://www.boost.org/doc/libs/1_36_0/libs/iostreams/doc/classes/gzip.html
and URL fetching is coming with the network lib (http://cpp-netlib.blogspot.com/) which aims to be included in the next release.
2. I had to many troubles with dynamically typed languages. I would (IMHO!) not take that as a plus.
3. There's no silver bulled with respect to reference counting. Each techniques has pro and cons.

And I do write web services (or services used by web app.) all the time using facebook's thrift, and CPU is critical for us. Hell, I would not even use java for it!

But as usual it depends a lot on what you need.

P.s. Adobe wrote also a speed critical image library which is now part of boost (http://www.boost.org/doc/libs/1_36_0/libs/gil/doc/index.html)

From the boost multi-index tutorial: typedef multi_index_container< employee, indexed_by< ordered_unique<identity<employee> >, ordered_non_unique<member<employee,std::string,&employee::name> >, hashed_unique<member<employee,int,&employee::ssnumber> > > > employee_set

Ok, so I hadn't realized that my dev environment included boost until about a week ago, and am still coming up to speed on boost. I echo the GP's concerns (I've largely been a Java developer), and am examining the boost documentation as we speak.

The other issue I take with general C++ development is documentation. I've been fairly spoiled by Javadoc over the years, and while I know things like Doxygen exist, they aren't widely used for the C++ language (to my knowledge). A brief examination of the boost libraries, however, yields a wealth of documentation. I'm quite impressed!

Let me say this. The "Smart Pointers" defined as part of the boost library look fantastic. I'm going to incorporate them as we speak. Have a look at the examples, they really are useful.

I have never seen Boost used in an established commercial C++ product so far[...]

Have you seen this? http://beta.boost.org/users/uses_shrink.html

go look on Sourceforge[...]

Do you know how much time Debian guys spend in testing every new release of C++ Boost to make sure that it works well with all the Debian applications that depend on it?

Boost is created and maintained by, among other people, the people who created and maintained the C++ STL.

Well, yes and no. Although Boost was begun by members of the C++ Standards Committee Library Working Group, participation has expanded to include thousands of programmers from the C++ community at large.

And of course, the STL was originally developed independent of C++ by Alex Stepanov and Meng Lee. When Stepanov was first throwing around the underlying ideas, C++ didn't even have templates yet.

If by "on more than the bleeding edge platforms" you mean "on something other than MSVC," then yes. Microsoft's compiler was tremendously shitty when it came to standards conformance until .NET 2003 edition (I believe).

Your prejudice is showing. Visual C++ has pretty consistently been among the most standard-compliant compilers since forever. It fell behind a little in the early 2000s, since VC++6 was actually released before the C++ standard was finalised, but remember that we're talking about the GCC 2.95 days there, and the average UNIX platform compiler wasn't even on the chart at that point.

You're definitely a Windows developer, aren't you? You're just suffering from the fact that Boost isn't really built with or for MSVC, and the Windows development process is very non-standard with respect to every other OS out there.

Irony #1: My C++ code probably gets compiled on more platforms than code written by most, maybe even all, of the other participants in this discussion.

Irony #2: While Windows may be the "odd one out" relative to the Linux world, the Visual C++ command line compiler and makefiles pretty much work like every other platform.

Irony #3: Visual C++ is the only compiler on which I have actually seen real world code that makes extensive use of Boost compile properly out of the box.

As for the licensing terms, this is the boost software license. It is three (short) paragraphs long.

It doesn't matter what it says. There is a licence, which imposes a restriction. That in itself it enough to trigger a need for approval by the legal people in many companies.

Should I mention the fact that boost is the code base for much of the additions to the next generation of the C++ STL? I know templates can be big and scary, but really...

Do you think adding substandard lambda expressions and a funky parser library using template wizardry are more important than providing, say, standard facilities for working with networking, database interaction, heck, even console I/O? This is what the C++ in-crowd have brought us: an emphasis on using clever tricks to provide facilities that still aren't as good as what numerous other languages do anyway, instead of plugging gaping holes in the basic provisions of the standard library. I don't have anything against templates (well, not on this scale, anyway) but I do have a big problem with directing an entire development community's efforts towards overcoming mostly self-made problems with templates and the rest of C++ rather than getting the basics into the state they should have been in ten years ago.

Boost is created and maintained by, among other people, the people who created and maintained the C++ STL.

If by "on more than the bleeding edge platforms" you mean "on something other than MSVC," then yes. Microsoft's compiler was tremendously shitty when it came to standards conformance until .NET 2003 edition (I believe). Not to mention that only applies to the more esoteric libraries (like lambda functions and spirit), and boost is quite modular so you could still use the parts that did work.

never mind trying to fight through the mess that is getting Boost installed and running these days and spending time getting lawyers to review the licensing terms

You're definitely a Windows developer, aren't you? You're just suffering from the fact that Boost isn't really built with or for MSVC, and the Windows development process is very non-standard with respect to every other OS out there. On my system installing boost is a process that consists of all the "mess" of executing ONE terminal command ('pacman -S boost' and when it gets done Boost is installed and ready to use).

As for the licensing terms, this is the boost software license. It is three (short) paragraphs long. Stick to the libraries that are covered by that license (most of them) and you won't have any trouble. If you need more libraries than that, I'm not aware of any that have meaningfully complex licenses.

Should I mention the fact that boost is the code base for much of the additions to the next generation of the C++ STL? I know templates can be big and scary, but really...

I consider that really sad. For the most part, since about 2004 or 2005 compilers have been perfectly fine for Boost. If most shops are still wondering about this, most shops are using dreadfully old development tools.

That being said, I haven't done any really serious C++ development work since early 2006. I now consider C++ to be the language to go to when Python is just too slow for something. And for that there's Boost.Python.

Though, I'm starting to get interested in intensive parallelization and Python is seriously lagging in good multithreading support.

Sure you can wrap up the c handlers in c++ objects which then have automagic destructors, but that is a lot of extra layers and code just to get around using a goto.

I apologize for the lack of indentation, I just couldn't get it right.

You don't even need to create a new class if you don't want to, and the setup and teardown are right next to each other, so you don't have to scan down to the bottom of the function to be sure you cleaned up after yourself (goto or no).

1. scope guard: http://www.ddj.com/cpp/184403758
2. boost::bind: http://www.boost.org/doc/libs/1_35_0/libs/bind/bind.html

Does he need to? Boost has support for various smart pointer classes that should handle everything you need:

http://www.boost.org/doc/libs/1_35_0/libs/smart_ptr/smart_ptr.htm

You don't *need* a garbage collector if you have a reference counted smart pointer to manage memory within scopes. The point here is that you can choose whichever memory management scheme you like if it is part of a library. If you want a special allocator, write (or select) one.

We needed this once, several highly-preallocated memory heaps, it made a tremendous impact on performance at the expense of memory consumed. It fitted our needs, something you'd never see in a general-purpose allocator.

The language is overly complex. The key advice any C++ expert is "restrict yourself to a specific subset of C++". That's the bulk of the difficulty. If C++ were simplified to include only that subset, you'd have a lot less need for training

And less libraries. A key C++ feature is facilities for library providers to make types that behave as if they were built in. Even though the application developer doesn't use these facilities directly, if taken away the libraries would go with them. It is of great value to be able to effectively extend the language for specialized domains, just by writing (or having someone experienced) write a library. Boost is a great example of what is possible.

This does not affect the users directly, but it is a major pain for integrators/porters. OO.o has a terrible habit of bundling all of the 3rd-party software packages, that it uses, into its own source tree. I'm talking about (probably missed some):

• agg
• bash
• bitstream-vera
• bsh
• bison
• boost
• curl
• db42
• dmake
• expat2
• freetype
• icu
• jpeg
• firefox (or some other Mozilla-based browser)
• libmspack
• libsndfile
• libtextcat
• libwpd
• libxslt
• neon
• nss
• nspr
• python
• sane-backends
• STLport
• unixODBC
• unzip
• vigra
• xmlsec1
• xt
• zip
• zlib

If they could, I'm certain, they would've bundled Java too, but — fortunately — Sun's license prohibits that... Now I realize, that this is done to offer "a single package" to those, who build it on their own, but nobody does. Everybody gets these from their OS' integrators. And the pain for us is enormous, because to force OO.o build to stop its silly ways is a serious undertaking. For some of the above packages there is --with-system-foo configure-flag, but not for all, and the default is to always use the bundled one, so support for the external ones bitrots quickly...

Most of the local builds don't bother and so end up wasting disk space and CPU-time rebuilding packages, which are external to OO.o. The end results are also bloated, duplicating stuff, that's already installed on the users' systems and without bug-fixes, which have already gone into each of the respective package since its most recent "bundling" into OO.o tarballs.

Download a source tarball and see for yourself... Something like: tar tjf OOo_OOG680_m9_source.tar.bz2 | grep 'z$'. No other software project does this on this scale and for good reasons — it is Just Wrong[TM]. OO.o better clean up their act in this respect...

It has been said by some other developers that the malloc/fwMalloc is being used from within the actual processing functions.

Memory allocation calls are expensive performance-wise. Please consider to create a few other house-keeping calls to be used before using the actual processing functions:
The house-keeping calls would be responsible for:
1)creating an object_pool which is a memory pool that can hold only objects of the same type as specified by ElementType
allocating the memory in the respective memory pool to hold an initial number of same-type objects
2)The actual number of pools to initially create would map to the number of types used in the library.
The actual number of objects to create in each type would depend on the average maximum number of elements used in each of the framewave API calls.
Here are the types I have identified for candidate pools:
Fw16s Fw16sc Fw16u Fw32f Fw32fc Fw32s Fw32sc Fw32u Fw64f Fw64fc Fw64s Fw64sc Fw64u Fw8s Fw8u
FwStatus FwLibraryVersion FwRoundMode FwWinType FwBool FwCmpOp FwCpuType FwHintAlgorithm

3)Single-Threaded and Multi-threaded should follow the same strategy because for each thread there should be a unique pools of memory for all of the above types anyways.
To make all of this easier, one could write a new class/template holding all the above with your initial respective pool sizes and just pass this one higher-level object to all the other api's and grab the respective thread's pools/elements when you need them with indirection.

The c++ memory pool api already exists:
http://www.boost.org/libs/pool/doc/index.html

I do hope this helps.

then a crazy pointer math or memory management in C/C++.

Nobody bothers with that anymore. Go check STL and Boost for your programming needs.

What sort of memory management would you prefer to have? Garbage collected? There are good garbage collection libraries available. "Smart" pointers? There are more libraries for minutely varying shades of that than I think I could count. That's what I, for one, like about the language.

For example, I do a lot of graphics/game programming as a hobby. For that, Garbage collected memory is really inappropriate (for a number of reasons, but most of all the need to release memory immediately with graphics hardware). On the other hand, sometimes I will code up a quick utility for home/work, and can just link in a garbage collection library to make things easy on me. I like the flexibility without having to constantly switch languages.

For reference:
Garbage Collector that I like.
Smart Pointer implementation that's good and general purpose. Roll your own if you want something more specific.