Valentin Bonnard <bonnardv@pratique.fr> writes:

 |>  James Kanze wrote:
 |>  JK>
 |>  JK> Eric Gindrup <gindrup@okway.okstate.edu> writes:
 |>
 |>  JK> |>  In particular, how does this partial snippet know that T is not
 |>  JK> |>  an array?  (Or, have I erroneously assumed that if T were, e.g.,
 |>  JK> |>  "int[5]", new[]() and delete[]() would be necessary?)
 |>  JK> |>
 |>  JK> |>  template foo<T>
 |>  JK> |>  {  foo()
 |>  JK> |>     {  // ...
 |>  JK> |>        T *foo=new T;
 |>  JK> |>        // ...
 |>  JK> |>        delete foo;
 |>  JK> |>        // ...
 |>  JK> |>     }
 |>  JK> |>  }
 |>  JK>
 |>  JK> If T is int[5], the above template results in undefined behavior.
 |>
 |>  IMO the code is just ill-formed:
 |>
 |>      T* p = new T;
 |>
 |>  doesn't work on my compiler when T is char[10] because new
 |>  return a char*, not a char (*)[10] (which is non-sens, and
 |>  proves again that arrays are broken, has James will add).

Correct on both counts: the code is ill-formed, and I will add that this
proves again that C style arrays are broken.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze (james-albert.kanze@vx.cit.alcatel.fr) wrote:
> C style arrays are horribly broken, on many counts.  They cannot be
> fixed without breaking existing code, however.  The currently accepted
> viewpoint is just to leave them like they are, for backwards
> compatibility, and to invest any effort in improvement in vector or
> dynarray.

Or maybe under some circumstances when the performance is really issue just
write

template<class T, int size>
struct fixed_length_vector {
  T data[size];
  T& operator[](int i) { return data[i]; }
  T const& operator[](int i) const { return data[i]; }
}

Now the array size is the essential part of type itself and all problems
with C - like arrays are solved without performance drawback.

P.S.
It would be nice to have such class with all related iterators
in the standard library.


--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

How does a class implementation determine if it is instantiated
with array or non-array types?

In particular, how does this partial snippet know that T is not
an array?  (Or, have I erroneously assumed that if T were, e.g.,
"int[5]", new[]() and delete[]() would be necessary?)

template foo<T>
{  foo()
   {  // ...
      T *foo=new T;
      // ...
      delete foo;
      // ...
   }
}
       -- Eric Gindrup ! gindrup@okway.okstate.edu
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Eric Gindrup <gindrup@okway.okstate.edu> writes:

>How does a class implementation determine if it is instantiated
>with array or non-array types?

You should be able to use template partial specialization to figure
it out.

 // warning: untested code

 template <class T>
 struct info {
  static const bool is_array = false;
 }

 template <class T, int i>
 struct info<T[i]> {
  static const bool is_array = true;
 }

>In particular, how does this partial snippet know that T is not
>an array?  (Or, have I erroneously assumed that if T were, e.g.,
>"int[5]", new[]() and delete[]() would be necessary?)
>
>template foo<T>
>{  foo()
>   {  // ...
>      T *foo=new T;
>      // ...
>      delete foo;
>      // ...
>   }
>}

Generally such templates would have a (usually undocumented)
requirement that the type be a non-array type.
Users that want to instantiated such templates with an array
type can instantiated them with a user-defined array template class
instead.

If for some reason you really want to write code that handles the case
when it is instantiated with an array type, then you could use

 T *foo = new T[1];
 ...
 delete foo;

This should work whether or not T is an array type.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I wrote:

>If for some reason you really want to write code that handles the case
>when it is instantiated with an array type, then you could use
>
> T *foo = new T[1];
> ...
> delete foo;
>
>This should work whether or not T is an array type.

Correction: that should be `delete [] foo', not `delete foo'.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Eric Gindrup <gindrup@okway.okstate.edu> writes:

|>  How does a class implementation determine if it is instantiated
|>  with array or non-array types?

It doesn't.

|>  In particular, how does this partial snippet know that T is not
|>  an array?  (Or, have I erroneously assumed that if T were, e.g.,
|>  "int[5]", new[]() and delete[]() would be necessary?)
|>
|>  template foo<T>
|>  {  foo()
|>     {  // ...
|>        T *foo=new T;
|>        // ...
|>        delete foo;
|>        // ...
|>     }
|>  }

If T is int[5], the above template results in undefined behavior.

There may be a trick involving partial specialization to work around
this, but IMHO, the best solution is just to use vector< int > instead
of int[5].

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze wrote:
>
> Eric Gindrup <gindrup@okway.okstate.edu> writes:
>>  How does a class implementation determine if it is instantiated
>>  with array or non-array types?
>
> It doesn't.
[...]
> If T is int[5], the above template results in undefined behavior.
>
> There may be a trick involving partial specialization to work around
> this, but IMHO, the best solution is just to use vector< int > instead
> of int[5].
>
> -- James Kanze

