Allowable C++11 Features in VTK

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Allowable C++11 Features in VTK

Robert Maynard-4
As everyone is aware over the past couple of months we have updated
VTK to require a C++11 compiler, but have not explicitly stated what
C++11 features are usable.

We do not intend to incorporate all features of the language at this
time because of incompatibilities with the structure of VTK and/or
incomplete support for the features by all of the compilers that VTK
aims to support.

The current proposed C++11 features, and where they are allowed can be found at:

https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing

Over the next two weeks please provide feedback, either by commenting
on the google document, or replying on the mailing list. Once the two
weeks are over, we will integrate the result into the existing coding
documentation, and then allow C++11 to be used.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
B B
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Allowable C++11 Features in VTK

B B

I would suggest the following:


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

- Replace raw arrays with std::array when possible: they are copyable, easier to manipulate and have no extra performance costs compared to raw arrays.

- 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.


Boris


De : vtkusers <[hidden email]> de la part de Robert Maynard <[hidden email]>
Envoyé : lundi 27 mars 2017 20:03
À : VTK Developers; vtk vtk
Objet : [vtkusers] Allowable C++11 Features in VTK
 
As everyone is aware over the past couple of months we have updated
VTK to require a C++11 compiler, but have not explicitly stated what
C++11 features are usable.

We do not intend to incorporate all features of the language at this
time because of incompatibilities with the structure of VTK and/or
incomplete support for the features by all of the compilers that VTK
aims to support.

The current proposed C++11 features, and where they are allowed can be found at:

https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing

Over the next two weeks please provide feedback, either by commenting
on the google document, or replying on the mailing list. Once the two
weeks are over, we will integrate the result into the existing coding
documentation, and then allow C++11 to be used.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Allowable C++11 Features in VTK

Robert Maynard-4
Hi,

Thanks for the feedback. 

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

2. I am going to update the std::array section to clarify that is preferred over raw fixed size 'C' arrays. 

3. This is good information to have. I will add a comment to the scoped enums section while I wait for more feedback

On Mon, Mar 27, 2017 at 3:30 PM, B B <[hidden email]> wrote:

I would suggest the following:


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

- Replace raw arrays with std::array when possible: they are copyable, easier to manipulate and have no extra performance costs compared to raw arrays.

- 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.


Boris


De : vtkusers <[hidden email]> de la part de Robert Maynard <[hidden email]>
Envoyé : lundi 27 mars 2017 20:03
À : VTK Developers; vtk vtk
Objet : [vtkusers] Allowable C++11 Features in VTK
 
As everyone is aware over the past couple of months we have updated
VTK to require a C++11 compiler, but have not explicitly stated what
C++11 features are usable.

We do not intend to incorporate all features of the language at this
time because of incompatibilities with the structure of VTK and/or
incomplete support for the features by all of the compilers that VTK
aims to support.

The current proposed C++11 features, and where they are allowed can be found at:

https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing

Over the next two weeks please provide feedback, either by commenting
on the google document, or replying on the mailing list. Once the two
weeks are over, we will integrate the result into the existing coding
documentation, and then allow C++11 to be used.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
To see the collection of prior postings to the list, visit the vtkusers Archives. Using vtkusers: To post a message to all the list members, send ...




_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [vtk-developers] Allowable C++11 Features in VTK

David Gobbi
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):

class vtkLookupTable
{
public:
  static const vtkIdType BELOW_RANGE_COLOR_INDEX;
  static const vtkIdType ABOVE_RANGE_COLOR_INDEX;
  static const vtkIdType NAN_COLOR_INDEX;
  static const vtkIdType NUMBER_OF_SPECIAL_COLORS;
...
};

In C++11 these "static const" members can be defined more efficiently as a fixed-type enum:

public:
  enum : vtkIdType {
    BELOW_RANGE_COLOR_INDEX = 0,
    ABOVE_RANGE_COLOR_INDEX = 1,
    NAN_COLOR_INDEX = 2,
    NUMBER_OF_SPECIAL_COLORS
  };

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.

 - David



On Mon, Mar 27, 2017 at 2:14 PM, Robert Maynard <[hidden email]> wrote:
Hi,

Thanks for the feedback. 

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

2. I am going to update the std::array section to clarify that is preferred over raw fixed size 'C' arrays. 

3. This is good information to have. I will add a comment to the scoped enums section while I wait for more feedback


On Mon, Mar 27, 2017 at 3:30 PM, B B <[hidden email]> wrote:

I would suggest the following:


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

- Replace raw arrays with std::array when possible: they are copyable, easier to manipulate and have no extra performance costs compared to raw arrays.

- 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.


Boris


De : vtkusers <[hidden email]> de la part de Robert Maynard <[hidden email]>
Envoyé : lundi 27 mars 2017 20:03
À : VTK Developers; vtk vtk
Objet : [vtkusers] Allowable C++11 Features in VTK
 
As everyone is aware over the past couple of months we have updated
VTK to require a C++11 compiler, but have not explicitly stated what
C++11 features are usable.

We do not intend to incorporate all features of the language at this
time because of incompatibilities with the structure of VTK and/or
incomplete support for the features by all of the compilers that VTK
aims to support.

The current proposed C++11 features, and where they are allowed can be found at:

https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing

Over the next two weeks please provide feedback, either by commenting
on the google document, or replying on the mailing list. Once the two
weeks are over, we will integrate the result into the existing coding
documentation, and then allow C++11 to be used.


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Allowable C++11 Features in VTK

Andrew Maclean-3
In reply to this post by Robert Maynard-4
I agree with David.

