Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7890 > unrolled thread

Traits in STL

Back to article view | Back to comp.lang.c++

Contents

  Traits in STL Narinder <narinder.claire@gmail.com> - 2011-07-16 16:36 -0700
    Re: Traits in STL Ian Collins <ian-news@hotmail.com> - 2011-07-17 11:46 +1200
      Re: Traits in STL Narinder <narinder.claire@gmail.com> - 2011-07-16 16:54 -0700
        Re: Traits in STL Ian Collins <ian-news@hotmail.com> - 2011-07-17 12:08 +1200
          Re: Traits in STL Narinder <narinder.claire@gmail.com> - 2011-07-16 17:13 -0700
            Re: Traits in STL Ian Collins <ian-news@hotmail.com> - 2011-07-17 14:09 +1200
    Re: Traits in STL Qi <no@no.com> - 2011-07-17 09:47 +0800

#7890 — Traits in STL

Hello

I am somewhat curious about the reason for the way types in the STL
are dependant on trait classes. For example the template class
basic_string is defined as :

template<class charT,
         class traits = char_traits<charT>,
		 class Allocator = allocator<charT> >
		 >
class basic_string;

but not as:

template<class charT,
         template <class> class traits_t = char_traits,
		 template <class> class Allocator_t = allocator >
		 >
