c++ compilation issues

[Anees]

Hi,

I am using vector in my program, when i try to compile the program I
am getting following error:

'class std::vector<Dt *, std::allocator<Dt *> >' has no member named
'wclear'

pointing to the line:

vt.clear();

where Dt is a class, vt is an vector<Dt *>.

thanks.

 

[Anees]

I am using g++ as compiler on solaris 10.

I have narrowed down the issue:

My C++ program is using lagacy c custom libraries. when i comment out
those header files and related functions, the program compiled
successfully. Please guide me how to use those lagacy c header files
and its its functions.

Thanks.

-Anees

 

[Anees]

Problem is solved.

I removed the lagacy c header file from include, instead declared the
function(s), I am using from that header, in:

extern "C" { //functions
}

block. It compiled successfully.

Thank you all for help

 

[James Kanze]

Problem is solved.

I removed the lagacy c header file from include, instead declared the
function(s), I am using from that header, in:

extern "C" { //functions

block. It compiled successfully.

But you might end up with problems linking, if you use the
functions, but they are macros in the C library. Alf gave a
fairly good hint as to what you have to do: define a class to
wrap the library, and define it in a way so that the 1) the
headers for the library are only needed in the implementation of
the class (using the compilation firewall idiom, if necessary),
and 2) the implementation of the class doesn't use the standard
library headers.

 

[James Kanze]

For basic PIMPL you can use e.g. boost::shared_ptr (not std::auto_ptr).

boost::shared_ptr doesn't have the correct semantics for a
compilation firewall. The Boost pointer with the correct
semantics would be boost::scoped_ptr, but I think it suffers
from the same problem as std::auto_ptr. And of course, just
aobut any smart pointer is really just introduces extra
complexity for nothing. (Unless you want to support copy and
assignment, in which case, a deep copying pointer might make
sense, if you've got one.)

 

[gpderetta]

boost::shared_ptr doesn't have the correct semantics for a
compilation firewall.

Why not?

If your object is non copyable, it work just fine.
If your 'pimpled' object, you won't use the 'shared' part
of shared_ptr, but it will work just fine (you may argue that it is
over-engineered
and a bit wasteful for this particular problem).

If your object is shallow copyable, it also works fine (I know you
prefer
GC, but it might still make sense if your object holds non-memory
resources).

Of course, for deep copyable objects one needs to look elsewhere.