This seems, somehow, unsatisfying.  Why should one have to write two
versions of a template, one for array arguments and one for non-array
arguments?  (Other than the obvious: It doesn't work if you don't!)
This would lead to a very large expansion in required coding if one
had to do this for several template type arguments.
  -- Eric Gindrup ! gindrup@okway.okstate.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

 |>  Eric Gindrup <gindrup@okway.okstate.edu> writes:
 |>
 |>  >How does a class implementation determine if it is instantiated
 |>  >with array or non-array types?
 |>
 |>  You should be able to use template partial specialization to figure
 |>  it out.
 |>
 |>   // warning: untested code
 |>
 |>   template <class T>
 |>   struct info {
 |>    static const bool is_array = false;
 |>   }
 |>
 |>   template <class T, int i>
 |>   struct info<T[i]> {
 |>    static const bool is_array = true;
 |>   }
 |>
 |>  >In particular, how does this partial snippet know that T is not
 |>  >an array?  (Or, have I erroneously assumed that if T were, e.g.,
 |>  >"int[5]", new[]() and delete[]() would be necessary?)
 |>  >
 |>  >template foo<T>
 |>  >{  foo()
 |>  >   {  // ...
 |>  >      T *foo=new T;
 |>  >      // ...
 |>  >      delete foo;
 |>  >      // ...
 |>  >   }
 |>  >}
 |>
 |>  Generally such templates would have a (usually undocumented)
 |>  requirement that the type be a non-array type.

Note the in STL, this requirement is not only present, it is documented,
although only indirectly.  (STL requires the type to have a copy
constructor and support assignment.  C style arrays do neither.)

I would imagine that the same is true for most user code as well.  The
stated requirements for the instantiation type will often include copy
and assignment.

 |>  Users that want to instantiated such templates with an array
 |>  type can instantiated them with a user-defined array template class
 |>  instead.
 |>
 |>  If for some reason you really want to write code that handles the case
 |>  when it is instantiated with an array type, then you could use
 |>
 |>   T *foo = new T[1];
 |>   ...
 |>   delete foo;

You do mean: "delete [] foo", don't you?

 [Yes.  -fjh.]

 |>  This should work whether or not T is an array type.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Eric Gindrup <gindrup@okway.okstate.edu> writes:

>This seems, somehow, unsatisfying.  Why should one have to write two
>versions of a template, one for array arguments and one for non-array
>arguments?

You don't have to do that.  Just write one for non-array arguments.
There's no need to have one for array arguments.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Eric Gindrup <gindrup@okway.okstate.edu> writes:
> This seems, somehow, unsatisfying.  Why should one have to write two
> versions of a template, one for array arguments and one for non-array
> arguments?  (Other than the obvious: It doesn't work if you don't!)
> This would lead to a very large expansion in required coding if one
> had to do this for several template type arguments.

But you can always do it like this:

template <class T>
class ArraySensitiveAllocator
{
public:
  static T *allocate() { return new T; }
  static void deallocate(T* ptr) { delete ptr; }
};

template <class T, int n>
class ArraySensitiveAllocator<T[n]>
{
public:
  static T *allocate() { return new T[n]; }
  static void deallocate(T *ptr) { delete [] ptr; }
};

And then just use ArraySensitiveAllocator<T>::allocate() and
deallocate() everywhere => you don't need to specialize for every type.
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze wrote:
JK>
JK> Eric Gindrup <gindrup@okway.okstate.edu> writes:

JK> |>  In particular, how does this partial snippet know that T is not
JK> |>  an array?  (Or, have I erroneously assumed that if T were, e.g.,
JK> |>  "int[5]", new[]() and delete[]() would be necessary?)
JK> |>
JK> |>  template foo<T>
JK> |>  {  foo()
JK> |>     {  // ...
JK> |>        T *foo=new T;
JK> |>        // ...
JK> |>        delete foo;
JK> |>        // ...
JK> |>     }
JK> |>  }
JK>
JK> If T is int[5], the above template results in undefined behavior.

IMO the code is just ill-formed:

    T* p = new T;

doesn't work on my compiler when T is char[10] because new
return a char*, not a char (*)[10] (which is non-sens, and
proves again that arrays are broken, has James will add).

JK> There may be a trick involving partial specialization to work around
JK> this, but IMHO, the best solution is just to use vector< int >
instead
JK> of int[5].

Ok, but that's not the point: the problem was how to write a
template class, not how to use it.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Eric Gindrup <gindrup@okway.okstate.edu> writes:

|>  James Kanze wrote:
|>  >
|>  > Eric Gindrup <gindrup@okway.okstate.edu> writes:
|>  >>  How does a class implementation determine if it is instantiated
|>  >>  with array or non-array types?
|>  >
|>  > It doesn't.
|>  [...]
|>  > If T is int[5], the above template results in undefined behavior.
|>  >
|>  > There may be a trick involving partial specialization to work around
|>  > this, but IMHO, the best solution is just to use vector< int > instead
|>  > of int[5].
|>  >
|>  > -- James Kanze
|>
|>  This seems, somehow, unsatisfying.  Why should one have to write two
|>  versions of a template, one for array arguments and one for non-array
|>  arguments?  (Other than the obvious: It doesn't work if you don't!)
|>  This would lead to a very large expansion in required coding if one
|>  had to do this for several template type arguments.

The obvious answer is not to use C style arrays, period, so you don't
have to write two versions.

C style arrays are horribly broken, on many counts.  They cannot be
fixed without breaking existing code, however.  The currently accepted
viewpoint is just to leave them like they are, for backwards
compatibility, and to invest any effort in improvement in vector or
dynarray.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]