470,849 Members | 1,196 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

c++ compilation issues

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.
Jun 27 '08 #1
7 1107

"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
Jun 27 '08 #2
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
Jun 27 '08 #3
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
Jun 27 '08 #4
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 :)
Jun 27 '08 #5
On May 14, 10:08 am, Anees <anees.hai...@gmail.comwrote:
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, +33 (0)1 30 23 00 34
Jun 27 '08 #6
On May 14, 9:38 am, "Alf P. Steinbach" <al...@start.nowrote:
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, +33 (0)1 30 23 00 34
Jun 27 '08 #7
On May 14, 11:26*am, James Kanze <james.ka...@gmail.comwrote:
On May 14, 9:38 am, "Alf P. Steinbach" <al...@start.nowrote:
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
Jun 27 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Steven T. Hatton | last post: by
2 posts views Thread by KN | last post: by
reply views Thread by hypnotik | last post: by
5 posts views Thread by Nick Gilbert | last post: by
1 post views Thread by hamardk | last post: by
17 posts views Thread by somenath | last post: by
1 post views Thread by Roumen Petrov | last post: by
82 posts views Thread by raashid bhatt | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.