[Dune] [Dune-Commit] dune-grid r5015 - trunk/grid/test

[Andreas Dedner]

Nevertheless a define to really remove all old methods seems a good
idea.
Andreas

Martin Nolte wrote:
> You're right, the old methods can now be marked deprecated, since the new ones 
> are implemented. Note that index sets / id sets use the Barton-Nackman trick (or 
> whatever this thing is really called) declare the interface. Therefore, the user 
> usually deals with the implementation rather than the interface and might not 
> get a deprecated warning unless the implementation also declares this method 
> deprecated.
>
> Moreover, I would like to clear up the rumour that gcc cannot deprecated 
> template methods. This is _not_ true. There is a bug in gcc that prevents the 
> parser from correctly handling deprecation _if_ you put it at the end of the 
> declaration. _But_ you can put it in from of the method name and it will 
> perfectly work.
>
> Martin
>
>
>
> Carsten Graeser wrote:
>   
>> Hi.
>> For a painless transition there are now two different interfaces using
>> different local indices. Mixing both is very dangerous and might lead
>> to the problem that the code runs, but simply produces wrong results
>> (which was intendet to be avoided by the renaming).
>>
>> Thus I suggest additionally to immediate deprecation of the old methods
>> to surround ALL of them by
>>
>> #ifndef DUNE_DISABLE_OLD_LOCAL_INDICES
>> [...]
>> #endif
>>
>> This allows to check if old indices are still used and is especially
>> necessary since member template deprecation does not work with gcc.
>>
>> Carsten
>>
>>
>> Oliver Sander schrieb:
>>     
>>> Hi Martin!
>>>       
>>>> as far as I remember the decision in Heidelberg (and I understand that 
>>>> Christian remembers the same), the old template method is to be 
>>>> deprecated and removed post 1.3.
>>>>         
>>> Well, great, let's do it!
>>>       
>>>> What confuses me is that you were one of the guys who wanted a hard 
>>>> break in the numbering while you have to change a lot of code. Anyway, 
>>>> I never wanted to offend you; my interest lies solely in a consistent 
>>>> interface. I'm in no way against discussions. But in this case a 
>>>> discussion started over things that we decided upon and the discussion 
>>>> seemed to weaken the interfaces consistency in quite a critical point, 
>>>> namely the subentity numbering.
>>>>         
>>> Apparently a misunderstanding triggered by my weak memory.  Apologies.  
>>> Let's just
>>> continue the transition.
>>>       
>>>> Personally, I would have deprecated the old subIndex / subId methods 
>>>> already. The problem is that many grids don't support the replacement, 
>>>> yet, so people cannot change their code to the new implementation.
>>>>         
>>> In dune-grid it's really only SGrid and YaspGrid.  The ALU-Hack could 
>>> applied there as well
>>> with little effort.
>>>
>>> --
>>> Oliver
>>>
>>>       
>>>> Maybe we should add FlySpray tasks for all the grids that don't 
>>>> support these methods, yet...
>>>>
>>>> Yours,
>>>>
>>>> Martin
>>>>
>>>> Oliver Sander wrote:
>>>>         
>>>>> Hi Martin, hi all!
>>>>>
>>>>>
>>>>>           
>>>>>> ok, I thought yesterday's discussion was quite final. I read Oliver's
>>>>>> statement as "I don't want to do this messy renumbering stuff, can't 
>>>>>> someone
>>>>>> else do it". 
>>>>>>             
>>>>> Not quite.  I do not want to dodge the numbering stuff (in fact I can't,
>>>>> I maintain quite a lot of code that depends on local edge and face
>>>>> numbers).  My problem was that I don't quite remember what we
>>>>> decided, and I didn't find it written down.  Therefore I took the 
>>>>> conservative
>>>>> point of view and assumed that the old methods would stay.
>>>>> If they stay, though, it's very confusing to have the old methods use
>>>>> a different numbering than the new ones.  That was my point.
>>>>>
>>>>> Now if we have actually decided that the old subIndex methods should
>>>>> disappear (post 1.3) (which I think is a good decision), then I agree 
>>>>> that
>>>>> they can keep the old numbering, but they should be marked as deprecated
>>>>> immediately, in order to avoid consistency issues.
>>>>>
>>>>> -- 
>>>>> Oliver
>>>>>
>>>>>           
>>>>>> With this in mind I simply changed things to the state they
>>>>>> should be according to the Heidelberg discussion.
>>>>>>
>>>>>> The only thing left was Peter's argument and (as far as I remember) we
>>>>>> discussed this in Heidelberg and decided that there should be no 
>>>>>> performance
>>>>>> loss due to inlining and compiler optimization.
>>>>>>
>>>>>> If someone wants to reopen the Heidelberg discussion, feel free to 
>>>>>> do so. But
>>>>>> until there is a different decision I think we should stick to what 
>>>>>> we already
>>>>>> decided.
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>> Carsten Graeser wrote:
>>>>>>  
>>>>>>             
>>>>>>> Dear Dune Developers,
>>>>>>> from the messages below the current state on the subIndex method 
>>>>>>> seems to be:
>>>>>>>
>>>>>>> *Oliver wants the template-arg method to have the same numbering
>>>>>>> *Peter wants the template-arg method to remain
>>>>>>> *Sven thinks that having different numbering conflicts with keeping 
>>>>>>> the template-arg method
>>>>>>>  but remembers that is was decided differently
>>>>>>> *Martin thinks that the numbering should be different and changed 
>>>>>>> the test accordingly
>>>>>>>
>>>>>>> So currently there seems to be no definite agreement about this issue.
>>>>>>> Perhaps it would be a good idea to decide this before further 
>>>>>>> changes are
>>>>>>> applied. (Especially for maintainers of a grid implementation like 
>>>>>>> me. ;-) )
>>>>>>>
>>>>>>> Best regard
>>>>>>> Carsten
>>>>>>>
>>>>>>>
>>>>>>> Oliver Sander schrieb:
>>>>>>>   
>>>>>>>               
>>>>>>>> Shouldn't the old method use the new numbering as well?
>>>>>>>> Then the test would be okay as it is.
>>>>>>>>       
>>>>>>>>                 
>>>>>>> Peter Bastian schrieb:
>>>>>>>   
>>>>>>>               
>>>>>>>>> - Do we keep the old member template methods?
>>>>>>>>>         
>>>>>>>>>                   
>>>>>>>> I would keep it, as it might be more efficient.
>>>>>>>>       
>>>>>>>>                 
>>>>>>> Sven Marnach schrieb:
>>>>>>>   
>>>>>>>               
>>>>>>>> As I remember the discussion, the idea was to keep the old methods
>>>>>>>> with the old numbering for a smooth transition, providing backward
>>>>>>>> compatibility for one release.  After the transition period, the old
>>>>>>>> methods are to be deleted.
>>>>>>>>
>>>>>>>> That idea somehow conflicts with the idea to keep the old subIndex
>>>>>>>> method with a template codim parameter.
>>>>>>>>       
>>>>>>>>                 
>>>>>>> mnolte at dune-project.org schrieb:
>>>>>>>   
>>>>>>>               
>>>>>>>> Author: mnolte
>>>>>>>> Date: 2009-04-03 09:43:03 +0200 (Fri, 03 Apr 2009)
>>>>>>>> New Revision: 5015
>>>>>>>> Modified: trunk/grid/test/checkindexset.cc
>>>>>>>> ===================================================================
>>>>>>>> --- trunk/grid/test/checkindexset.cc    2009-04-03 07:40:07 UTC 
>>>>>>>> (rev 5014)
>>>>>>>> +++ trunk/grid/test/checkindexset.cc    2009-04-03 07:43:03 UTC 
>>>>>>>> (rev 5015)
>>>>>>>> @@ -448,9 +448,17 @@
>>>>>>>>                   // the subIndex and the index for subEntity must 
>>>>>>>> be the same          assert( vxidx == lset.index( *vxp ));
>>>>>>>> +        +        typedef GenericGeometry::MapNumberingProvider< 
>>>>>>>> dim > Numbering;
>>>>>>>> +        const unsigned int tid = GenericGeometry::topologyId( 
>>>>>>>> it->type() );
>>>>>>>> +        const int gi = Numbering::template dune2generic< dim >( 
>>>>>>>> tid, i );
>>>>>>>>  
>>>>>>>>          // static and dynamic method must yield the same result
>>>>>>>> -        assert( vxidx == lset.subIndex(*it,i,dim));
>>>>>>>> +        if( vxidx != lset.subIndex( *it, gi, dim ) )
>>>>>>>> +        {
>>>>>>>> +          std::cerr << "Error: subIndex< dim >( entity, i ) != 
>>>>>>>> subIndex( entity, dune2generic( i ), dim )" << std::endl;
>>>>>>>> +          assert( vxidx == lset.subIndex( *it, gi, dim ) );
>>>>>>>> +        }
>>>>>>>>                     // check whether the coordinates are the same 
>>>>>>>>            
>>>>>>>> assert(vertexCoordsMap.find(vxidx)!=vertexCoordsMap.end());
>>>>>>>>       
>>>>>>>>                 
>>>>>>>     
>>>>>>>               
>>>>>>   
>>>>>>             
>>     
>
>