class basic_string
{
	typedef traits_t<charT> traits;
	typedef Allocator_t<charT> Allocator;
...


You would think (or perhaps not) that the second approach is less
error prone since it would be less likely that your traits would be
inconsistent with the char type. The only reason I can think of is
that you may have a traits class specifically for char which wouldn't
make sense for any other types and thus wouldn't need to be a
template. In that case you could always write it as template class and
use traits to activate it only for char types.

Regards
N

[toc] | [next] | [standalone]

#7892

On 07/17/11 11:36 AM, Narinder wrote:
> Hello
>
> I am somewhat curious about the reason for the way types in the STL
> are dependant on trait classes. For example the template class
> basic_string is defined as :
>
> template<class charT,
>           class traits = char_traits<charT>,
> 		 class Allocator = allocator<charT>  >
> 		>
> class basic_string;
>
> but not as:
>
> template<class charT,
>           template<class>  class traits_t = char_traits,
> 		 template<class>  class Allocator_t = allocator>
> 		>
> class basic_string
> {
> 	typedef traits_t<charT>  traits;
> 	typedef Allocator_t<charT>  Allocator;
> ....
>
>
> You would think (or perhaps not) that the second approach is less
> error prone since it would be less likely that your traits would be
> inconsistent with the char type. The only reason I can think of is
> that you may have a traits class specifically for char which wouldn't
> make sense for any other types and thus wouldn't need to be a
> template. In that case you could always write it as template class and
> use traits to activate it only for char types.

Another reason could be a lot of compilers didn't support template 
template parameters when the standard was published (as an aside, I 
don't think template template parameters are used anywhere in the 
current standard library).  Not being able to support std:;string would 
have been a bit of a problem!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7893

On Jul 17, 12:46 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 07/17/11 11:36 AM, Narinder wrote:
>
>
>
>
>
>
>
>
>
> > Hello
>
> > I am somewhat curious about the reason for the way types in the STL
> > are dependant on trait classes. For example the template class
> > basic_string is defined as :
>
> > template<class charT,
> >           class traits = char_traits<charT>,
> >             class Allocator = allocator<charT>  >
>
> > class basic_string;
>
> > but not as:
>
> > template<class charT,
> >           template<class>  class traits_t = char_traits,
> >             template<class>  class Allocator_t = allocator>
>
> > class basic_string
> > {
> >    typedef traits_t<charT>  traits;
> >    typedef Allocator_t<charT>  Allocator;
> > ....
>
> > You would think (or perhaps not) that the second approach is less
> > error prone since it would be less likely that your traits would be
> > inconsistent with the char type. The only reason I can think of is
> > that you may have a traits class specifically for char which wouldn't
> > make sense for any other types and thus wouldn't need to be a
> > template. In that case you could always write it as template class and
> > use traits to activate it only for char types.
>
> Another reason could be a lot of compilers didn't support template
> template parameters when the standard was published (as an aside, I
> don't think template template parameters are used anywhere in the
> current standard library).  Not being able to support std:;string would
> have been a bit of a problem!
>
> --
> Ian Collins

hmmm ... there something quite disturbing about that. Surely the
implementation of the compilers should depend on the standard not the
other way round ...

[toc] | [prev] | [next] | [standalone]

#7894

On 07/17/11 11:54 AM, Narinder wrote:
> On Jul 17, 12:46 am, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 07/17/11 11:36 AM, Narinder wrote:
>>> Hello
>>
>>> I am somewhat curious about the reason for the way types in the STL
>>> are dependant on trait classes. For example the template class
>>> basic_string is defined as :
>>
>>> template<class charT,
>>>            class traits = char_traits<charT>,
>>>              class Allocator = allocator<charT>    >
>>
>>> class basic_string;
>>
>>> but not as:
>>
>>> template<class charT,
>>>            template<class>    class traits_t = char_traits,
>>>              template<class>    class Allocator_t = allocator>
>>
>>> class basic_string
>>> {
>>>     typedef traits_t<charT>    traits;
>>>     typedef Allocator_t<charT>    Allocator;
>>> ....
>>
>>> You would think (or perhaps not) that the second approach is less
>>> error prone since it would be less likely that your traits would be
>>> inconsistent with the char type. The only reason I can think of is
>>> that you may have a traits class specifically for char which wouldn't
>>> make sense for any other types and thus wouldn't need to be a
>>> template. In that case you could always write it as template class and
>>> use traits to activate it only for char types.
>>
>> Another reason could be a lot of compilers didn't support template
>> template parameters when the standard was published (as an aside, I
>> don't think template template parameters are used anywhere in the
>> current standard library).  Not being able to support std:;string would
>> have been a bit of a problem!
>
> hmmm ... there something quite disturbing about that. Surely the
> implementation of the compilers should depend on the standard not the
> other way round ...

Imagine where we'd be if the standard library required export....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7898

On Jul 17, 1:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 07/17/11 11:54 AM, Narinder wrote:
>
>
>
>
>
>
>
>
>
> > On Jul 17, 12:46 am, Ian Collins<ian-n...@hotmail.com>  wrote:
> >> On 07/17/11 11:36 AM, Narinder wrote:
> >>> Hello
>
> >>> I am somewhat curious about the reason for the way types in the STL
> >>> are dependant on trait classes. For example the template class
> >>> basic_string is defined as :
>
> >>> template<class charT,
> >>>            class traits = char_traits<charT>,
> >>>              class Allocator = allocator<charT>    >
>
> >>> class basic_string;
>
> >>> but not as:
>
> >>> template<class charT,
> >>>            template<class>    class traits_t = char_traits,
> >>>              template<class>    class Allocator_t = allocator>
>
> >>> class basic_string
> >>> {
> >>>     typedef traits_t<charT>    traits;
> >>>     typedef Allocator_t<charT>    Allocator;
> >>> ....
>
> >>> You would think (or perhaps not) that the second approach is less
> >>> error prone since it would be less likely that your traits would be
> >>> inconsistent with the char type. The only reason I can think of is
> >>> that you may have a traits class specifically for char which wouldn't
> >>> make sense for any other types and thus wouldn't need to be a
> >>> template. In that case you could always write it as template class and
> >>> use traits to activate it only for char types.
>
> >> Another reason could be a lot of compilers didn't support template
> >> template parameters when the standard was published (as an aside, I
> >> don't think template template parameters are used anywhere in the
> >> current standard library).  Not being able to support std:;string would
> >> have been a bit of a problem!
>
> > hmmm ... there something quite disturbing about that. Surely the
> > implementation of the compilers should depend on the standard not the
> > other way round ...
>
> Imagine where we'd be if the standard library required export....
>
> --
> Ian Collins

Mr Comeau would be very wealthy.
I could be wrong, but wasn't export introduced after the work on the
STL already along way on ?

[toc] | [prev] | [next] | [standalone]

#7899

On 07/17/11 12:13 PM, Narinder wrote:
> On Jul 17, 1:08 am, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 07/17/11 11:54 AM, Narinder wrote:
>>> On Jul 17, 12:46 am, Ian Collins<ian-n...@hotmail.com>    wrote:
>>
>>>> Another reason could be a lot of compilers didn't support template
>>>> template parameters when the standard was published (as an aside, I
>>>> don't think template template parameters are used anywhere in the
>>>> current standard library).  Not being able to support std:;string would
>>>> have been a bit of a problem!
>>
>>> hmmm ... there something quite disturbing about that. Surely the
>>> implementation of the compilers should depend on the standard not the
>>> other way round ...
>>
>> Imagine where we'd be if the standard library required export....
>>

Please don't quote signatures.

> Mr Comeau would be very wealthy.

:)

> I could be wrong, but wasn't export introduced after the work on the
> STL already along way on ?

There's another reason: a large part of the library was existing 
practice and pre-standard compilers didn't have template template 
parameters.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7897

On 2011-7-17 7:36, Narinder wrote:
>
> You would think (or perhaps not) that the second approach is less
> error prone since it would be less likely that your traits would be
> inconsistent with the char type. The only reason I can think of is
> that you may have a traits class specifically for char which wouldn't
> make sense for any other types and thus wouldn't need to be a
> template. In that case you could always write it as template class and
> use traits to activate it only for char types.

Don't know the real reason.

But IMO, template template parameter is quite less flexible than class.

In your second case, you limit that the traits must be a template with
only one parameter, which is too restrict.

The user may want to provide another char_traits, which first parameter
is charT, second is another accessorial parameter for internal use.


-- 
WQ

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web