some well known stupidness in c99

Discussion in 'C Programming' started by fir, Nov 18, 2012.

  1. fir

    fir Guest

    It is sad to say so but there is some real
    and terrible stupidnes in c99. When i wrote
    programs in c (and I am involved c user) I
    just use const int for array boundaries but
    in c99 (and some previous too, terribly) it
    will not compile (see for example
    http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
    thing for ppl who just wants to use const int to this
    purposes and not to use preprocesor - as I do.
    It is terribly stupidness in my opinion, it have to
    be changed.
     
    fir, Nov 18, 2012
    #1
    1. Advertising

  2. Am 18.11.2012 10:21, schrieb fir:
    > It is sad to say so but there is some real
    > and terrible stupidnes in c99. When i wrote
    > programs in c (and I am involved c user) I
    > just use const int for array boundaries but
    > in c99 (and some previous too, terribly) it
    > will not compile (see for example
    > http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
    > thing for ppl who just wants to use const int to this
    > purposes and not to use preprocesor - as I do.
    > It is terribly stupidness in my opinion, it have to
    > be changed.


    This is valid C++ code, thus one option would be just to switch to C++.
    In C, however, const is probably not quite what you expect it to be.
     
    Thomas Richter, Nov 18, 2012
    #2
    1. Advertising

  3. fir

    SG Guest

    Am 18.11.2012 10:21, schrieb fir:
    > It is sad to say so but there is some real
    > and terrible stupidnes in c99. When i wrote
    > programs in c (and I am involved c user) I
    > just use const int for array boundaries but
    > in c99 (and some previous too, terribly) it
    > will not compile (see for example
    > http://stackoverflow.com/questions/1712592/ ) It is terribly wrong
    > thing for ppl who just wants to use const int to this
    > purposes and not to use preprocesor - as I do.
    > It is terribly stupidness in my opinion, it have to
    > be changed.


    To my knowledge this has been the way in C for ever. Are you complaining
    about C99 not adopting the C++ style in treating a file-scope const
    "variable" with a constant initializer as a constant [compile-time]
    expression? Or are you suggesting that C90 handles this any better and
    that C99 is actually a regression in this department?

    In C++ you can actually do this and

    const int foo = 10;

    is implicitly static (file-scope) due to the top-level constness and foo
    can be used as compile-time constant expression. This is by design
    because B. Stroustrup doesn't like macros very much, either.

    I sort of accepted this difference between C and C++. In C you just have
    to #define something like this in order to be able to use it as the size
    of a non-VL array. But I would appreciate it if this unnecessary
    incompatibility went away...
     
    SG, Nov 18, 2012
    #3
  4. fir

    fir Guest

    W dniu niedziela, 18 listopada 2012 10:41:55 UTC+1 użytkownik SG napisał:
    > Am 18.11.2012 10:21, schrieb fir:
    >
    > > It is sad to say so but there is some real

    >
    > > and terrible stupidnes in c99. When i wrote

    >
    > > programs in c (and I am involved c user) I

    >
    > > just use const int for array boundaries but

    >
    > > in c99 (and some previous too, terribly) it

    >
    > > will not compile (see for example

    >
    > > http://stackoverflow.com/questions/1712592/ ) It is terribly wrong

    >
    > > thing for ppl who just wants to use const int to this

    >
    > > purposes and not to use preprocesor - as I do.

    >
    > > It is terribly stupidness in my opinion, it have to

    >
    > > be changed.

    >
    >
    >
    > To my knowledge this has been the way in C for ever. Are you complaining
    >
    > about C99 not adopting the C++ style in treating a file-scope const
    >
    > "variable" with a constant initializer as a constant [compile-time]
    >
    > expression? Or are you suggesting that C90 handles this any better and
    >
    > that C99 is actually a regression in this department?
    >
    >
    >
    > In C++ you can actually do this and
    >
    >
    >
    > const int foo = 10;
    >
    >
    >
    > is implicitly static (file-scope) due to the top-level constness and foo
    >
    > can be used as compile-time constant expression. This is by design
    >
    > because B. Stroustrup doesn't like macros very much, either.
    >
    >
    >
    > I sort of accepted this difference between C and C++. In C you just have
    >
    > to #define something like this in order to be able to use it as the size
    >
    > of a non-VL array. But I would appreciate it if this unnecessary
    >
    > incompatibility went away...


    yes, i know; i dislike #define and must to switch to c++ compatybility modeto compile
    my besides that pure c codes

    it is terrible, it should just change becouse
    in other way though I am c (not c++) coder I must throw c compilers to trashbin - becouse
    I dislike macros and do not use no one of them

    c should just accept

    const int table_max = 1000;
    int table[table_max};

    I do not know where this no 'const int array boundaries' dirty shit originates
    but it seem to me that in older c there it was possible to use const ints as array boundaries, (not sure to this, usualy switched to c++ mode to resolve other old c troubles with int i before for loop and so :/ )

    make c const int usable in c, call the comitee or compiler writers to include some switch :/
     
    fir, Nov 18, 2012
    #4
  5. fir

    SG Guest

    Am 18.11.2012 11:02, schrieb fir:
    > W dniu niedziela, 18 listopada 2012 10:41:55 UTC+1 użytkownik SG napisał:
    >> Am 18.11.2012 10:21, schrieb fir:
    >>
    >>> It is sad to say so but there is some real
    >>> and terrible stupidnes in c99. When i wrote
    >>> programs in c (and I am involved c user) I
    >>> just use const int for array boundaries but
    >>> in c99 (and some previous too, terribly) it
    >>> will not compile (see for example
    >>> http://stackoverflow.com/questions/1712592/ )


    [snip]

    >> To my knowledge this has been the way in C for ever.


    [snip]

    >> of a non-VL array. But I would appreciate it if this unnecessary
    >> incompatibility went away...

    >
    > yes, i know; i dislike #define and must to switch to c++ compatybility mode to compile
    > my besides that pure c codes


    [snip]

    > c should just accept
    >
    > const int table_max = 1000;
    > int table[table_max};
    >
    > I do not know where this no 'const int array boundaries' dirty shit originates
    > but it seem to me that in older c there it was possible to use const ints as array boundaries, (not sure to this, usualy switched to c++ mode to resolve other old c troubles with int i before for loop and so :/ )


    I don't think you're right. "older C" wasn't "better" in that respect.
     
    SG, Nov 18, 2012
    #5
  6. fir

    fir Guest

    >
    >
    > I don't think you're right. "older C" wasn't "better" in that respect.


    ok :-(
     
    fir, Nov 18, 2012
    #6
  7. On Nov 18, 9:21 am, fir <> wrote:

    > It is sad to say so but there is some real
    > and terrible stupidnes in c99. When i wrote
    > programs in c (and I am involved c user) I
    > just use const int for array boundaries


    no you didn't

    > but
    > in c99 (and some previous too, terribly)


    all previous

    > it
    > will not compile (see for examplehttp://stackoverflow.com/questions/1712592/variably-modified-array-at... ) It is terribly wrong
    > thing for ppl who just wants to use const int to this
    > purposes and not to use preprocesor - as I do.
    > It is terribly stupidness in my opinion, it have to
    > be changed.


    :)

    C changes pretty slowly so don't hold your breath
     
    Nick Keighley, Nov 18, 2012
    #7
  8. fir <> writes:
    <snip>
    > I do not know where this no 'const int array boundaries' dirty shit
    > originates but it seem to me that in older c there it was possible to
    > use const ints as array boundaries, (not sure to this, usualy switched
    > to c++ mode to resolve other old c troubles with int i before for loop
    > and so :/ )


    It seems you've been writing C++ for some years now, so why not just be
    a happy C++ programmer rather than an unhappy C one?

    --
    Ben.
     
    Ben Bacarisse, Nov 18, 2012
    #8
  9. fir

    fir Guest

    W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:
    > fir <> writes:
    >
    > <snip>
    >
    > > I do not know where this no 'const int array boundaries' dirty shit

    >
    > > originates but it seem to me that in older c there it was possible to

    >
    > > use const ints as array boundaries, (not sure to this, usualy switched

    >
    > > to c++ mode to resolve other old c troubles with int i before for loop

    >
    > > and so :/ )

    >
    >
    >
    > It seems you've been writing C++ for some years now, so why not just be
    >
    > a happy C++ programmer rather than an unhappy C one?
    >


    becouse i dislike all c++ features (and soul), and deply appreciate most ofc features (and its spirit), this

    const int table_max = 100;
    int table[table_max];

    i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change
    to c++ becouse of some old c slight quirks
    and was unaware that this terrible const int
    boundary distaster is present here
     
    fir, Nov 18, 2012
    #9
  10. fir <> writes:

    You might want to look into using either the older Google groups
    interface or a stand-alone news reader. The new Google groups seems to
    mess up posts that go to Usenet very badly. (You might also consider
    using your shift key.)

    > W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:
    >> fir <> writes:
    >>
    >> <snip>
    >>
    >> > I do not know where this no 'const int array boundaries' dirty shit

    >>
    >> > originates but it seem to me that in older c there it was possible to

    >>
    >> > use const ints as array boundaries, (not sure to this, usualy switched

    >>
    >> > to c++ mode to resolve other old c troubles with int i before for loop

    >>
    >> > and so :/ )

    >>
    >>
    >>
    >> It seems you've been writing C++ for some years now, so why not just be
    >>
    >> a happy C++ programmer rather than an unhappy C one?
    >>

    >
    > becouse i dislike all c++ features (and soul), and deply appreciate
    > most of c features (and its spirit),


    You obviously don't dislike all C++ features since you want C to adopt
    one of them!

    > this
    > const int table_max = 100;
    > int table[table_max];


    You don't *have* to use a macro. You can use an enum constant instead:

    enum { table_max = 100 };
    int table[table_max];

    > i consider as it should belong to c language also It should be, it is
    > terrible that it fails here, (indeed i write in c but i change to c++
    > becouse of some old c slight quirks and was unaware that this terrible
    > const int boundary distaster is present here


    You have only two realistic options: keep using C++, or switch back to C
    and use a macro or an enum. There is no hope at all that the C
    committee will change the meaning of const any time soon. It's likely
    to be 10 years before the next major revision of the language and even
    then I don't think it's likely. If you want to try, posting here is
    going to be of little use. You'll need a proposal and, probably,
    backing from your national standards body.

    BTW, I agree with you in theory: C should have used C++'s meaning of
    const from the start, but back in the late 80s no one new that C++ would
    become what it has, and C compilers were already using the more
    restricted notion that became standard.

    --
    Ben.
     
    Ben Bacarisse, Nov 18, 2012
    #10
  11. fir

    fir Guest

    W dniu niedziela, 18 listopada 2012 15:24:34 UTC+1 użytkownik Ben Bacarisse napisał:
    > fir <> writes:
    >
    >
    >
    > You might want to look into using either the older Google groups
    >
    > interface or a stand-alone news reader. The new Google groups seems to
    >
    > mess up posts that go to Usenet very badly. (You might also consider
    >
    > using your shift key.)
    >
    >
    >
    > > W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:

    >
    > >> fir <> writes:

    >
    > >>

    >
    > >> <snip>

    >
    > >>

    >
    > >> > I do not know where this no 'const int array boundaries' dirty shit

    >
    > >>

    >
    > >> > originates but it seem to me that in older c there it was possible to

    >
    > >>

    >
    > >> > use const ints as array boundaries, (not sure to this, usualy switched

    >
    > >>

    >
    > >> > to c++ mode to resolve other old c troubles with int i before for loop

    >
    > >>

    >
    > >> > and so :/ )

    >
    > >>

    >
    > >>

    >
    > >>

    >
    > >> It seems you've been writing C++ for some years now, so why not just be

    >
    > >>

    >
    > >> a happy C++ programmer rather than an unhappy C one?

    >
    > >>

    >
    > >

    >
    > > becouse i dislike all c++ features (and soul), and deply appreciate

    >
    > > most of c features (and its spirit),

    >
    >
    >
    > You obviously don't dislike all C++ features since you want C to adopt
    >
    > one of them!
    >
    >
    >
    > > this

    >
    > > const int table_max = 100;

    >
    > > int table[table_max];

    >
    >
    >
    > You don't *have* to use a macro. You can use an enum constant instead:
    >
    >
    >
    > enum { table_max = 100 };
    >
    > int table[table_max];
    >
    >
    >
    > > i consider as it should belong to c language also It should be, it is

    >
    > > terrible that it fails here, (indeed i write in c but i change to c++

    >
    > > becouse of some old c slight quirks and was unaware that this terrible

    >
    > > const int boundary distaster is present here

    >
    >
    >
    > You have only two realistic options: keep using C++, or switch back to C
    >
    > and use a macro or an enum. There is no hope at all that the C
    >
    > committee will change the meaning of const any time soon. It's likely
    >
    > to be 10 years before the next major revision of the language and even
    >
    > then I don't think it's likely. If you want to try, posting here is
    >
    > going to be of little use. You'll need a proposal and, probably,
    >
    > backing from your national standards body.
    >
    >
    >
    > BTW, I agree with you in theory: C should have used C++'s meaning of
    >
    > const from the start, but back in the late 80s no one new that C++ would
    >
    > become what it has, and C compilers were already using the more
    >
    > restricted notion that became standard.
    >


    I could try to talk with some ppl in this comitee if i would konow how to do it, couse
    I am curious what they would say to me

    (though have neber tried this yet)

    I am far involved in area of c language
    improvements, as I said few weeks ago,
    and I am working on my own compiler and
    language (which I consider is still c )

    so one options is to write my own
    compiler (can do, and will do that)

    other option is also to say to some
    compiler makers to make some switch which
    would accept const ints as array boundaries
    (though they probably would say that i can
    use c-like subset of c++ as I am doing
    now (it is ok though i would feel bad if
    it would be named as writing in c++, I am
    absolutely c spitit not c++ programmer
     
    fir, Nov 18, 2012
    #11
  12. fir

    fir Guest

    >
    > language (which I consider is still c )
    >


    or, at least, I would like it to be still c
    (this may need some smewhat difficult care
    maybe to feel what c is, especially on improved
    area :-()
     
    fir, Nov 18, 2012
    #12
  13. fir

    James Kuyper Guest

    On 11/18/2012 04:21 AM, fir wrote:
    > It is sad to say so but there is some real
    > and terrible stupidnes in c99. When i wrote
    > programs in c (and I am involved c user) I
    > just use const int for array boundaries but
    > in c99 (and some previous too, terribly) it
    > will not compile (see for example
    > http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
    > thing for ppl who just wants to use const int to this
    > purposes and not to use preprocesor - as I do.
    > It is terribly stupidness in my opinion, it have to
    > be changed.


    In C++, a const object initialized with a constant expression can itself
    be used as a constant expression, but in C, this is not the case, and it
    has never been the case. You're wrong when you claim to have previously
    written C programs where such code worked. Perhaps you actually compiled
    them as C++?

    I like this feature of C++, and favor it's adoption in C. It would not
    break any strictly conforming code, and would allows better type safety
    than is provided by the C alternatives. However, describing this as a
    stupid feature of C ignores the fact that C does provide perfectly
    workable alternatives, such
    #define CONSTANT 4
    or
    enum {CONSTANT=4};

    Constant expressions are required in the following cases (and possibly
    others that I missed):
    _Alignas(CONSTANT)/*C2011*/ static struct {
    unsigned bit_field:CONSTANT
    } array[CONSTANT] = {
    [CONSTANT/2].bit_field /*C99*/ = CONSTANT
    };
    enum {OTHER=CONSTANT};
    case CONSTANT:
    #if CONSTANT
    #elif CONSTANT
    _Static_assert(CONSTANT, "CONSTANT is 0"); /*C2011*/

    C99 didn't make this issue any worse - in fact, C99 no longer required
    the use of constant expressions for array dimensions unless the array
    was defined with static storage duration (as was the case in your code)
    (in C2011, constants are also required for the dimensions of arrays with
    thread storage duration). When you don't use a constant expression, the
    result is a Variable Length Array, as was mentioned in the title of your
    stackoverflow question.

    As a result, if you need to have global access to the array (which
    suggests that your program is poorly designed), there is another
    alternative in C99 or later:

    types.h:
    static const int NUM_TYPES = 4;
    extern int *types;

    main.c:
    #include <types.h>
    int *types;
    int main(void)
    {
    int type_list[NUM_TYPES] = {
    1,
    2,
    3,
    4 };
    types = type_list;
    // The rest of your program.
    }

    Is there any reason why none of the C alternatives described above would
    be acceptable for use in your program?
    --
    James Kuyper
     
    James Kuyper, Nov 18, 2012
    #13
  14. fir

    James Kuyper Guest

    On 11/18/2012 09:50 AM, fir wrote:
    >>
    >> language (which I consider is still c )
    >>

    >
    > or, at least, I would like it to be still c
    > (this may need some smewhat difficult care
    > maybe to feel what c is, especially on improved
    > area :-()


    You compiler could qualify as C, so long as every feature that it
    supports which deviates from the requirements specified by the standard
    can either be disabled by a compiler option, or requires the use of a
    #pragma or a C feature with undefined behavior to enable it. If your
    extension always involves something that constitutes a syntax error or a
    constraint violation in C, your compiler can fully conform to the
    standard simply by issuing a diagnostic message (such as "Warning: this
    program relies upon our file scope VLA extension to standard C")
    whenever the program uses the feature.

    However, you'll need to know precisely what the C standard requires, in
    order to meet those requirements. Since this issue surprised you, and
    particularly since you mis-identified it as something new in C99, I
    suspect that you have a lot to learn before you'll be able to build a
    standard-conforming implementation of C.
    --
    James Kuyper
     
    James Kuyper, Nov 18, 2012
    #14
  15. fir

    fir Guest

    this question on stack overflow was not mine, just found it ocasionally

    >
    > Is there any reason why none of the C alternatives described above would
    > be acceptable for use in your program?
    >


    #define is not acceptable by me I dislike
    using preprocessor and use only few includes
    (do not like it either) and nothing more of it

    enum would be eventually hardly acceptable
    but its just bad (from my aestehetic point of
    view), nothing else to say :<
     
    fir, Nov 18, 2012
    #15
  16. fir

    fir Guest

    W dniu niedziela, 18 listopada 2012 18:22:47 UTC+1 użytkownik Kenneth Brody napisał:
    > On 11/18/2012 8:27 AM, fir wrote:
    >
    > > W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:

    >
    > [...]
    >
    > >> It seems you've been writing C++ for some years now, so why not just be

    >
    > >> a happy C++ programmer rather than an unhappy C one?

    >
    > >>

    >
    > >

    >
    > > becouse i dislike all c++ features (and soul), and deply appreciate most of c features (and its spirit), this

    >
    > >

    >
    > > const int table_max = 100;

    >
    > > int table[table_max];

    >
    > >

    >
    > > i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change

    >
    > > to c++ becouse of some old c slight quirks

    >
    > > and was unaware that this terrible const int

    >
    > > boundary distaster is present here

    >
    >
    >
    > I find it highly unlikely that this fart of the language will change,
    >
    > considering the fact that you can have:
    >
    >
    >
    > ===== file1.c
    >
    >
    >
    > const int table_max = 100;
    >
    >
    >
    > ===== file2.c
    >
    >
    >
    > extern const int table_max;
    >
    >
    >
    > .... references to "table_max" that cannot be a compile-time constant ...
    >
    >


    here, it should be just some requirement that
    array boundary const int must be defined in the
    same module as aray itself (end compile error
    if not) it is not general problem with const int here
     
    fir, Nov 18, 2012
    #16
  17. fir

    Ben Pfaff Guest

    fir <> writes:

    > It is sad to say so but there is some real
    > and terrible stupidnes in c99. When i wrote
    > programs in c (and I am involved c user) I
    > just use const int for array boundaries but
    > in c99 (and some previous too, terribly) it
    > will not compile (see for example
    > http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
    > thing for ppl who just wants to use const int to this
    > purposes and not to use preprocesor - as I do.
    > It is terribly stupidness in my opinion, it have to
    > be changed.


    Just use an enum.

    enum { LIMIT = 10 };
    int myarray[LIMIT];
     
    Ben Pfaff, Nov 18, 2012
    #17
  18. fir

    Eric Sosman Guest

    On 11/18/2012 12:11 PM, fir wrote:
    > this question on stack overflow was not mine, just found it ocasionally
    >
    >>
    >> Is there any reason why none of the C alternatives described above would
    >> be acceptable for use in your program?
    >>

    >
    > #define is not acceptable by me I dislike
    > using preprocessor and use only few includes
    > (do not like it either) and nothing more of it
    >
    > enum would be eventually hardly acceptable
    > but its just bad (from my aestehetic point of
    > view), nothing else to say :<


    In short, "stupidity" is "whatever offends fir's delicate
    aesthetic sensibilities."

    Are you related to Reginald Bunthorne?

    --
    Eric Sosman
    d
     
    Eric Sosman, Nov 18, 2012
    #18
  19. fir

    BartC Guest

    "Kenneth Brody" <> wrote in message
    news:...
    > On 11/18/2012 8:27 AM, fir wrote:


    >> const int table_max = 100;
    >> int table[table_max];


    > I find it highly unlikely that this fart of the language will change,
    > considering the fact that you can have:
    >
    > ===== file1.c
    >
    > const int table_max = 100;
    >
    > ===== file2.c
    >
    > extern const int table_max;
    >
    > .... references to "table_max" that cannot be a compile-time constant ...


    Why not? I can do this in another language (albeit using true named
    constants, rather than read-only variables, although the latter can be
    possible in the same way).

    In any case, the language ought to provide true named constants, which are
    pretty fundamental, not expect everyone to mess around with enums, defines,
    and const attributes. Then the above won't be a problem.

    --
    Bartc
     
    BartC, Nov 18, 2012
    #19
  20. fir

    fir Guest

    W dniu niedziela, 18 listopada 2012 21:10:33 UTC+1 użytkownik Eric Sosman napisał:
    > On 11/18/2012 12:11 PM, fir wrote:
    >
    > > this question on stack overflow was not mine, just found it ocasionally

    >
    > >

    >
    > >>

    >
    > >> Is there any reason why none of the C alternatives described above would

    >
    > >> be acceptable for use in your program?

    >
    > >>

    >
    > >

    >
    > > #define is not acceptable by me I dislike

    >
    > > using preprocessor and use only few includes

    >
    > > (do not like it either) and nothing more of it

    >
    > >

    >
    > > enum would be eventually hardly acceptable

    >
    > > but its just bad (from my aestehetic point of

    >
    > > view), nothing else to say :<

    >
    >
    >
    > In short, "stupidity" is "whatever offends fir's delicate
    >
    > aesthetic sensibilities."
    >
    >


    When I wrote some messages on this group
    (not many times that was my third visit here)
    really I often met a ppl which I see try to make 'much effort to not understand me'
    (Really, I see suc thing here)

    It would be hard to explain such basic
    things why

    coinst int table_max = 4096;

    is better than

    enum { table_max = 4096 }

    (this reason is not purely aesthetic but i
    meant that giving up with const ints here
    and go intu enums would be terrible aesthetic
    failure for me) Seem terribly obvious for me,
    and not seeing it end using enums here seem
    to be very stupid for me

    defines are not such stupid but preprocesor
    can be consideren not as part of c but some
    external tool to use over it (it was initialy
    considered like that, check out c history note)
    and i also treat it such way (as external tool
    over c, with not to much use for me personally)

    it is not to much speak here, just simple
    thing - imo the question is how to made this
    change in c language (If I would be C 'director' (I should be*) I would just
    change that

    * becouse I am really well prepared for this things :>
     
    fir, Nov 18, 2012
    #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. Mladen Adamovic
    Replies:
    3
    Views:
    11,027
  2. Replies:
    3
    Views:
    3,759
    Chris Torek
    Feb 20, 2006
  3. Replies:
    3
    Views:
    626
    Keith Thompson
    Mar 31, 2007
  4. Hendrik van Rooyen

    List mutation method gotcha - How well known?

    Hendrik van Rooyen, Mar 13, 2008, in forum: Python
    Replies:
    20
    Views:
    642
  5. Mike Treseler
    Replies:
    0
    Views:
    685
    Mike Treseler
    Feb 8, 2009
Loading...

Share This Page