Naming template parameters

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

Naming template parameters

Barend
>I've applied some refactoring to ggl/geometries/* and for instance, for
>polygon class, I decided to use _type postifx for typedef declarations.
>I'm not sure about it, however.

>I thought it makes sense to distinct class name of alias name,
>especially name of public alias. Also, std library uses _type
>postfix for aliases exposed as public interface of a class.

>For example, I changed  "B" alias this way: [snipped]

OK for me. Now that "B" is to go there has to be a new convention. I used
"box" in a few cases but agree that "box_type" sounds better.

Often these things can be made private as well, it are most of the time
shortcuts for templated longer names.

MPL has strict rules as "type", "value" and "apply", there are also other
conventions as "value_type", so these must stay as they are.

Regards, Barend




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Naming template parameters

Mateusz Loskot
Administrator
Barend Gehrels wrote:

>> I've applied some refactoring to ggl/geometries/* and for instance, for
>> polygon class, I decided to use _type postifx for typedef declarations.
>> I'm not sure about it, however.
>
>> I thought it makes sense to distinct class name of alias name,
>> especially name of public alias. Also, std library uses _type
>> postfix for aliases exposed as public interface of a class.
>
>> For example, I changed  "B" alias this way: [snipped]
>
> OK for me. Now that "B" is to go there has to be a new convention. I used
> "box" in a few cases but agree that "box_type" sounds better.

OK.

> Often these things can be made private as well, it are most of the time
> shortcuts for templated longer names.

Yes, but changing access may be too serious and I'm not confident where
it is OK where not. Don't want to break anything.

> MPL has strict rules as "type", "value" and "apply", there are also other
> conventions as "value_type", so these must stay as they are.

Yes, this is clear.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Loading...