vector of char arrays

Discussion in 'C++' started by Scott McPhillips [MVP], Jan 6, 2005.

  1. I have a fixed-size string array like this

    char m_titles[80000][8];

    and can't figure out how to change it to a dynamically-sized vector like
    this:

    std::vector<char[8]> m_titles;

    The declaration compiles but then calling reserve or resize leads to
    obscure compiler errors. Can this be done so that it allocates one big
    array of chars, not 80000 heap strings?

    --
    Scott McPhillips [VC++ MVP]
     
    Scott McPhillips [MVP], Jan 6, 2005
    #1
    1. Advertising

  2. Scott McPhillips [MVP] wrote:
    > I have a fixed-size string array like this
    >
    > char m_titles[80000][8];
    >
    > and can't figure out how to change it to a dynamically-sized vector
    > like this:
    >
    > std::vector<char[8]> m_titles;
    >
    > The declaration compiles but then calling reserve or resize leads to
    > obscure compiler errors.


    Yeah, this fails both copyconstuctibility and assignability.

    > Can this be done so that it allocates one
    > big array of chars, not 80000 heap strings?


    You can use a struct with a member array, but you can't be sure there won't be
    padding between the instances.

    Jonathan
     
    Jonathan Turkanis, Jan 6, 2005
    #2
    1. Advertising

  3. Scott McPhillips [MVP]

    Ron Natalie Guest

    Scott McPhillips [MVP] wrote:
    > I have a fixed-size string array like this
    >
    > char m_titles[80000][8];
    >
    > and can't figure out how to change it to a dynamically-sized vector like
    > this:
    >
    > std::vector<char[8]> m_titles;
    >
    > The declaration compiles but then calling reserve or resize leads to
    > obscure compiler errors. Can this be done so that it allocates one big
    > array of chars, not 80000 heap strings?
    >

    The problem is that the type char[8] isn't assignable so it's not going
    to work inside a vector.

    You could either do a vector of vector,
    or a vector of strings,
    or
    struct c8 {
    char c[8];
    };
    vector<c8>
     
    Ron Natalie, Jan 6, 2005
    #3
  4. Scott McPhillips [MVP]

    Mike Wahler Guest

    "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
    news:...
    > I have a fixed-size string array like this
    >
    > char m_titles[80000][8];
    >
    > and can't figure out how to change it to a dynamically-sized vector like
    > this:
    >
    > std::vector<char[8]> m_titles;
    >
    > The declaration compiles but then calling reserve or resize leads to
    > obscure compiler errors. Can this be done so that it allocates one big
    > array of chars, not 80000 heap strings?


    Standard containers require that the contained objects
    be copyable and assignable. Arrays do not qualify.

    Use a vector of vectors.

    -Mike
     
    Mike Wahler, Jan 6, 2005
    #4
  5. Scott McPhillips [MVP] wrote:
    > I have a fixed-size string array like this
    >
    > char m_titles[80000][8];
    >
    > and can't figure out how to change it to a dynamically-sized vector

    like
    > this:
    >
    > std::vector<char[8]> m_titles;


    Others have commented on this issue already. I just want to point out
    that the upcoming library TR has an elegant solution to this which is
    not as expensive as a vector of vectors: 'std::tr1::array' is a class
    template for fixed size arrays. The replacement would look like this:

    | std::vector<std::tr1::array<char, 8> > m_titles;

    Unfortunately, TR1 implementations are not yet available, AFAIK. On the
    other hand, Boost has an implementation of 'array' which is close if
    not
    identical to the TR1 version (see <http://www.boost.org/>).
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 6, 2005
    #5
  6. Scott McPhillips [MVP]

    Howard Guest

    "Dietmar Kuehl" <> wrote in message > Others have
    commented on this issue already. I just want to point out
    > that the upcoming library TR has an elegant solution to this which is
    > not as expensive as a vector of vectors: 'std::tr1::array' is a class
    > template for fixed size arrays. The replacement would look like this:
    >
    > | std::vector<std::tr1::array<char, 8> > m_titles;
    >
    > Unfortunately, TR1 implementations are not yet available, AFAIK. On the
    > other hand, Boost has an implementation of 'array' which is close if
    > not
    > identical to the TR1 version (see <http://www.boost.org/>).
    > --


    Just curious: what's the "tr1" stand for? Is it really going to be "tr1"?
    Having to use std:: isn't bad, but having to do std::tr1: is starting to
    look like crap to me. I know it's nice to limit the number of characters in
    an identifier (to reduce typing), but at least I try to make my id's
    somewhat meaningful. I just hate to see my c++ code cluttered with names
    that make no earthly sense! :)
    Thanks,
    -Howard
     
    Howard, Jan 6, 2005
    #6
  7. Howard wrote:

    > Just curious: what's the "tr1" stand for? Is it really going to be "tr1"?
    > Having to use std:: isn't bad, but having to do std::tr1: is starting to
    > look like crap to me. I know it's nice to limit the number of characters in
    > an identifier (to reduce typing), but at least I try to make my id's
    > somewhat meaningful. I just hate to see my c++ code cluttered with names
    > that make no earthly sense! :)



    This is some text from my site:

    There will be additional ISO C++ library facilities in a library named
    TR1 and in namespace std::tr1, due to 2005-2006 time frame. Proposals
    that have been accepted are here:

    http://www.open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Jan 6, 2005
    #7
  8. Howard wrote:
    > Just curious: what's the "tr1" stand for?


    "First (Library) Technical Report". Since "1tr" or "1thtr do not work
    and
    "firsttr" is much longer, we settled on "tr1". That it is technically
    not
    really the first technical report issued by the C++ committee (this was
    the TR on performance) may be a little strange but it still is the
    first
    library TR.

    > Is it really going to be "tr1"?


    See Section 1.3 (tr.intro.namespaces) of the current document
    (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf>).

    > Having to use std:: isn't bad, but having to do std::tr1: is starting

    to
    > look like crap to me.


    If the components make it into C++0x they will be moved to 'std::'.
    However,
    the TR does not really modify the standard and it is unclear whether
    the
    components will really become part of the standard and if so, whether
    they
    remain unchanged. Putting the names into a clearly distinguished
    namespace
    which is only used for that purpose allows implementers to retain the
    TR
    version for compatibility issues and still provide the standard version
    in
    the appropriate namespace.

    It would have been possible to choose '::tr1' (i.e. not nest it into
    namespace
    'std') but this would possibly be in conflict with user namespaces:
    '::tr1' is
    definitely not reserved. 'std::tr1' is a safe place where a user shall
    not
    place his own names (if he does so, he deserves what he gets). Of
    course,
    'tr1' may be a macro defined by users. In this case, a user cannot use
    the
    'tr1' components but that's bad luck. Of course, loads of new names
    which
    cannot be used as macro names are introduced by the TR but since it is
    conventional to at least start macro names with a capital letter, the
    chances
    of conflicts are actually pretty low.

    > I know it's nice to limit the number of characters in
    > an identifier (to reduce typing), but at least I try to make my id's
    > somewhat meaningful.


    'std::tr1' *is* meaningful. It is clearly the best name available: even
    dropping the '1' to make it shorter is not a reasonable choice as we
    will
    start working on 'tr2' ("Second (Library) Technical Report") at the
    next
    meeting in Lillehammer. We might get rid of the 'r', though, but I
    prefer
    'tr1' over 't1'.

    > I just hate to see my c++ code cluttered with names
    > that make no earthly sense! :)


    You are free to use using directives or using declarations and only
    that
    part of your code uses these names. I wouldn't call that cluttering. Of
    course, you are also free not to use the TR1 components at all.
    Personally, I don't think the latter approach is really such a smart
    move
    once implementations of TR1 are widely available.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 6, 2005
    #8
  9. Scott McPhillips [MVP]

    Howard Guest

    "Dietmar Kuehl" <> wrote in message
    news:...
    > Howard wrote:
    >> Just curious: what's the "tr1" stand for?

    >
    > "First (Library) Technical Report". Since "1tr" or "1thtr do not work
    > and
    > "firsttr" is much longer, we settled on "tr1". That it is technically
    > not
    > really the first technical report issued by the C++ committee (this was
    > the TR on performance) may be a little strange but it still is the
    > first
    > library TR.
    >
    >> Is it really going to be "tr1"?

    >
    > See Section 1.3 (tr.intro.namespaces) of the current document
    > (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf>).
    >
    >> Having to use std:: isn't bad, but having to do std::tr1: is starting

    > to
    >> look like crap to me.

    >
    > If the components make it into C++0x they will be moved to 'std::'.
    > However,
    > the TR does not really modify the standard and it is unclear whether
    > the
    > components will really become part of the standard and if so, whether
    > they
    > remain unchanged. Putting the names into a clearly distinguished
    > namespace
    > which is only used for that purpose allows implementers to retain the
    > TR
    > version for compatibility issues and still provide the standard version
    > in
    > the appropriate namespace.
    >
    > It would have been possible to choose '::tr1' (i.e. not nest it into
    > namespace
    > 'std') but this would possibly be in conflict with user namespaces:
    > '::tr1' is
    > definitely not reserved. 'std::tr1' is a safe place where a user shall
    > not
    > place his own names (if he does so, he deserves what he gets). Of
    > course,
    > 'tr1' may be a macro defined by users. In this case, a user cannot use
    > the
    > 'tr1' components but that's bad luck. Of course, loads of new names
    > which
    > cannot be used as macro names are introduced by the TR but since it is
    > conventional to at least start macro names with a capital letter, the
    > chances
    > of conflicts are actually pretty low.
    >
    >> I know it's nice to limit the number of characters in
    >> an identifier (to reduce typing), but at least I try to make my id's
    >> somewhat meaningful.

    >
    > 'std::tr1' *is* meaningful.


    Well, it's meaningful if you know what it means! :)

    (I was thinking along the lines of using a name like "Length" instead of "l"
    in my code. And in that respect "tr1" by itself doesn't tell me much.
    Something like "ext05" might tell me that it was the "2005 extension". But
    no problem, I'm a big boy, and can deal with it! :))

    > It is clearly the best name available: even
    > dropping the '1' to make it shorter is not a reasonable choice as we
    > will
    > start working on 'tr2' ("Second (Library) Technical Report") at the
    > next
    > meeting in Lillehammer. We might get rid of the 'r', though, but I
    > prefer
    > 'tr1' over 't1'.
    >
    >> I just hate to see my c++ code cluttered with names
    >> that make no earthly sense! :)

    >
    > You are free to use using directives or using declarations and only
    > that
    > part of your code uses these names. I wouldn't call that cluttering. Of
    > course, you are also free not to use the TR1 components at all.
    > Personally, I don't think the latter approach is really such a smart
    > move
    > once implementations of TR1 are widely available.
    > --
    > <mailto:> <http://www.dietmar-kuehl.de/>
    > <http://www.contendix.com> - Software Development & Consulting
    >


    Okee dokee. Thanks for the info, guys!
    -H
     
    Howard, Jan 6, 2005
    #9
  10. Howard wrote:
    > Just curious: what's the "tr1" stand for?


    "First (Library) Technical Report". Since "1tr" or "1thtr do not work
    and
    "firsttr" is much longer, we settled on "tr1". That it is technically
    not
    really the first technical report issued by the C++ committee (this was
    the TR on performance) may be a little strange but it still is the
    first
    library TR.

    > Is it really going to be "tr1"?


    See Section 1.3 (tr.intro.namespaces) of the current document
    (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf>).

    > Having to use std:: isn't bad, but having to do std::tr1: is starting

    to
    > look like crap to me.


    If the components make it into C++0x they will be moved to 'std::'.
    However,
    the TR does not really modify the standard and it is unclear whether
    the
    components will really become part of the standard and if so, whether
    they
    remain unchanged. Putting the names into a clearly distinguished
    namespace
    which is only used for that purpose allows implementers to retain the
    TR
    version for compatibility issues and still provide the standard version
    in
    the appropriate namespace.

    It would have been possible to choose '::tr1' (i.e. not nest it into
    namespace
    'std') but this would possibly be in conflict with user namespaces:
    '::tr1' is
    definitely not reserved. 'std::tr1' is a safe place where a user shall
    not
    place his own names (if he does so, he deserves what he gets). Of
    course,
    'tr1' may be a macro defined by users. In this case, a user cannot use
    the
    'tr1' components but that's bad luck. Of course, loads of new names
    which
    cannot be used as macro names are introduced by the TR but since it is
    conventional to at least start macro names with a capital letter, the
    chances
    of conflicts are actually pretty low.

    > I know it's nice to limit the number of characters in
    > an identifier (to reduce typing), but at least I try to make my id's
    > somewhat meaningful.


    'std::tr1' *is* meaningful. It is clearly the best name available: even
    dropping the '1' to make it shorter is not a reasonable choice as we
    will
    start working on 'tr2' ("Second (Library) Technical Report") at the
    next
    meeting in Lillehammer. We might get rid of the 'r', though, but I
    prefer
    'tr1' over 't1'.

    > I just hate to see my c++ code cluttered with names
    > that make no earthly sense! :)


    You are free to use using directives or using declarations and only
    that
    part of your code uses these names. I wouldn't call that cluttering. Of
    course, you are also free not to use the TR1 components at all.
    Personally, I don't think the latter approach is really such a smart
    move
    once implementations of TR1 are widely available.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 6, 2005
    #10
  11. Howard wrote:

    > Well, it's meaningful if you know what it means! :)


    Although I also like descriptive names generally, I prefer for the
    standard library short ones.


    I am too tired to type all the type


    using namespace std::TechnicalLibraryReport1;


    or something, in local scopes all the time. Unless you are of the style
    to use such using statements only once in the global namespace, but this
    is not good style.




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Jan 6, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bill Reyn
    Replies:
    3
    Views:
    2,282
    Bob Hairgrove
    Jun 22, 2004
  2. lovecreatesbeauty
    Replies:
    1
    Views:
    1,099
    Ian Collins
    May 9, 2006
  3. Replies:
    8
    Views:
    1,967
    Csaba
    Feb 18, 2006
  4. arnuld
    Replies:
    19
    Views:
    699
    Jacek Dziedzic
    Mar 30, 2007
  5. Philipp
    Replies:
    21
    Views:
    1,157
    Philipp
    Jan 20, 2009
Loading...

Share This Page