Home Bug Reports

More solaris template problems

marlowamarlowa Member Andrew MarlowOrganization: Wellabove LtdProject: study into feasibility of ice on WINCE project ✭✭
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.

Comments

  • matthewmatthew NL, CanadaMember Matthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications Engine ✭✭✭
    Working around all these compiler differences is always a pain :( Thanks alot for the report. We'll adjust the source accordingly.

    Regards, Matthew
  • rodrigcrodrigc Member
    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/docs/xml/bobcat/html/threadsref/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.
  • marlowamarlowa Member Andrew MarlowOrganization: Wellabove LtdProject: study into feasibility of ice on WINCE project ✭✭
    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
  • marlowamarlowa Member Andrew MarlowOrganization: Wellabove LtdProject: study into feasibility of ice on WINCE project ✭✭
    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
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    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
  • marlowamarlowa Member Andrew MarlowOrganization: Wellabove LtdProject: study into feasibility of ice on WINCE project ✭✭
    Originally posted by marc

    BTW, there is no attachment.

    -- Marc

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

    -Andrew
  • marlowamarlowa Member Andrew MarlowOrganization: Wellabove LtdProject: study into feasibility of ice on WINCE project ✭✭
    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=&hl=en&lr=&ie=UTF-8&threadm=b429n7%241q6vtf%241%40ID-136218.news.dfncis.de&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.std.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.
Sign In or Register to comment.