const confusion between gcc / VS2005
Confused about why this error is showing up.
I've got the following code in VS2005 working fine.
class NastranModel
{
...
private:
set<BulkDataFile> bulkDataFiles;
}
BulkDataFile & NastranModel::getBDF(const string & filename)
{
BulkDataFile in(filename, false);
set<BulkDataFile>::iterator itr = bulkDataFiles.find(in);
return *itr;
};
So then when I port it over to Redhat using:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 7.3 3.2-7)
I get the following error
NastranModel.cpp: In member function `BulkDataFile& NastranModel::getBDF(const std::string&)':
NastranModel.cpp:375: could not convert `(&itr)->td::_Rb_tree_iterator<_Val, _Ref, _Ptr>:: operator*() const [with _Val = BulkDataFile, _Ref = const BulkDataFile&, _Ptr = const BulkDataFile*]()' to `BulkDataFile&'
I'm not sure what is causing the problem. is it the const after operator*()?
why would this pass on VS but not gcc?
I tried with and without -ansi flag when compiling. VS tells me that there are 2 version of find (const and non const).
Could it be the g++ compiler is out of date?
-------------------
also, is there a better way to use find?
I'd like to find an object in the set with a name that matches the string input.
However, find expects the key to be of the same type as what is contained in set. So I'm creating a dummy obj right now. There's got to be a better way?
[1896 byte] By [
rssmps] at [2007-11-11 10:23:57]
# 1 Re: const confusion between gcc / VS2005
nastranfcn.h: In function `void assignElementWithAllGridTouching(const std::vector<element, std::allocator<_CharT> >&, const std::vector<TypeGRID, std::allocator<TypeGRID> >&, std::vector<element, std::allocator<_CharT> >&)':
nastranfcn.h:237: warning: `typename std::vector<element, std::allocator<_CharT> >::const_iterator' is implicitly a typename
nastranfcn.h:237: warning: implicit typename is deprecated, please see the documentation for details
more strange warnings ... since when was iterators deprecated?
rssmps at 2007-11-11 20:59:00 >
# 2 Re: const confusion between gcc / VS2005
the iterator wasnt, the implicit typedef is.
I dont see anything for it to choke on, but historically, gcc has been more right than VS when it comes to some strange detail of c++. Not always, but usually. Two places g++ hose up are signed ints with logic operations (vs gets these correct, from a bitwise standpoint, and gcc gets them correct from a "you cant do logic on a sign bit" standpoint, I argue that VS is correct as, at the bit level, there is no such thing as sign). Also, you cant in G++ have a namespace with the same name as whats inside it but you can in VS. Here, g++ is more likely correct as this is just too confusing a construct to have in your code, shouldnt be allowed.
jonnin at 2007-11-11 20:59:55 >
# 3 Re: const confusion between gcc / VS2005
VS is notorious for issuing spurious warnings that are utter nonsense. I'm very certain that iterators have never been deprecated (neither have standard C functions, STL algorithms etc. these all produce that silly warning). The purpose of this spurious warning is to force user to use MS proprietary functions, classes and concepts such as checked iterators. These aren't worth the trouble and they are pretty slow. So, with respect to the deprecation warning (BTW, I dedicated long diatribes to this on Informit. You can find it there), simply disable this warning.
As for the set warning: I think sets store only keys, not valus so you need search for a similar key. Try to replace set with map (or vector).
Danny at 2007-11-11 21:01:05 >
# 4 Re: const confusion between gcc / VS2005
Danny, on VC there is NO warnings, only on GCC!
Radius at 2007-11-11 21:02:05 >
# 5 Re: const confusion between gcc / VS2005
Not sure if this is the best way to do this or not but to have it compile, I added this
return const_cast<BulkDataFile &>(*itr);
rssmps at 2007-11-11 21:02:59 >
# 6 Re: const confusion between gcc / VS2005
wow, this cross platform thing is much more painful than I thought.
I thought I'd done a pretty good job in keeping everything as plain as possible...
so what passed on VS2005 and Linux(gcc 3.2) now fails on AIX (gcc 4.11)
and it's not even anything complex.
nastranfcn.h: In function 'std::string convertConsecutiveSetToStr(std::set<element, std::less<_Key>, std::allocator<_CharT> >&)':
nastranfcn.h:20: error: expected `;' before 'beg'
nastranfcn.h:21: error: 'beg' was not declared in this scope
nastranfcn.h:22: error: expected `;' before 'end'
nastranfcn.h:23: error: 'end' was not declared in this scope
nastranfcn.h:24: error: expected `;' before 'itr'
nastranfcn.h:24: error: 'itr' was not declared in this scope
the code in question is:
template<class element>
string convertConsecutiveSetToStr(set<element> & ids)
{
stringstream output;
set<element>::iterator beg;
beg = ids.begin();
set<element>::iterator end;
end = ids.begin();
for(set<element>::iterator itr = ids.begin(); itr!=ids.end(); )
{
++itr;
if(itr!=ids.end()&&(*itr-*end)==1)
{
// next value is consecutive so move end to current
end = itr;
}
else
{
// next value is nonconsectuive
if(beg==end)
{
// same value so only output once
output<<*beg<<",";
}
else
{
output<<*beg<<":"<<*end<<",";
}
if(itr!=ids.end())
{
beg = end = itr;
}
}
}
return output.str().substr(0,output.str().length()-1);
}
I'm at a loss as how to fix the problem... what's wrong with the iterator declaration?
rssmps at 2007-11-11 21:03:58 >
# 7 Re: const confusion between gcc / VS2005
Did you #include <sstream> ? It seems like AIX doesn't recognize stringstream.
Danny at 2007-11-11 21:05:07 >
# 8 Re: const confusion between gcc / VS2005
yup, got the sstream included
I think I found the problem.
Since 3.2 complained as an warning and 4.11 rejected completely, I looked into what was going on with the iterator.
after looking up implicit typedef, it seems the standards have changed?
I had to change the iterators defintion as follows:
typedef typename set<element>::iterator SetIterator;
SetIterator beg = ids.begin();
if it is in the cpp file,
typedef set<element>::iterator SetIterator;
SetIterator beg = ids.begin();
rssmps at 2007-11-11 21:06:10 >
