Re: Sorting two arrays with one call to sort()?
On Sep 24, 8:30 pm, xz <zhang.xi...@gmail.com> wrote:
On Sep 22, 12:42 pm, Erik Wikstr=F6m <Erik-wikst...@telia.com> wrote:
On 2007-09-22 16:52, xz wrote:
but by using a vector you gain more functionality and have
less limitations.
Is that always better? Even in the case you don't need those
functionality at all. I thought, in the programming world,
it's better for an object not to have the function if it does
not need the function.
It depends. The fact that vector has all of the functionality
of a C style array (or almost) means that it can always be used
where a C style array can be used. The real issue, however, is
that array types in C are broken, so it's best to avoid them as
much as possible. I believe that the next release of the
standard will have boost::array in it, which is a very valid
alternative to vector in cases where you don't need (or want)
the extra functionality.
If the fact that the array contains exactly 10 elements is an
important invariant, the possibility to change the size of
std::vector is a disadvantage. But not enough to outweigh the
disavantages of a C style array. Today, without boost::array,
you will normally only use C style arrays when either 1) you
need static initialization, or 2) you want the compiler to
calculate the size from the initialization list. Boost::array
will also provide 1; I think that there are also proposals to
cover 2, but I'm less familiar with them.
Note that for case 2, above, C style arrays are often combined
with standard containers. Thus, if you want a constant map of
strings to ints, you might write something like:
typedef std::map< std::string, int > Map ;
struct MapInit
{
char const* key ;
int value ;
operator Map::value_type() const
{
return Map::value_type( std::string( key ), value ) ;
}
} ;
MapInit const mapInit[] =
{
{ "one" , 1 },
{ "two" , 2 },
{ "five" , 5 },
{ "ten" , 10 },
{ "twenty" , 20 },
{ "one hundred", 100 },
} ;
Map const map( begin( mapInit ), end( mapInit ) ) ;
Only the map itself would be visible to users, of course.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34