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.

[Mike Wahler]

"Anees" <an**********@gmail.comwrote in message
news:5c**********************************@d45g2000 hsc.googlegroups.com...

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 *>.

Please show minimum code that produces the error.
And just in case it's a compiler issue, tell
which one you're using.

-Mike

[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

[Paavo Helde]

Anees <an**********@gmail.comwrote in news:5cb64015-ebb9-467c-9992-
48**********@d45g2000hsc.googlegroups.com:

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();

Sounds like some macro trickery. You can try to put

#undef clear

before that line. If this works then you should find out, where this macro
is defined, why it is defined and what to do about it. There are probably
other macros as well.

hth
Paavo

[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]

On May 14, 10:08 am, Anees <[e-mail]:

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On May 14, 9:38 am, "Alf P. Steinbach" <[e-mail]:

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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[gpderetta]

On May 14, 11:26*am, James Kanze <[e-mail]:

On May 14, 9:38 am, "Alf P. Steinbach" <[e-mail]:

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.

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.

--
gpd

--
gpd