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

Martin Nolte nolte at mathematik.uni-freiburg.de
Wed Apr 8 07:57:23 CEST 2009 

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());
>>>>>>>       
>>>>>>     
>>>>>   
>>
> 
> 

-- 
Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5642
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany

More information about the Dune mailing list