copy smaller array into bigger array?

Discussion in 'C++' started by Marcus, Aug 15, 2009.

  1. Marcus

    Marcus Guest

    hi, given int foo[10] and int foo2[10][10], how would it be possible
    to do something like foo2[0] = foo?

    i realize i can use a for loop, but just wondering how to do this with
    other methods, perhaps memcpy (but how)?

    unfortunately, my searches have turned up nothing for this type of
    array copy, so any help would be greatly appreciated.

    thanks,
    marcus
    Marcus, Aug 15, 2009
    #1
    1. Advertising

  2. Marcus

    Sjouke Burry Guest

    Marcus wrote:
    > hi, given int foo[10] and int foo2[10][10], how would it be possible
    > to do something like foo2[0] = foo?
    >
    > i realize i can use a for loop, but just wondering how to do this with
    > other methods, perhaps memcpy (but how)?
    >
    > unfortunately, my searches have turned up nothing for this type of
    > array copy, so any help would be greatly appreciated.
    >
    > thanks,
    > marcus

    Learn Fortran. It has exactly what you want(and more).
    Sjouke Burry, Aug 15, 2009
    #2
    1. Advertising

  3. Marcus

    Ian Collins Guest

    Marcus wrote:
    > hi, given int foo[10] and int foo2[10][10], how would it be possible
    > to do something like foo2[0] = foo?
    >
    > i realize i can use a for loop, but just wondering how to do this with
    > other methods, perhaps memcpy (but how)?
    >
    > unfortunately, my searches have turned up nothing for this type of
    > array copy, so any help would be greatly appreciated.


    You can't assign one array to another, but you can if you wrap one in a
    class:

    #include <tr1/array.hpp>

    typedef std::tr1::array<int,10> Array;

    int main()
    {
    Array foo;
    std::tr1::array<Array,10> foo2;

    foo2[0] = foo;
    }


    --
    Ian Collins
    Ian Collins, Aug 15, 2009
    #3
  4. Marcus

    Jerry Coffin Guest

    In article <ae91dc08-b194-4cee-91df-
    >,
    says...
    >
    > hi, given int foo[10] and int foo2[10][10], how would it be possible
    > to do something like foo2[0] = foo?
    >
    > i realize i can use a for loop, but just wondering how to do this with
    > other methods, perhaps memcpy (but how)?
    >
    > unfortunately, my searches have turned up nothing for this type of
    > array copy, so any help would be greatly appreciated.


    Assuming it an array of PODs, you can use memcpy -- but it's only
    rarely a really good idea.

    For the specific case you mention, I'd probably use vectors instead:

    std::vector<int> foo(10);

    std::vector<std::vector<int> > foo2;
    foo2.resize(10);

    foo2[0] = foo;
    // Or:
    std::swap(foo, foo2[0]);

    Using std::swap as above is different from using an assignment in (at
    least) two ways. First of all, it'll usually be faster than an
    assignment. Second, it'll turn foo into an empty vector -- foo[0] was
    empty, and we're swapping the two, so now foo[0] is a vector of ten
    ints, and foo is an empty vector (i.e. doesn't contain anything).

    --
    Later,
    Jerry.
    Jerry Coffin, Aug 15, 2009
    #4
  5. Marcus

    Default User Guest

    Marcus wrote:

    > hi, given int foo[10] and int foo2[10][10], how would it be possible
    > to do something like foo2[0] = foo?
    >
    > i realize i can use a for loop, but just wondering how to do this with
    > other methods, perhaps memcpy (but how)?


    memcpy(foo2[0], foo, sizeof foo);



    Brian

    --
    Day 193 of the "no grouchy usenet posts" project
    Default User, Aug 15, 2009
    #5
  6. Marcus

    Gil Guest

    On Aug 14, 11:29 pm, Marcus <> wrote:
    > hi, given int foo[10] and int foo2[10][10], how would it be possible
    > to do something like foo2[0] = foo?


    //following should do exactly what you want
    std::copy( foo, foo + 10, foo2[ 0 ] );

    gil
    Gil, Aug 15, 2009
    #6
  7. Marcus

    Fraser Ross Guest

    template <typename T, size_t N>
    inline void copy(T (&lhs)[N], T (&rhs)[N]) {
    std::copy_n(lhs, N, rhs);
    }

    copy(foo, foo2[0]);

    Fraser.
    Fraser Ross, Aug 15, 2009
    #7
  8. Marcus

    Francesco Guest

    On 15 Ago, 13:03, "Fraser Ross" <> wrote:
    > template <typename T, size_t N>
    > inline void copy(T (&lhs)[N], T (&rhs)[N]) {
    >  std::copy_n(lhs, N, rhs);
    >  }
    >
    > copy(foo, foo2[0]);
    >
    > Fraser.


    Is copy_n really part of the STL?

    I wasn't able to compile the code - copy_n doesn't appear in my
    <algorithm> header - also, it is not present in TC++PL 3rd ed. nor
    into the standard specs (but my copy of the standard dates back to
    1996).

    The following page:
    http://www.cppreference.com/wiki/stl/algorithm/copy_n

    States:
    "copy_n
    This function was part of the original SGI STL library, but never has
    been a part of ISO C++."

    Is it accurate and up to date?
    Francesco, Aug 15, 2009
    #8
  9. Marcus

    Francesco Guest

    On 15 Ago, 16:02, Francesco <> wrote:
    > On 15 Ago, 13:03, "Fraser Ross" <> wrote:
    >
    > > template <typename T, size_t N>
    > > inline void copy(T (&lhs)[N], T (&rhs)[N]) {
    > > std::copy_n(lhs, N, rhs);
    > > }

    >
    > > copy(foo, foo2[0]);

    >
    > > Fraser.

    >
    > Is copy_n really part of the STL?
    >
    > I wasn't able to compile the code - copy_n doesn't appear in my
    > <algorithm> header - also, it is not present in TC++PL 3rd ed. nor
    > into the standard specs (but my copy of the standard dates back to
    > 1996).
    >
    > The following page:http://www.cppreference.com/wiki/stl/algorithm/copy_n
    >
    > States:
    > "copy_n
    > This function was part of the original SGI STL library, but never has
    > been a part of ISO C++."
    >
    > Is it accurate and up to date?


    On 15 Ago, 16:02, Francesco <> wrote:
    > On 15 Ago, 13:03, "Fraser Ross" <> wrote:
    >
    > > template <typename T, size_t N>
    > > inline void copy(T (&lhs)[N], T (&rhs)[N]) {
    > > std::copy_n(lhs, N, rhs);
    > > }

    >
    > > copy(foo, foo2[0]);

    >
    > > Fraser.

    >
    > Is copy_n really part of the STL?
    >
    > I wasn't able to compile the code - copy_n doesn't appear in my
    > <algorithm> header - also, it is not present in TC++PL 3rd ed. nor
    > into the standard specs (but my copy of the standard dates back to
    > 1996).
    >
    > The following page:http://www.cppreference.com/wiki/stl/algorithm/copy_n
    >
    > States:
    > "copy_n
    > This function was part of the original SGI STL library, but never has
    > been a part of ISO C++."
    >
    > Is it accurate and up to date?


    What do you thing about this version, which allows copying a smaller
    array to the beginning of a larger one and uses std::copy which is
    surely part of the ISO STL?

    -------
    template <typename T, size_t Nfrom, size_t Nto>
    inline bool copy(T (&from)[Nfrom], T (&to)[Nto]) {
    if (Nto < Nfrom) {
    return false;
    } else {
    std::copy(from, &from[Nfrom], to);
    return true;
    }
    }
    -------

    In my opinion working with std::vector would be better in any case.

    Francesco
    Francesco, Aug 15, 2009
    #9
  10. Marcus

    Francesco Guest

    On 15 Ago, 16:49, Francesco <> wrote:
    > On 15 Ago, 16:02, Francesco <> wrote:
    > On 15 Ago, 16:02, Francesco <> wrote:


    Ooops... messed with copy and paste, sorry :-/
    Francesco, Aug 15, 2009
    #10
  11. Marcus

    Fraser Ross Guest

    "Francesco"
    >> Is copy_n really part of the STL?


    Its in the latest draft standard. Some libraries might have it within
    the TR1 namespace.

    >> The following
    >> page:http://www.cppreference.com/wiki/stl/algorithm/copy_n
    >>
    >> States:
    >> "copy_n
    >> This function was part of the original SGI STL library, but never has
    >> been a part of ISO C++."
    >>
    >> Is it accurate and up to date?


    Its out of date. Its quite well known that copy_if was omitted by the
    standard.


    > What do you thing about this version, which allows copying a smaller
    > array to the beginning of a larger one and uses std::copy which is
    > surely part of the ISO STL?
    >
    > -------
    > template <typename T, size_t Nfrom, size_t Nto>
    > inline bool copy(T (&from)[Nfrom], T (&to)[Nto]) {
    > if (Nto < Nfrom) {
    > return false;
    > } else {
    > std::copy(from, &from[Nfrom], to);
    > return true;
    > }
    > }


    The OP has arrays of a single size. I don't think your function has any
    use as it is. Nfrom and Nto are compile-time constants and you have a
    run-time comparison of them. You have taken the address of a
    non-existing element from[Nfrom] which is usually doable but isn't good.
    You can write from + Nfrom.


    Fraser.
    Fraser Ross, Aug 15, 2009
    #11
  12. Marcus

    Francesco Guest

    On 15 Ago, 17:46, "Fraser Ross" <> wrote:
    > "Francesco"
    >
    > >> Is copy_n really part of the STL?

    >
    > Its in the latest draft standard. Some libraries might have it within
    > the TR1 namespace.
    >
    > >> The following
    > >> page:http://www.cppreference.com/wiki/stl/algorithm/copy_n

    >
    > >> States:
    > >> "copy_n
    > >> This function was part of the original SGI STL library, but never has
    > >> been a part of ISO C++."

    >
    > >> Is it accurate and up to date?

    >
    > Its out of date. Its quite well known that copy_if was omitted by the
    > standard.
    >
    > > What do you thing about this version, which allows copying a smaller
    > > array to the beginning of a larger one and uses std::copy which is
    > > surely part of the ISO STL?

    >
    > > -------
    > > template <typename T, size_t Nfrom, size_t Nto>
    > > inline bool copy(T (&from)[Nfrom], T (&to)[Nto]) {
    > > if (Nto < Nfrom) {
    > > return false;
    > > } else {
    > > std::copy(from, &from[Nfrom], to);
    > > return true;
    > > }
    > > }

    >
    > The OP has arrays of a single size. I don't think your function has any
    > use as it is. Nfrom and Nto are compile-time constants and you have a
    > run-time comparison of them. You have taken the address of a
    > non-existing element from[Nfrom] which is usually doable but isn't good.
    > You can write from + Nfrom.
    >
    > Fraser.


    On 15 Ago, 17:46, "Fraser Ross" <> wrote:
    > "Francesco"
    >
    > >> Is copy_n really part of the STL?

    >
    > Its in the latest draft standard. Some libraries might have it within
    > the TR1 namespace.


    Thank you, I didn't knew that.

    >
    > >> The following
    > >> page:http://www.cppreference.com/wiki/stl/algorithm/copy_n

    >
    > >> States:
    > >> "copy_n
    > >> This function was part of the original SGI STL library, but never has
    > >> been a part of ISO C++."

    >
    > >> Is it accurate and up to date?

    >
    > Its out of date. Its quite well known that copy_if was omitted by the
    > standard.
    >
    > > What do you thing about this version, which allows copying a smaller
    > > array to the beginning of a larger one and uses std::copy which is
    > > surely part of the ISO STL?

    >
    > > -------
    > > template <typename T, size_t Nfrom, size_t Nto>
    > > inline bool copy(T (&from)[Nfrom], T (&to)[Nto]) {
    > > if (Nto < Nfrom) {
    > > return false;
    > > } else {
    > > std::copy(from, &from[Nfrom], to);
    > > return true;
    > > }
    > > }

    >
    > The OP has arrays of a single size. I don't think your function has any
    > use as it is. Nfrom and Nto are compile-time constants and you have a
    > run-time comparison of them. You have taken the address of a
    > non-existing element from[Nfrom] which is usually doable but isn't good.
    > You can write from + Nfrom.
    >
    > Fraser.


    You're right, the different sized array assignment wasn't requested so
    there is no need for my function in this particular case, although it
    works just fine - that's just a more flexible version instead of a
    more specialized one, as I see it.

    Could you please explain me why it isn't good to use "&from[Nfrom]",
    being that "from + Nfrom" is just exactly the same thing, and since
    the standard allows me to take the address of the first element past
    the array in either way? Am I mistaking the standard or is it just
    matter of tastes?

    About the runtime check, if I understand it right, a good compiler
    should be able to optimize away that comparison and generate the
    actual functions accordingly. On the other hand, if I omit that check,
    my code could call that function with a bad couple of arrays and I
    would end up writing outside the boundaries, instead of having a safe
    do-nothing function which just returns false.

    I've just tried the same function without that check, it just compiled
    and it just wrote outside the boundaries as expected, when fed with
    the wrong arrays. Is there a way to do such a check at compile time,
    allowing the compiler to issue a warning or an error about it?

    In any case, that's just matter of curiosity, I think I would never
    manage actual data in arrays that way. Maybe it could be worth doing
    in some low-level, hidden, optimized function, I don't know.

    Please don't take my words in the wrong way, I'm not the kind of
    person who likes to dive into polemics, I'm just willing to learn new
    things, that's why I'm responding to your points that way.

    Have good time,
    Francesco
    Francesco, Aug 15, 2009
    #12
  13. Marcus

    Fraser Ross Guest

    "Francesco"
    > Could you please explain me why it isn't good to use "&from[Nfrom]",
    > being that "from + Nfrom" is just exactly the same thing, and since
    > the standard allows me to take the address of the first element past
    > the array in either way? Am I mistaking the standard or is it just
    > matter of tastes?


    The former takes the address of a nonexisting element. The latter only
    uses pointer arithmetic.


    > the wrong arrays. Is there a way to do such a check at compile time,
    > allowing the compiler to issue a warning or an error about it?


    Yes theres static_assert in the latest draft standard. Heres a method
    using the current standard:

    namespace GlobalTypes {
    template < bool >
    struct CompileTimeChecker {
    CompileTimeChecker(...) {}
    };
    template <>
    struct CompileTimeChecker<false> {
    };
    }

    #define STATIC_CHECK(expr, msg) \
    { \
    class ERROR_##msg {}; \
    (void)sizeof(( ::GlobalTypes::CompileTimeChecker<0 !=
    (expr)>(ERROR_##msg()) )); \
    }

    You would write something like:
    STATIC_CHECK(Nto >= Nfrom, DestinationTooShort)

    Fraser.
    Fraser Ross, Aug 15, 2009
    #13
  14. Marcus

    MCD Guest

    thanks very much for all the replies! they've been very helpful and i
    learned much more than i thought i would. am trying them out and
    seeing which one works best.

    regards
    marcus
    MCD, Aug 15, 2009
    #14
  15. Marcus

    James Kanze Guest

    On Aug 15, 5:46 pm, "Fraser Ross" <> wrote:
    > "Francesco"


    > >> Is copy_n really part of the STL?


    > Its in the latest draft standard. Some libraries might have
    > it within the TR1 namespace.


    > >> The following
    > >> page:http://www.cppreference.com/wiki/stl/algorithm/copy_n


    > >> States:
    > >> "copy_n
    > >> This function was part of the original SGI STL library, but
    > >> never has been a part of ISO C++."


    > >> Is it accurate and up to date?


    > Its out of date. Its quite well known that copy_if was
    > omitted by the standard.


    And copy_n, apparently. But it has since been reinstated.

    > > What do you thing about this version, which allows copying a
    > > smaller array to the beginning of a larger one and uses
    > > std::copy which is surely part of the ISO STL?


    > > -------
    > > template <typename T, size_t Nfrom, size_t Nto>
    > > inline bool copy(T (&from)[Nfrom], T (&to)[Nto]) {
    > > if (Nto < Nfrom) {
    > > return false;
    > > } else {
    > > std::copy(from, &from[Nfrom], to);


    The second argument contains undefined behavior. Use from +
    Nfrom instead.

    > > return true;
    > > }
    > > }


    > The OP has arrays of a single size. I don't think your
    > function has any use as it is.


    It's certainly useful for the case the original poster
    presented--copying a one dimensional array into a row of a two
    dimensional array. For his case, in fact, something like:

    assert( Nto == Nfrom ) ;
    std::copy( from, from + nFrom, to ) ;

    would be even more appropriate.

    > Nfrom and Nto are compile-time constants and you have a
    > run-time comparison of them.


    Agreed. Some form of static assert would be more appropriate.

    > You have taken the address of a non-existing element
    > from[Nfrom] which is usually doable but isn't good. You can
    > write from + Nfrom.


    It's a good habit to get into. Taking the address of one past
    the end of a C style array will usually work, even if it is
    formally undefined behavior. Taking the address of one past the
    end of any other container in this manner, however, will
    normally cause the program to crash, at least with a good
    implementation of the library.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 16, 2009
    #15
  16. Marcus

    James Kanze Guest

    On Aug 15, 7:56 pm, "Fraser Ross" <> wrote:
    > "Francesco"


    > > Could you please explain me why it isn't good to use
    > > "&from[Nfrom]", being that "from + Nfrom" is just exactly
    > > the same thing, and since the standard allows me to take the
    > > address of the first element past the array in either way?
    > > Am I mistaking the standard or is it just matter of tastes?


    > The former takes the address of a nonexisting element. The
    > latter only uses pointer arithmetic.


    The former dereferences a pointer to a nonexisting element.
    &from[Nfrom] is, by definition, &(*(from + Nfrom)). And that *
    operator in there results in undefined behavior.

    In practice, of course, every compiler will optimize &*... to a
    no-op, and you'll get exactly the same code for both. But only
    when the built-in operators are involved. If you invoke
    &v[v.size()], you get the equivalent of &v.operator[]( v.size() ).
    And in a good implementation of the library, v.operator[] will
    cause a fatal error in the program when passed v.size(). So
    it's a good habit to get into using first+size to get a pointer
    to one past the end, rather than &first[size].

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Aug 16, 2009
    #16
  17. Marcus

    Fraser Ross Guest

    "James Kanze"
    >It's certainly useful for the case the original poster
    >presented--copying a one dimensional array into a row of a two
    >dimensional array. For his case, in fact, something like:


    > assert( Nto == Nfrom ) ;
    > std::copy( from, from + nFrom, to ) ;


    >would be even more appropriate.


    The function I wrote also does that. His allows target arrays of
    different lengths. STL has overloaded swap for like sized arrays and I
    wonder why it wasn't done for copy, copy_if, copy_backward, and possible
    move and move_backward.

    I'm not sure what move does. Can it be implemented with a 2003 standard
    compiler? Are constructors and destructors invoked? What fills the
    location moved from?

    Fraser.
    Fraser Ross, Aug 16, 2009
    #17
  18. Marcus

    Francesco Guest

    On 15 Ago, 19:56, "Fraser Ross" <> wrote:
    > "Francesco"
    >
    > > Could you please explain me why it isn't good to use "&from[Nfrom]",
    > > being that "from + Nfrom" is just exactly the same thing, and since
    > > the standard allows me to take the address of the first element past
    > > the array in either way? Am I mistaking the standard or is it just
    > > matter of tastes?

    >
    > The former takes the address of a nonexisting element.  The latter only
    > uses pointer arithmetic.


    Well, I'd have expected some kind of argumentation instead of an
    explanation which is pretty obvious - I understand that my "hobbyist"
    label doesn't give any pointer about the level of my knowledge, hence
    this explanation of yours _could have been_ not obvious for me.

    Let's put a point: I'll buy pointer arithmetic just for the sake of
    the fewer keystrokes.

    For everything else, since "&from[Nfrom]" and "from + Nfrom" represent
    exactly the same address, I still see it as matter of tastes. James
    Kanze raised another issue about it but I'll respond to that by
    replying to his post.

    >
    > > the wrong arrays. Is there a way to do such a check at compile time,
    > > allowing the compiler to issue a warning or an error about it?

    >
    > Yes theres static_assert in the latest draft standard.  Heres a method
    > using the current standard:
    >
    > namespace GlobalTypes {
    > template < bool >
    > struct CompileTimeChecker {
    >  CompileTimeChecker(...) {}
    >  };
    > template <>
    > struct CompileTimeChecker<false> {
    >  };
    >
    > }
    >
    > #define STATIC_CHECK(expr, msg) \
    > { \
    > class ERROR_##msg {}; \
    > (void)sizeof(( ::GlobalTypes::CompileTimeChecker<0 !=
    > (expr)>(ERROR_##msg()) )); \
    >
    > }
    >
    > You would write something like:
    > STATIC_CHECK(Nto >= Nfrom, DestinationTooShort)


    Thank you, this method will eventually come handy before the
    implementation of static_assert (which of course I wasn't aware of).

    All the best,
    Francesco

    >
    > Fraser.
    Francesco, Aug 16, 2009
    #18
  19. Marcus

    Francesco Guest

    On 16 Ago, 00:36, MCD <> wrote:
    > thanks very much for all the replies! they've been very helpful and i
    > learned much more than i thought i would. am trying them out and
    > seeing which one works best.
    >
    > regards
    > marcus


    You're welcome. It's nice to see the OP feedback from time to time ;-)

    (of course the sentence above is meant in general, not for you in
    particular)

    All the best,
    Francesco
    Francesco, Aug 16, 2009
    #19
  20. Marcus

    Francesco Guest

    On 16 Ago, 11:08, James Kanze <> wrote:
    > On Aug 15, 7:56 pm, "Fraser Ross" <> wrote:
    >
    > > "Francesco"
    > > > Could you please explain me why it isn't good to use
    > > > "&from[Nfrom]", being that "from + Nfrom" is just exactly
    > > > the same thing, and since the standard allows me to take the
    > > > address of the first element past the array in either way?
    > > > Am I mistaking the standard or is it just matter of tastes?

    > > The former takes the address of a nonexisting element. The
    > > latter only uses pointer arithmetic.

    >
    > The former dereferences a pointer to a nonexisting element.
    > &from[Nfrom] is, by definition, &(*(from + Nfrom)). And that *
    > operator in there results in undefined behavior.


    I don't agree here. As I understand it, it is the act of _accessing_
    the first element past the array to be undefined behavior, not the act
    of composing, getting or passing its address in any manner.

    Stroustrup does this in his example code...
    int v[] = { 1, 2, 3, 4};
    int* p3 = &v[4];
    ....and I wasn't able to find any clause of the standard giving a
    different behavior or different requisites of behavior to the process
    of creating an address using unary *, unary & and the subscript
    operator.

    On the contrary, I was able to understand that those operators are
    expected _not to access_ the relative item(s) while creating the
    address.

    > In practice, of course, every compiler will optimize &*... to a
    > no-op, and you'll get exactly the same code for both. But only
    > when the built-in operators are involved. If you invoke
    > &v[v.size()], you get the equivalent of &v.operator[]( v.size() ).
    > And in a good implementation of the library, v.operator[] will
    > cause a fatal error in the program when passed v.size(). So
    > it's a good habit to get into using first+size to get a pointer
    > to one past the end, rather than &first[size].


    I'll definitely use pointer arithmetic in any case, both with the
    built-in types where it seems to make no difference and with all the
    other types that can be messed up, for the sake of surety - and for
    the sake of the fewer keystrokes ;-)

    Best regards,
    Francesco

    >
    > --
    > James Kanze (GABI Software) email:
    > Conseils en informatique orientée objet/
    > Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    Francesco, Aug 16, 2009
    #20
    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. TG
    Replies:
    3
    Views:
    450
    Robert Kern
    Jul 26, 2006
  2. Replies:
    2
    Views:
    763
    Filip Larsen
    Apr 10, 2007
  3. Peter Kiederich

    text normal smaller bigger

    Peter Kiederich, Jul 5, 2009, in forum: HTML
    Replies:
    11
    Views:
    672
    Jonathan N. Little
    Jul 7, 2009
  4. Yannick Turgeon

    App getting bigger and bigger

    Yannick Turgeon, Oct 13, 2003, in forum: Perl Misc
    Replies:
    1
    Views:
    122
    Yannick Turgeon
    Oct 14, 2003
  5. Gary Mayor
    Replies:
    1
    Views:
    340
    gnari
    Feb 14, 2004
Loading...

Share This Page