I would argue for strongly typed enums to be allowed. In contrast to ordinary enums, they don't export their enumerators to the surrounding scope and they don't have implicit conversion to int. Implicit conversion to int can dangerous in that the code performs correctly but the results are unexpected. I don't think their use should be restricted to just global enumerations.

I actually had the experience of converting old code to C++11 and when I converted the enums to strongly typed enums a whole lot of subtle faults were revealed where ints were used instead of enums. The important thing was that the old code ran perfectly but it was nearly impossible to account for the anomalous behaviour until strongly typed enums were used.


Here is a contrived example that illustrates the problem.
#include <cstdlib>
#include <iostream>
#include <iomanip>

enum bg1 {r, g, b};

enum class bg2 { r, g, b };

void c0(int intensity)
{
std::cout << "Intensity: " << intensity << "\n";
}

void c1(bg1 bg, int intensity)
{
std::cout << "Background: ";
switch (bg)
{
case r: std::cout << "r\n";   break;
case g: std::cout << "gr\n"; break;
case b: std::cout << "b\n";  break;
}
std::cout << "Intensity: " << intensity << "\n";
}

void c2(bg2 bg, int intensity)
{
std::cout << "Background: ";
switch (bg)
{
case bg2::r: std::cout << "r\n";   break;
case bg2::g: std::cout << "g\n"; break;
case bg2::b: std::cout << "b\n";  break;
}
std::cout << "Intensity: " << intensity << "\n";
}

int main()
{
int intensity = 7;
c0(intensity);
c0(bg1::r); // OK but surely an error!
c1(bg1::r, intensity);
// This call is Ok as bg is implicitly converted to int.
// Is this what we really want?
c1(bg1::r, bg1::g);
// Strongly typed case.
c2(bg2::r, intensity);
// Because of strongly typed enums, 
// these will fail as bg2 is strongly typed.
// c0(bg2::r);
// c2(bg2::r, bg2::g);

return EXIT_SUCCESS;
}

Regards
   Andrew

---------- Forwarded message ----------
From: David Gobbi <[hidden email]>
To: Robert Maynard <[hidden email]>
Cc: VTK Developers <[hidden email]>, vtk vtk <[hidden email]>
Bcc: 
Date: Mon, 27 Mar 2017 15:22:29 -0600
Subject: Re: [vtk-developers] [vtkusers] Allowable C++11 Features in VTK
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):

class vtkLookupTable
{
public:
  static const vtkIdType BELOW_RANGE_COLOR_INDEX;
  static const vtkIdType ABOVE_RANGE_COLOR_INDEX;
  static const vtkIdType NAN_COLOR_INDEX;
  static const vtkIdType NUMBER_OF_SPECIAL_COLORS;
...
};

In C++11 these "static const" members can be defined more efficiently as a fixed-type enum:

public:
  enum : vtkIdType {
    BELOW_RANGE_COLOR_INDEX = 0,
    ABOVE_RANGE_COLOR_INDEX = 1,
    NAN_COLOR_INDEX = 2,
    NUMBER_OF_SPECIAL_COLORS
  };

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.

 - David



On Mon, Mar 27, 2017 at 2:14 PM, Robert Maynard <[hidden email]> wrote:
Hi,

Thanks for the feedback. 

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

2. I am going to update the std::array section to clarify that is preferred over raw fixed size 'C' arrays. 

3. This is good information to have. I will add a comment to the scoped enums section while I wait for more feedback


On Mon, Mar 27, 2017 at 3:30 PM, B B <[hidden email]> wrote:

I would suggest the following:


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

- Replace raw arrays with std::array when possible: they are copyable, easier to manipulate and have no extra performance costs compared to raw arrays.

- 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.


Boris


De : vtkusers <[hidden email]> de la part de Robert Maynard <[hidden email]>
Envoyé : lundi 27 mars 2017 20:03
À : VTK Developers; vtk vtk
Objet : [vtkusers] Allowable C++11 Features in VTK
 
As everyone is aware over the past couple of months we have updated
VTK to require a C++11 compiler, but have not explicitly stated what
C++11 features are usable.

We do not intend to incorporate all features of the language at this
time because of incompatibilities with the structure of VTK and/or
incomplete support for the features by all of the compilers that VTK
aims to support.

The current proposed C++11 features, and where they are allowed can be found at:

https://docs.google.com/document/d/1h7wIq25d-qimQO8N9sE43fHXKKlHM2sW2ErohfHiuCg/edit?usp=sharing

Over the next two weeks please provide feedback, either by commenting
on the google document, or replying on the mailing list. Once the two
weeks are over, we will integrate the result into the existing coding
documentation, and then allow C++11 to be used.


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers


--
___________________________________________
Andrew J. P. Maclean

___________________________________________

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [vtk-developers] Allowable C++11 Features in VTK

Sean McBride
In reply to this post by Robert Maynard-4
On Mon, 27 Mar 2017 14:03:16 -0400, Robert Maynard said:

>As everyone is aware over the past couple of months we have updated
>VTK to require a C++11 compiler, but have not explicitly stated what
>C++11 features are usable.
>
>We do not intend to incorporate all features of the language at this
>time because of incompatibilities with the structure of VTK and/or
>incomplete support for the features by all of the compilers that VTK
>aims to support.
>
>The current proposed C++11 features, and where they are allowed can be
>found at:

It looks pretty good to me.

I'm a little trepidacious about 'auto'.  I think it can certainly be beneficial if used judiciously, but I worry that overuse will hurt the readability and debuggability of the codebase.

A shame that VS didn't support constexpr until recently, it would be nice to use too.

In general, one thing I've always liked about VTK's C++ is that it isn't unnecessarily 'clever' using any and every funky C++ feature.  I hope that continues.

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ

Search the list archives at: http://markmail.org/search/?q=vtkusers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers
Loading...