<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020 at 6:41 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
we have a couple of implementation-specific inline functions defined in <br>
header files which have exactly one caller. I think we should remove <br>
these functions in general, to reduce the lines of code, making code <br>
review easier, and reduce the number of functions which need <br>
documentation. If it makes the caller site more clear, then we should <br>
place them in the source file of the caller. Examples:<br>
<br>
cpukit/rtems/src/partcreate.c:  the_partition = _Partition_Allocate();<br>
cpukit/include/rtems/rtems/partimpl.h:RTEMS_INLINE_ROUTINE <br>
Partition_Control *_Partition_Allocate ( void )<br>
<br>
cpukit/include/rtems/rtems/regionimpl.h:RTEMS_INLINE_ROUTINE bool <br>
_Region_Free_segment (<br>
cpukit/rtems/src/regionreturnsegment.c:  if ( _Region_Free_segment( <br>
the_region, segment ) ) {<br>
<br>
cpukit/sapi/src/extensiondelete.c:  the_extension = _Extension_Get( id );<br>
cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE <br>
Extension_Control *_Extension_Get( Objects_Id id )<br>
<br>
cpukit/sapi/src/extensioncreate.c:  the_extension = _Extension_Allocate();<br>
cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE <br>
Extension_Control *_Extension_Allocate( void )<br>
<br>
cpukit/sapi/src/extensiondelete.c:    _Extension_Free( the_extension );<br>
cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE void <br>
_Extension_Free (<br>
<br>
What do you think?<br></blockquote><div><br></div><div>I think that having a single caller is not by itself a reason to eliminate a method.</div><div><br></div><div>Although it predates C++, the design of RTEMS internal interfaces was based</div><div>on strong packaging and encapsulation. </div><div><br></div><div>This particular change would expose the allocation scheme for these object </div><div>classes to the caller and the need for a cast. Under the original rules, hiding</div><div>that had value.</div><div><br></div><div>In this case, it is probably OK because the caller should always be the API</div><div> that actually defined the method  But if the simple, single caller method </div><div>is not defined in the same "class" where it is called, that would break the</div><div>encapsulation.</div><div><br></div><div>We also have to consider if this has a negative impact on readability. In this</div><div>case, that seems unlikely as well since the verb isn't changing and there</div><div>is no algorithm or internals exposure. Sometimes, a simple inline is hiding</div><div>something that is ugly and makes the callers look better. Certainly this</div><div>is hiding a cast. But that's not necessarily inherently ugly.</div><div><br></div><div>I'm not giving blanket permission. I'm saying it is worth considering on a</div><div>case by case method and updating the coding conventions on inlines.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>