reasoning for a macro

Discussion in 'C Programming' started by Mark, May 28, 2010.

  1. Mark

    Mark Guest

    Quite a lot people here argue about the use of complex macros, and it
    appears that the most of those who know the C language very well, recommend
    against the usage of macros, except some trivial cases. I'm trying to
    understand the reasoning for it, and what factors should I consider when
    deciding to have a macro or not.

    Consider this example. I'm implementing a serial interface over GPIO lines
    of a microcontroller; underlying procedure is to put '0' or '1' on pins, and
    higher level functions are based on it. So I considered to wrap the API
    dealing with GPIO registers in macro:

    #define SET_BIT0(pin) \
    do { \
    gpio_out(dev, (pin), 0); \
    gpio_outen(dev, (pin), (pin)); \
    while (0)

    #define SET_BIT1(pin) \
    do { \
    gpio_out(dev, (pin), (pin)); \
    gpio_outen(dev, (pin), (pin)); \
    while (0)

    ... and use these macros in the code implementing the guts of the serial
    interface (ticking sync clock, sending commands, acknowledges and so on).

    What would you say -- is it appropriate use of macro or it'd a way
    better/safer to put it in inline routines and if so, why?
    Thanks.

    --
    Mark
    Mark, May 28, 2010
    #1
    1. Advertising

  2. Mark

    Ian Collins Guest

    On 05/28/10 09:04 PM, Mark wrote:
    > Quite a lot people here argue about the use of complex macros, and it
    > appears that the most of those who know the C language very well,
    > recommend against the usage of macros, except some trivial cases. I'm
    > trying to understand the reasoning for it, and what factors should I
    > consider when deciding to have a macro or not.
    >
    > Consider this example. I'm implementing a serial interface over GPIO
    > lines of a microcontroller; underlying procedure is to put '0' or '1' on
    > pins, and higher level functions are based on it. So I considered to
    > wrap the API dealing with GPIO registers in macro:
    >
    > #define SET_BIT0(pin) \
    > do { \
    > gpio_out(dev, (pin), 0); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)
    >
    > #define SET_BIT1(pin) \
    > do { \
    > gpio_out(dev, (pin), (pin)); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)


    Missing '}'

    > ... and use these macros in the code implementing the guts of the serial
    > interface (ticking sync clock, sending commands, acknowledges and so on).
    >
    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?


    I'd say it was a gratuitous use of macros. Just use a function and rely
    on the compiler to inline them, a function is clearer (no pointless
    while{}) and easier to debug (you can step into it).

    --
    Ian Collins
    Ian Collins, May 28, 2010
    #2
    1. Advertising

  3. Mark

    bart.c Guest

    "Mark" <> wrote in message
    news:hto0v2$lcn$...
    > Quite a lot people here argue about the use of complex macros, and it


    > #define SET_BIT0(pin) \
    > do { \
    > gpio_out(dev, (pin), 0); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)
    >
    > #define SET_BIT1(pin) \
    > do { \
    > gpio_out(dev, (pin), (pin)); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)
    >
    > .. and use these macros in the code implementing the guts of the serial
    > interface (ticking sync clock, sending commands, acknowledges and so on).
    >
    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?


    These macros aren't complex, they're a fairly reasonable use of macros.

    But since they already contain function calls, there seems little to lose
    from using functions for them instead. (And having also set_bit(pin,value),
    instead of only having dedicated set_bit0/set_bit1 routines.)

    Also you won't have to bother with that do...while(0) stuff which might
    baffle some people.

    (BTW is there a "}" missing from those macros? And a '1' from the second
    gpio_out call?)

    --
    Bartc
    bart.c, May 28, 2010
    #3
  4. "Mark" <> writes:

    > Quite a lot people here argue about the use of complex macros, and it
    > appears that the most of those who know the C language very well,
    > recommend against the usage of macros, except some trivial cases. I'm
    > trying to understand the reasoning for it, and what factors should I
    > consider when deciding to have a macro or not.


    I am surprised that you formed this opinion without picking up the
    reasoning. My recollection is that most people will comment on a macros
    and explain why it is best to avoid using them at the same time. Maybe
    there's been a spate of blank "don't use macros".

    > Consider this example. I'm implementing a serial interface over GPIO
    > lines of a microcontroller; underlying procedure is to put '0' or '1'
    > on pins, and higher level functions are based on it. So I considered
    > to wrap the API dealing with GPIO registers in macro:
    >
    > #define SET_BIT0(pin) \
    > do { \
    > gpio_out(dev, (pin), 0); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)
    >
    > #define SET_BIT1(pin) \
    > do { \
    > gpio_out(dev, (pin), (pin)); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)


    This missing } is one reason right there. When you use this macro, the
    error will show up some way away. In fact it could be dozens of lines
    later.

    Oddest of all, though, is why do you have two of these? That's twice
    the chance to make a mistake.

    > .. and use these macros in the code implementing the guts of the
    > serial interface (ticking sync clock, sending commands, acknowledges
    > and so on).
    >
    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?


    No, I use a function. I would not even bother it see it was inlined.
    the lowness of IO almost always trumps the speed of a function call and
    return though I admit that your IO may be different since I don't know
    the device you are using. Anyway, you risk confusing error messages,
    bugs due to double evaluation of 'pin', more obscure code, harder
    testing and debugging for a dubious advantage.

    When compilers were less sophisticated and machines were slower, the
    pay-of was was higher, but I have gradually unlearnt my desire to reach
    for a macro. There are reasons to use them, but they usually involve
    things you can't do with a function.

    --
    Ben.
    Ben Bacarisse, May 28, 2010
    #4
  5. Mark

    Eric Sosman Guest

    On 5/28/2010 5:04 AM, Mark wrote:
    > Quite a lot people here argue about the use of complex macros, and it
    > appears that the most of those who know the C language very well,
    > recommend against the usage of macros, except some trivial cases. I'm
    > trying to understand the reasoning for it, and what factors should I
    > consider when deciding to have a macro or not.


    It seems to me you've read much more into the debate than is
    actually there. "Macros aren't right for everything" is not the
    same as "Don't use macros."

    > Consider this example. I'm implementing a serial interface over GPIO
    > lines of a microcontroller; underlying procedure is to put '0' or '1' on
    > pins, and higher level functions are based on it. So I considered to
    > wrap the API dealing with GPIO registers in macro:
    >
    > #define SET_BIT0(pin) \
    > do { \
    > gpio_out(dev, (pin), 0); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)
    >
    > #define SET_BIT1(pin) \
    > do { \
    > gpio_out(dev, (pin), (pin)); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)
    >
    > .. and use these macros in the code implementing the guts of the serial
    > interface (ticking sync clock, sending commands, acknowledges and so on).


    Lotsa luck. Others have pointed out the missing brace; it also
    looks like you may have messed up the third argument to gpio_out() in
    one or the other macro. The hard-wired identifier `dev' is suspect,
    unless it's some kind of well-known program-wide thing on a par with
    `stdin' and `errno' (in which case it probably ought to have a more
    descriptive name than merely `dev').

    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?


    I find it hard to imagine a program in which the macros you've
    shown would be helpful. I can't say whether cleaned-up and corrected
    versions would be, because you haven't explained enough about the
    situation. What advantage are you trying to obtain by macroizing
    the thing rather than using a function or using open code? Why do
    you write two macros/functions when it appears one might suffice?

    Macros -- or functions, or arrays, or loops -- are not appropriate
    or inappropriate in isolation, but only with reference to an objective
    and the constraints that surround it. We don't know enough.

    --
    Eric Sosman
    lid
    Eric Sosman, May 28, 2010
    #5
  6. Mark

    ImpalerCore Guest

    On May 28, 5:04 am, "Mark" <> wrote:
    > Quite a lot people here argue about the use of complex macros, and it
    > appears that the most of those who know the C language very well, recommend
    > against the usage of macros, except some trivial cases. I'm trying to
    > understand the reasoning for it, and what factors should I consider when
    > deciding to have a macro or not.


    I often use macros in the case where I want to codify some expression,
    but have it work over multiple types. The use macros becomes a cost
    benefit analysis between the lack of type safety and other inherent
    problems of macros against defining code segments that function over
    multiple types. For example, consider my macro implementation for
    setting a bit in an arbitrary unsigned integer.

    \code snippet
    /*!
    * \brief Define the integer type used to create a bitmask of zeros
    with
    * the least-significant bit enabled.
    *
    * One of the basic constructs used in the \c bits macro library is to
    * create a mask that is all zero except for a single bit at a given
    * index. This is often implemented using the simple expression
    * <tt>1 << index</tt>. This is used to isolate single bits to be set
    * or cleared within an integer.
    *
    * There is a caveat to consider when using this expression. The
    issue
    * is that the value of \c 1 is evaluated to be of type integer. For
    * environments where the integer type is 16-bit, this expression will
    * fail when trying to set a bit with an index >= 16 in a 32-bit long
    * integer. A similar problem arises for 32-bit environments when
    * trying to use \c 1 to set a bit at index >= 32 in a 64-bit integer.
    * If this is an issue, there will typically be a warning that says
    * that the left shift count is larger than the width of the integer
    * type. If this error is found, \c C_BITS_ONE will need to be
    defined
    * as a larger integer type.
    *
    * The method to increase the width used by the macro library is to
    * specify the type explicitly. This can be specified using a
    stdint.h
    * constant like <tt>UINT64_C(1)</tt> to enable support for 64-bit
    * integers. Keep in mind that increasing the width beyond the
    default
    * integer type for the processor may incur a performance penalty for
    * all macros.
    *
    * Ideally this should be configured using Autoconf or a Makefile, but
    * for now its location is here. The \c C_BITS_ONE define can be \c 1
    * for \c int sized masks, <tt>UINT32_C(1)</tt> to enable 32-bit
    support
    * on 16-bit integer platforms, or <tt>UINT64_C(1)</tt> to enable 64-
    bit
    * support.
    */
    #define C_BITS_ONE (UINT32_C(1))

    /*!
    * \brief Set a single bit at \c INDEX in \c WORD.
    * \param WORD The word.
    * \param INDEX The bit index.
    *
    * The \c INDEX range is from [0,N-1] where N is the number of bits
    * of the \c WORD integer type.
    */
    #define C_SET_BIT(WORD, INDEX) (WORD |= (C_BITS_ONE << (INDEX)))
    \endcode

    If I were to define a function implementation, I would need to
    maintain practically duplicate code for a myriad of different types.

    void set_bit8( uint8_t* b );
    void set_bit16( uint16_t* w );
    void set_bit32( uint32_t* dw );
    void set_bit64( uint64_t* qw );

    I decided to go with macros to implement my bit hacking primarily
    because imo the overhead of implementing these functions with the lack
    of templates is too high. There is also a very interesting article (I
    think it's Scott Meyers) about comparing min/max in C++ with the C
    macro version.

    I also use macros to wrap type casting for generic containers, as I
    think it simplifies the syntax of the interface in a beneficial way
    that outweighs the cons of using macros. There may be people who
    disagree, but I'm ok with that.

    > Consider this example. I'm implementing a serial interface over GPIO lines
    > of a microcontroller; underlying procedure is to put '0' or '1' on pins, and
    > higher level functions are based on it. So I considered to wrap the API
    > dealing with GPIO registers in macro:
    >
    > #define SET_BIT0(pin) \
    >     do { \
    >         gpio_out(dev, (pin), 0); \
    >         gpio_outen(dev, (pin), (pin)); \
    >     while (0)
    >
    > #define SET_BIT1(pin) \
    >     do { \
    >         gpio_out(dev, (pin), (pin)); \
    >         gpio_outen(dev, (pin), (pin)); \
    >     while (0)
    >
    > .. and use these macros in the code implementing the guts of the serial
    > interface (ticking sync clock, sending commands, acknowledges and so on).


    If I were to look at this, I would say that this doesn't need the type
    independence provided by macros, and hence is better off in a
    function, inlined if needed and it's available on your compiler.

    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?


    Inline function is my recommendation.

    Best regards,
    John D.

    > Thanks.
    >
    > --
    > Mark
    ImpalerCore, May 28, 2010
    #6
  7. Mark

    Seebs Guest

    On 2010-05-28, Mark <> wrote:
    > Quite a lot people here argue about the use of complex macros, and it
    > appears that the most of those who know the C language very well, recommend
    > against the usage of macros, except some trivial cases. I'm trying to
    > understand the reasoning for it, and what factors should I consider when
    > deciding to have a macro or not.


    Okay.

    > Consider this example. I'm implementing a serial interface over GPIO lines
    > of a microcontroller; underlying procedure is to put '0' or '1' on pins, and
    > higher level functions are based on it. So I considered to wrap the API
    > dealing with GPIO registers in macro:


    > #define SET_BIT0(pin) \
    > do { \
    > gpio_out(dev, (pin), 0); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)


    Okay.

    > #define SET_BIT1(pin) \
    > do { \
    > gpio_out(dev, (pin), (pin)); \
    > gpio_outen(dev, (pin), (pin)); \
    > while (0)


    I'm a bit surprised that 0 changes to (pin) rather than to 1 here, but okay.

    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?
    > Thanks.


    I'd probably write these as functions without even thinking about it. I
    could easily imagine someone writing:

    pin = first;
    while (pin < last)
    SET_BIT0(pin++);

    Note that the macros as provided have at least one error ({ without }).

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 28, 2010
    #7
  8. On May 28, 4:04 pm, "Mark" <> wrote:
    > ... recommend
    > against the usage of macros, except some trivial cases.


    I once used a device whose programming
    took the form
    SPE[0] = command;
    SPE[1] = datum;
    for writes and
    SPE[0] = command;
    datum = SPE[1];
    for reads.

    I wrote a macro something like
    #define CTRLR(command) \
    (*(SPE[0] = command, &SPE[1]))
    so that writes and reads would have ordinary forms:
    CTRLR(command) = datum;
    or
    datum = CTRLR(command);


    What do c.l.c'ers think of that?
    Bad? Very bad? Horrifying?

    James Dow Allen
    James Dow Allen, May 29, 2010
    #8
  9. Mark

    Nick Guest

    James Dow Allen <> writes:

    > On May 28, 4:04 pm, "Mark" <> wrote:
    >> ... recommend
    >> against the usage of macros, except some trivial cases.

    >
    > I once used a device whose programming
    > took the form
    > SPE[0] = command;
    > SPE[1] = datum;
    > for writes and
    > SPE[0] = command;
    > datum = SPE[1];
    > for reads.
    >
    > I wrote a macro something like
    > #define CTRLR(command) \
    > (*(SPE[0] = command, &SPE[1]))
    > so that writes and reads would have ordinary forms:
    > CTRLR(command) = datum;
    > or
    > datum = CTRLR(command);
    >
    >
    > What do c.l.c'ers think of that?
    > Bad? Very bad? Horrifying?


    In that it plays with the language syntax it ought to be frowned upon.
    But with a comment along the lines of this post attached to the macro
    definition I actually quite like it.
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
    Nick, May 29, 2010
    #9
  10. Mark

    Ian Collins Guest

    On 05/29/10 05:50 PM, James Dow Allen wrote:
    > On May 28, 4:04 pm, "Mark"<> wrote:
    >> ... recommend
    >> against the usage of macros, except some trivial cases.

    >
    > I once used a device whose programming
    > took the form
    > SPE[0] = command;
    > SPE[1] = datum;
    > for writes and
    > SPE[0] = command;
    > datum = SPE[1];
    > for reads.
    >
    > I wrote a macro something like
    > #define CTRLR(command) \
    > (*(SPE[0] = command,&SPE[1]))
    > so that writes and reads would have ordinary forms:
    > CTRLR(command) = datum;
    > or
    > datum = CTRLR(command);
    >
    >
    > What do c.l.c'ers think of that?
    > Bad? Very bad? Horrifying?


    Nice one. It's the sort of trick I often use in C++ (although not with
    a macro) but it's the first time I've seen something like it in C.

    --
    Ian Collins
    Ian Collins, May 29, 2010
    #10
  11. Mark

    Stargazer Guest

    On May 28, 12:04 pm, "Mark" <> wrote:
    > Quite a lot people here argue about the use of complex macros, and it
    > appears that the most of those who know the C language very well, recommend
    > against the usage of macros, except some trivial cases. I'm trying to
    > understand the reasoning for it, and what factors should I consider when
    > deciding to have a macro or not.
    >
    > Consider this example. I'm implementing a serial interface over GPIO lines
    > of a microcontroller; underlying procedure is to put '0' or '1' on pins, and
    > higher level functions are based on it. So I considered to wrap the API
    > dealing with GPIO registers in macro:
    >
    > #define SET_BIT0(pin) \
    >     do { \
    >         gpio_out(dev, (pin), 0); \
    >         gpio_outen(dev, (pin), (pin)); \
    >     while (0)
    >
    > #define SET_BIT1(pin) \
    >     do { \
    >         gpio_out(dev, (pin), (pin)); \
    >         gpio_outen(dev, (pin), (pin)); \
    >     while (0)
    >
    > .. and use these macros in the code implementing the guts of the serial
    > interface (ticking sync clock, sending commands, acknowledges and so on).
    >
    > What would you say -- is it appropriate use of macro or it'd a way
    > better/safer to put it in inline routines and if so, why?
    > Thanks.


    The reason for macros is to make the code that using them simpler /
    more convenient than it would be otherwise. Your particular example is
    probably bad, because (besides the obvious missing '}') it is
    unnecessary complicating the interface. Having two separate macros for
    doing the same thing - set GPIO bit to a value - is bad, in my
    opinion. If use macros at all (what is bad with original function
    gpio_out(), which is called anyway?) then it's better something like
    `#define GPIO_SET_BIT(pin, value) gpio_out(dev, (pin), (value & 1) <<
    (pin));' (assuming that "pin" is a bit-mask of appropriate GPIO pin,
    (1 << pin_number)).

    Macros are processed by the preprocessor, which does only simple text
    substitution; no language syntax analysis takes place. That is, if you
    make a syntactic mistake (such as missing '}'), it will be pasted all
    over the code, resulting in as many compiler's errors as there are
    macro replacements.

    Also, macros should be used with tested code, as they will make harder
    functional debugging. Your code is functionally suspicious - GPIO
    enables and direction should be set correctly before using the port;
    also there is usually no need to change the "enable" assingments after
    system init (certainly not with every GPIO output).

    Daniel
    Stargazer, May 30, 2010
    #11
  12. Mark

    spinoza1111 Guest

    On May 29, 4:35 am, Seebs <> wrote:
    > On 2010-05-28, Mark <> wrote:
    >
    > > Quite a lot people here argue about the use of complex macros, and it
    > > appears that the most of those who know the C language very well, recommend
    > > against the usage of macros, except some trivial cases. I'm trying to
    > > understand the reasoning for it, and what factors should I consider when
    > > deciding to have a macro or not.

    >
    > Okay.
    >
    > > Consider this example. I'm implementing a serial interface over GPIO lines
    > > of a microcontroller; underlying procedure is to put '0' or '1' on pins, and
    > > higher level functions are based on it. So I considered to wrap the API
    > > dealing with GPIO registers in macro:
    > > #define SET_BIT0(pin) \
    > >     do { \
    > >         gpio_out(dev, (pin), 0); \
    > >         gpio_outen(dev, (pin), (pin)); \
    > >     while (0)

    >
    > Okay.
    >
    > > #define SET_BIT1(pin) \
    > >     do { \
    > >         gpio_out(dev, (pin), (pin)); \
    > >         gpio_outen(dev, (pin), (pin)); \
    > >     while (0)

    >
    > I'm a bit surprised that 0 changes to (pin) rather than to 1 here, but okay.
    >
    > > What would you say -- is it appropriate use of macro or it'd a way
    > > better/safer to put it in inline routines and if so, why?
    > > Thanks.

    >
    > I'd probably write these as functions without even thinking about it.  I


    Why am I not surprised that you don't like thinking?

    > could easily imagine someone writing:
    >
    >         pin = first;
    >         while (pin < last)
    >                 SET_BIT0(pin++);


    Those of us who've studied computer science would know that macro
    parameters are evaluated by name and that each time the formal
    parameter name is used, the increment may occur depending on your
    sequence points mess. Therefore, we pass simple names to macros.

    Unlike you, we like to Think. You're the Don't Make Me Think
    generation, kid.

    Whereas hackers know only specific cases, like the lawyer in Bleak
    House who prides himself on reading only cases connected with Jarndyce
    v Jarndyce. For this reason, they live in a world where shit just
    happens, like the BP disaster.
    >
    > Note that the macros as provided have at least one error ({ without }).
    >
    > -s
    > --
    > Copyright 2010, all wrongs reversed.  PeterSeebach/ usenet-nos...@seebs..nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    spinoza1111, May 30, 2010
    #12
  13. Mark

    Rob Kendrick Guest

    On Sun, 30 May 2010 06:29:08 -0700 (PDT)
    spinoza1111 <> wrote:

    > Those of us who've studied computer science would know that macro
    > parameters are evaluated by name and that each time the formal
    > parameter name is used, the increment may occur depending on your
    > sequence points mess.


    Do you have any actual arguements other than this one to play at
    Seebs? Because this one's clearly faulty, given I've never studied
    computer science in any official sense, and I know this. And I also
    know people who have studied computer science officially who don't.

    B.
    Rob Kendrick, May 30, 2010
    #13
  14. Mark

    Seebs Guest

    On 2010-05-30, Rob Kendrick <> wrote:
    > On Sun, 30 May 2010 06:29:08 -0700 (PDT)
    > spinoza1111 <> wrote:


    >> Those of us who've studied computer science would know that macro
    >> parameters are evaluated by name and that each time the formal
    >> parameter name is used, the increment may occur depending on your
    >> sequence points mess.


    > Do you have any actual arguements other than this one to play at
    > Seebs? Because this one's clearly faulty, given I've never studied
    > computer science in any official sense, and I know this. And I also
    > know people who have studied computer science officially who don't.


    All he's doing is posting ever more outrageous nonsense to try to get the
    responses which validate him.

    Computer science has a lot to do with general principles of programming,
    and very little to do with the details of a given language. As always,
    anything that looks like a technical detail in a Nilges post is probably
    wrong; in this case, we have the lovely "evaluated by name", which
    is probably wrong, but may be insufficently coherent to be considered
    "wrong", on the grounds that it may not be stating a claim which could
    be considered right or wrong at all.

    It has nothing at all to do with whether or not the formal parameter name is
    used, and everything to do with whether the resulting code evaluates an
    expression repeatedly, and if so, how often.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 30, 2010
    #14
  15. Mark

    Mark Guest

    Thank to everyone who contributed to this topic, the concept of judicious
    use of macros is now clear to me.

    --
    Mark
    Mark, May 31, 2010
    #15
    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. blu4899
    Replies:
    4
    Views:
    1,718
    Bob Foster
    Oct 31, 2003
  2. Andy Baker

    Reasoning behind nested scope

    Andy Baker, Aug 3, 2004, in forum: Python
    Replies:
    6
    Views:
    319
    Nigel Rowe
    Aug 5, 2004
  3. Rick Spencer

    what's wrong with my popen reasoning?

    Rick Spencer, Feb 5, 2006, in forum: Python
    Replies:
    1
    Views:
    322
    Rick Spencer
    Feb 5, 2006
  4. GHUM
    Replies:
    1
    Views:
    248
    Marc 'BlackJack' Rintsch
    Oct 17, 2008
  5. small Pox
    Replies:
    5
    Views:
    251
    small Pox
    Dec 5, 2010
Loading...

Share This Page