[Coin-discuss] Bug Report in PackedVectorBase

[Leo Lopes]

Thanks! We'll test it this week.

Cheers,
Leo.

Laszlo Ladanyi wrote:

>I have moved things a bit around, now things should work with MSVC 2003 as
>well.
>
>--Laci
>
>On Sun, 5 Oct 2003, Leo Lopes wrote:
>
>  
>
>>Hi Laszlo,
>>
>>    I think I started my msg incorrectly, by even bringing up whether or 
>>not compiler A or B was at fault. I apologize for that. The question you 
>>brought up about how to deal with ANY compiler's bugs is an important 
>>one. My 2c on that is to treat each situation individually. The argument 
>>for that approach is that these days, almost always all that is required 
>>are very simple changes. Furthermore, the result is often code 
>>improvement, and sometimes when you are lucky even design improvements. 
>>At least that has been my experience.
>>
>>    For this particular issue, I agree with your solution. I think that 
>>the binaryOp methods as they are now don't belong in PackedVectorBase. 
>>My (strictly academic, I admit) simplest arguments for that are: a base 
>>class should not have any knowledge about a derived class; and a method 
>>should not be used in a file if it isn't defined in that file or in a 
>>file included from that file.
>>
>>    BTW, Kipp Martin tells me that with the changes I sent you COIN 
>>compiles cleanly and works on MSVC 03.
>>
>>
>>Cheers,
>>Leo.
>>
>>Laszlo Ladanyi wrote:
>>
>>    
>>
>>>Hi Leo,
>>>
>>>Actually, I believe that MSVC 2003 is at fault. The binaryOp methods are
>>>templated methods and the compiler has no business in compiling them until it
>>>knows the template arguments. What I think is that MSVC 2003 tries to be
>>>clever and precompile those parts of the method that do not depend on the
>>>template argument. But that's a problem with the compiler. Also, Sun's CC,
>>>IBM's xlC, HP's aCC compile the code without any problems...
>>>
>>>This raises the issue of how do we deal with bugs in Microsoft's compilers?
>>>(The question is valid regardless of whether MSVC 2003 is at fault now or
>>>not.) To get wide audience, we need them to compile our code. But that would
>>>be sort of letting the bully to win. (The bully's compiler is faster, but only
>>>because it cheats on the rules, but we can't do anything about it, so we
>>>conform...)
>>>
>>>In this particular case moving binatyOp into the PackedVector class is not the
>>>right solution either. If we did that we couldn't use ShallowPackedVectors in
>>>binaryOps.
>>>
>>>A possible solution would be to move binaryOp into CoinPackedVector.hpp as a
>>>templated function (not a method in PackedVector. This actually makes sense,
>>>after all, the does function return a PackedVector...
>>>
>>>What do people think? (On both questions.)
>>>
>>>--Laci
>>>
>>>On Sat, 4 Oct 2003, Leo Lopes wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Dear Laszlo,
>>>>
>>>>	I was having trouble compiling the basic COIN library under the newest 
>>>>VS .net (I know, I know), and I noticed you were the last to update 
>>>>CoinPackedVectorBase and CoinPackedVector. I'd like to point out a 
>>>>feature of that code that is causing a problem. It is on lines 164, 182, 
>>>>and 200, and the couple of lines following each case. MSVC 2003 
>>>>complains about this code even though gcc and the previous MSVC don't, 
>>>>and I think at least this time MSVC 2003 is right.
>>>>
>>>>	The problem is the following: when compiling PackedVectorBase, a 
>>>>compiler has no way of knowing that PackedVector has a 
>>>>setTestForDuplicateIndex method. It doesn't know, at this point, that 
>>>>PackedVector is a child of PackedVectorBase. My guess is that the code 
>>>>as it is now only works in gcc and the old MSVC because of the mechanism 
>>>>that gcc and MSVC use to implement templates.
>>>>
>>>>	I changed PackedVectorBase and PackedVector so that any references to 
>>>>PackedVector are removed from its parent, PackedVectorBase. This 
>>>>involved moving the binaryOp functions to PackedVector and changing some 
>>>>signatures. This allowed the Coin library ato compile cleanly under MSVC 
>>>>and gcc and Clp to compile cleanly under gcc. I haven't tried other 
>>>>libraries/compilers combinations yet.
>>>>
>>>>	The sources I am sending you are not changes of the absolute newest 
>>>>versions in the CVS. However the same holds true of those versions.
>>>>
>>>>Cheers,
>>>>Leo.
>>>>
>>>>Laszlo Ladanyi wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>I think I caught all memory problems. At least now valgrind is quiet. It
>>>>>wasn't too bad, various pointers got deleted multiple times. I think there are
>>>>>memory leaks left. I'll try to deal with them over the weekend or early next
>>>>>week.
>>>>>
>>>>>All the changes are committed. 
>>>>>
>>>>>Thanks for the bug report!
>>>>>--Laci
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Coin-discuss mailing list
>>>>>Coin-discuss at www-124.ibm.com
>>>>>http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>-- 
>>>>=======================================================================
>>>>Leonardo B. Lopes                                   leo at sie.arizona.edu
>>>>Visiting Assistant Professor                              (520)626-1780
>>>>SIE - University of Arizona
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>-- 
>>=======================================================================
>>Leonardo B. Lopes                                   leo at sie.arizona.edu 
>>Visiting Assistant Professor                              (520)626-1780
>>SIE - University of Arizona
>>
>>
>>
>>    
>>
>
>_______________________________________________
>Coin-discuss mailing list
>Coin-discuss at www-124.ibm.com
>http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
>  
>

-- 
=======================================================================
Leonardo B. Lopes                                   leo at sie.arizona.edu 
Visiting Assistant Professor                              (520)626-1780
SIE - University of Arizona