Constructors in fixed_vectors.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Constructors in fixed_vectors.

Joaquim Duran Comas
Hello,

These days, I'm fixing the issues in tests when they are compiled using MSCV compiler.

I've an issue with the constructors of fixed_vector. In fixed_vector, MSVC compiler gets confused with these constructors:

    /// \brief Constructor of a fixed_vector with a unique initial value
    /// \param init value to assign to each element of the vector
         BOOST_UBLAS_INLINE
         fixed_vector (const value_type &init):
             vector_container<self_type> (),
             data_ () {
             data_.fill( init );
         }

and

#if defined(BOOST_MSVC)
        // This may or may not work. Maybe use this for all instead only for MSVC
        template <typename... U>
        fixed_vector(U&&... values) :
            vector_container<self_type> (),
            data_{{ std::forward<U>(values)... }} {}
#else
        template <typename... Types>
        fixed_vector(value_type v0, Types... vrest) :
            vector_container<self_type> (),
            data_{ { v0, vrest... } } {}
#endif

because, constructing a vector and providing just an unique initial value, any of these constructors could be called and the compiler reports a warning.

I propose change the second constructor by providing an inilialization_list (instead of a variadiric template), where type of elements of the list can be enforced as well as the length of the list.

Joaquim Duran


_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Constructors in fixed_vectors.

Nasos Iliopoulos
Your are right we should also provide an initialization list constructor. Last time I checked initialization lists (like a year ago) were not treated properly by all compilers and that's the reason the implementation is the way it is in uBlas.  I am pretty sure the standard implementation of std:array will have a more universally accepted approach. 

My only concern is that dynamic containers in uBlas already provide the functionality of initializing with a value and we should make sure we keep this feature.

I just created this branch if you want to work on:
https://github.com/uBLAS/ublas/tree/feature/ublas00003_fixed_containers_initialization_list_constructor

I can check with various versions of clang and g++ within the week if those work before we merge to develop.

-Nasos


On 08/12/2015 06:55 PM, Joaquim Duran Comas wrote:
Hello,

These days, I'm fixing the issues in tests when they are compiled using MSCV compiler.

I've an issue with the constructors of fixed_vector. In fixed_vector, MSVC compiler gets confused with these constructors:

    /// \brief Constructor of a fixed_vector with a unique initial value
    /// \param init value to assign to each element of the vector
         BOOST_UBLAS_INLINE
         fixed_vector (const value_type &init):
             vector_container<self_type> (),
             data_ () {
             data_.fill( init );
         }

and

          
#if defined(BOOST_MSVC)
        // This may or may not work. Maybe use this for all instead only for MSVC
        template <typename... U>
        fixed_vector(U&&... values) :
            vector_container<self_type><
span> (),
            data_{{ std::forward<U>(values)... }} {}
#else
        template <typename... Types>
        fixed_vector(value_type v0, Types... vrest) :
            vector_container<self_type> (),
            data_{ { v0, vrest... } } {}
#en
dif

because, constructing a vector and providing just an unique initial value, any of these constructors could be called and the compiler reports a warning.

I propose change the second constructor by providing an inilialization_list (instead of a variadiric template), where type of elements of the list can be enforced as well as the length of the list.

Joaquim Duran



_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]


_______________________________________________
ublas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]