More solaris template problems

[marlowa]

Another problem with Forte 6.2 building Ice on Solaris. Ice has a template class called Lock but several classes define a typedef called Lock which uses the template Lock, e.g we have typedef Lock<RecMutex> Lock. Forte does not like this. I must admit, I'm not keen either. I had to change the name of the template lock class. Once it was called Lock_tmpl it compiled ok. The affected header files are:

include/IceUtil/Lock.h
include/IceUtil/Mutex.h
include/IceUtil/RecMutex.h
include/IceUtil/RWRecMutex.h

I am not sure if this is a compiler bug; I have posted a query to comp.std.c++.

Regards,

Andrew M.

[matthew]

Working around all these compiler differences is always a pain Thanks alot for the report. We'll adjust the source accordingly.

Regards, Matthew

[rodrigc]

comp.std.c++ is the wrong place to post for this kind of thing,
since Lock is not Standard C++.

You are better off posting to some place like
comp.lang.c++.moderated

or a forum that is specific to Sun Forte C++.

If I recall, Sun Forte comes with libraries from RogueWave
including Tools.h++ and RogueWave's implementation of STL.

Does it look the the problems you are encountering are due to any of the
classes mentioned in RogueWave's synchronization library?

http://www.roguewave.com/support/doc...dsref/2-7.html

I'm not sure if RogueWave's STL implementation uses Tools.h++ for
thread synchronization.

If you look around the header files that come with your compiler,
that might yield some clues.

[marlowa]

Originally posted by rodrigc
comp.std.c++ is the wrong place to post for this kind of thing,
since Lock is not Standard C++.

You are better off posting to some place like
comp.lang.c++.moderated
.

Pardon me but comp.std.c++ is exactly the right NG to post to on questions of std conformance, and I got a reply too. The Forte compiler is wrong. This satisifies my curiousity but we will of course have to change the Ice code to make it acceptable to the Forte compiler.

-apm

[marlowa]

Originally posted by matthew
Working around all these compiler differences is always a pain :( Thanks alot for the report. We'll adjust the source accordingly.

Regards, Matthew

I have tried to build Ice 1.0.1 and I am sorry to say that the source has not been adjusted correctly. The header RWRecMutex.h needs to be changed so that we do not have

typedef RLock<RWRecMutex> RLock;
typedef TryRLock<RWRecMutex> TryRLock;
typedef WLock<RWRecMutex> WLock;
typedef TryWLock<RWRecMutex> TryWLock;

The other changes were made ok.

The fixed file is attached.

Regards,

Andrew

[marc]

Originally posted by marlowa
I have tried to build Ice 1.0.1 and I am sorry to say that the source has not been adjusted correctly. The header RWRecMutex.h needs to be changed so that we do not have

typedef RLock<RWRecMutex> RLock;
typedef TryRLock<RWRecMutex> TryRLock;
typedef WLock<RWRecMutex> WLock;
typedef TryWLock<RWRecMutex> TryWLock;

The other changes were made ok.

The fixed file is attached.

Regards,

Andrew

Sorry for that. It's difficult to make such changes without having the software to test them against. (But as I wrote before, a Solaris system has been ordered, so soon we can test this for ourselves.)

BTW, there is no attachment.

-- Marc

[marlowa]

Originally posted by marc

BTW, there is no attachment.

-- Marc

Hmmm, very strange. I have emailed it to you.

-Andrew

[marlowa]

Originally posted by marlowa
Pardon me but comp.std.c++ is exactly the right NG to post to on questions of std conformance, and I got a reply too. The Forte compiler is wrong. This satisifies my curiousity but we will of course have to change the Ice code to make it acceptable to the Forte compiler.

-apm

I have been following the thread on comp.std.c++ (http://groups.google.com/groups?dq=&...td.c%252B%252B) and there have been some interesting developments. Consensus is that the the construct is wrong according to section 3.3.6/1 but the std says that a diagnostic is not required. This unfortunately makes things very unclear. I recommend that in general this construct is best avoided, due to the issue being unclear in the std. One could argue that both GCC and Forte conform but in different ways!

Regards,

Andrew M.