<div dir="ltr"><div>The fixed-type enums in C++11 could also be beneficial.  Consider the following vtkLookupTable code, which declares a few constants in the header (shown below) and then provides the definition in the .cxx file (not shown):</div><div><br></div><div>class vtkLookupTable<br></div><div>{</div><div>public:</div><div><div>  static const vtkIdType BELOW_RANGE_COLOR_INDEX;</div><div>  static const vtkIdType ABOVE_RANGE_COLOR_INDEX;</div><div>  static const vtkIdType NAN_COLOR_INDEX;</div><div>  static const vtkIdType NUMBER_OF_SPECIAL_COLORS;</div></div><div>...</div><div>};</div><div><br></div><div>In C++11 these "static const" members can be defined more efficiently as a fixed-type enum:</div><div><br></div><div>public:</div><div>  enum : vtkIdType {</div><div>    BELOW_RANGE_COLOR_INDEX = 0,</div><div>    ABOVE_RANGE_COLOR_INDEX = 1,</div><div>    NAN_COLOR_INDEX = 2,</div><div>    NUMBER_OF_SPECIAL_COLORS</div><div>  };</div><div><br></div><div>Of course VTK already uses enums for most constants (except for the ones that are still #define'd), so the benefit is for when you need a guarantee that the constant will be evaluated as a specific integral type.</div><div><br></div><div> - David</div><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 2:14 PM, Robert Maynard <span dir="ltr"><<a href="mailto:robert.maynard@kitware.com" target="_blank">robert.maynard@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Thanks for the feedback. </div><div><br></div><div>1. I agree that when doing template metaprogramming, the alias keyword is significantly better than typedef. I will update the document to state that we prefer alias over typedef</div><div><br></div><div>2. I am going to update the std::array section to clarify that is preferred over raw fixed size 'C' arrays. </div><div><br></div><div>3. This is good information to have. I will add a comment to the scoped enums section while I wait for more feedback<div><div class="gmail-h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 3:30 PM, B B <span dir="ltr"><<a href="mailto:baljci@hotmail.com" target="_blank">baljci@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div id="gmail-m_3755318598748279352m_2854504301224582632m_-1575733224505100624divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:calibri,arial,helvetica,sans-serif" dir="ltr">
<p>I would suggest the following:</p>
<p><br>
</p>
<p>- Prefer the use of alias declarations instead of typedef: they do the same but alias declarations are better because they can be templetized (see Scott Meyers, Effective Modern C++, 63-67)</p>
<p>- Replace raw arrays with std::array when possible: they are copyable, easier to manipulate and have no extra performance costs compared to raw arrays.</p>
<p>- For scoped enums, I would restrict their use to global enums, especially in case of possible name conflicts. For nested enums, I would suggest to maintain the use of unscoped enums for two reasons: first, you don't need to write MyEnum::MyEnumValue each
 time you use them inside the class implementation; second, from my own experience, their implicit conversion to int can be useful in many cases.</p>
<div><br>
</div>
Boris<br>
<br>
<div style="color:rgb(0,0,0)">
<div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_3755318598748279352m_2854504301224582632m_-1575733224505100624x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>De :</b> vtkusers <<a href="mailto:vtkusers-bounces@vtk.org" target="_blank">vtkusers-bounces@vtk.org</a>> de la part de Robert Maynard <<a href="mailto:robert.maynard@kitware.com" target="_blank">robert.maynard@kitware.com</a>><br>
<b>Envoyé :</b> lundi 27 mars 2017 20:03<br>
<b>À :</b> VTK Developers; vtk vtk<br>
<b>Objet :</b> [vtkusers] Allowable C++11 Features in VTK</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="gmail-m_3755318598748279352m_2854504301224582632m_-1575733224505100624PlainText"><div><div class="gmail-m_3755318598748279352m_2854504301224582632h5">As everyone is aware over the past couple of months we have updated<br>
VTK to require a C++11 compiler, but have not explicitly stated what<br>
C++11 features are usable.<br>
<br>
We do not intend to incorporate all features of the language at this<br>
time because of incompatibilities with the structure of VTK and/or<br>
incomplete support for the features by all of the compilers that VTK<br>
aims to support.<br>
<br>
The current proposed C++11 features, and where they are allowed can be found at:<br>
<br>
<a href="https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing" id="gmail-m_3755318598748279352m_2854504301224582632m_-1575733224505100624LPlnk333734" target="_blank">https://docs.google.com/docume<wbr>nt/d/1h7wIq25d-qimQO8N9sE43fHX<wbr>KKlHM2sW2ErohfHiuCg/edit?usp=s<wbr>haring</a><br>
<br>
Over the next two weeks please provide feedback, either by commenting<br>
on the google document, or replying on the mailing list. Once the two<br>
weeks are over, we will integrate the result into the existing coding<br>
documentation, and then allow C++11 to be used.<br></div></div></div></span></font></div></div></div></blockquote></div></div></div></div></div></div></blockquote></div><br></div></div>