Loading ...
Sorry, an error occurred while loading the content.

RE: [hackers-il] Sash

Expand Messages
  • Chen Shapira
    ... You forgot obfuscation, as in nyh s fine example: #define Xx putchar but lets go back to usage of macros and const: I can either use: #define PIE 4 or
    Message 1 of 25 , Jul 5 3:49 AM
    • 0 Attachment
      > Well, this is all fine as a matter of principle. In practice there
      > are other possible uses, such as encapsulating common code patterns
      > (careful!). But there is no reason to use macros for efficiency in
      > general or for inlining in particular.

      You forgot obfuscation, as in nyh's fine example:
      #define Xx putchar

      but lets go back to usage of macros and const:
      I can either use:
      #define PIE 4
      or
      const pie = 4

      when would I use what?
    • Oleg Goldshmidt
      ... You will use the macro only if you need to have double x[4]; in your code. You will prefer to write double x[PIE]; instead. In every other case you ll
      Message 2 of 25 , Jul 5 10:30 PM
      • 0 Attachment
        Chen Shapira <chen@...> writes:

        > but lets go back to usage of macros and const:
        > I can either use:
        > #define PIE 4
        > or
        > const pie = 4
        >
        > when would I use what?

        You will use the macro only if you need to have

        double x[4];

        in your code. You will prefer to write

        double x[PIE];

        instead. In every other case you'll prefer

        const int pie = 4;

        Believe me, some day you'll be very happy when it shows up in the
        debugger.

        --
        Oleg Goldshmidt <ogoldsh@...>
        "... We work but wit, and not by witchcraft;
        And wit depends on dilatory time." [Shakespeare]
      • Moshe Zadka
        ... Why not const int PIE = 4; (that removes the temptation to change PIE) -- Moshe Zadka There is no GOD but Python, and HTTP is its
        Message 3 of 25 , Jul 6 7:41 AM
        • 0 Attachment
          On 6 Jul 2000, Oleg Goldshmidt wrote:

          > Chen Shapira <chen@...> writes:
          >
          > > but lets go back to usage of macros and const:
          > > I can either use:
          > > #define PIE 4
          > > or
          > > const pie = 4
          > >
          > > when would I use what?
          >
          > You will use the macro only if you need to have
          >
          > double x[4];
          >
          > in your code. You will prefer to write
          >
          > double x[PIE];
          >
          > instead. In every other case you'll prefer
          >
          > const int pie = 4;

          Why not

          const int PIE = 4;

          (that removes the temptation to change PIE)
          --
          Moshe Zadka <moshez@...>
          There is no GOD but Python, and HTTP is its prophet.
        • Chen Shapira
          ... you are not debating the case of my letters, are you? there must be a subtle point here that I missed. Ofcourse I ll use standard conventions when coding.
          Message 4 of 25 , Jul 6 8:47 AM
          • 0 Attachment
            > Why not
            >
            > const int PIE = 4;
            >
            > (that removes the temptation to change PIE)

            you are not debating the case of my letters, are you? there must be a subtle
            point here that I missed.
            Ofcourse I'll use standard conventions when coding. I'll may even go as far
            as const int iPIE = 4, if my coworkers are Hugarian and ask me very very
            nicely.
            But that wasn't the point of the question. the point was #define vs. const.
          • Oleg Goldshmidt
            ... You temptations will be cut short by the compiler, though I see your stylistic point. ... He is debating the case of my letters ;-) ... Capitalized PIE
            Message 5 of 25 , Jul 6 11:06 AM
            • 0 Attachment
              Chen Shapira <chen@...> writes:

              > > Why not
              > >
              > > const int PIE = 4;
              > >
              > > (that removes the temptation to change PIE)

              You temptations will be cut short by the compiler, though I see your
              stylistic point.

              > you are not debating the case of my letters, are you?

              He is debating the case of my letters ;-)

              > there must be a subtle point here that I missed.

              Capitalized PIE will look like conventional macro and will stand out
              in the code, and you'll see your constants clearly. Decide for
              yourself if it is important or not.

              > Ofcourse I'll use standard conventions when coding. I'll may even go as far
              > as const int iPIE = 4, if my coworkers are Hugarian and ask me very very
              > nicely.

              Refuse. I firmly believe that the Hungarian convention is bad. It's a
              lot of visual garbage on top of (hopefully) meaningful identifiers,
              and when you decide that int iPIE has to become long int iPIE you will
              have to track all the occurrences of iPIE in all of your code and
              change them.

              More importantly. If you maintain any code written by your Hungarian
              (or Ukrainian) co-workers, maintain whatever conventions they happened
              to be using. Even if it is Hungarian.

              > But that wasn't the point of the question. the point was #define
              > vs. const.

              Just once again: const.

              --
              Oleg Goldshmidt <ogoldsh@...>
              "... We work but wit, and not by witchcraft;
              And wit depends on dilatory time." [Shakespeare]
            • Shlomi Fish
              ... Actually, when I programmed Freecell Solver I used macros for all the board and card access routines. I just did not want to take the risk that they will
              Message 6 of 25 , Jul 6 11:23 AM
              • 0 Attachment
                On Tue, 4 Jul 2000, Moshe Zadka wrote:

                > On Tue, 4 Jul 2000, Chen Shapira wrote:
                >
                > > Sash implements function such as isNumber() as macros. I usually impelement
                > > those as functions (actually using those in stdlib, but sash couldn't use
                > > those).
                > >
                > > If I have a very small function - when should I put it as macro?
                >
                > Never -- premature optimization, etc. If you do find a ned to optimize,
                > see if you can limit yourself to gcc and just use __inline__ (or, if you
                > have a C++ compiler, use inline and compile the C code as C++)
                >

                Actually, when I programmed Freecell Solver I used macros for all the
                board and card access routines. I just did not want to take the risk that
                they will run as functions with their extra overhead. I'm doing quite a
                lot of board and card lookups and movements there.

                Some of my macros would not have been possible as functions because they
                receive a struct as a parameter and operate on it. Naturally, passing an
                entire struct as a function argument is very impractical, and plus it
                cannot be modified. I suppose I would have used a pointer had I written
                them as functions.

                I think my program would be much slower if they were functions, and I did
                not think of gcc's inline at the time. Not to mention that I wanted it to
                compile on any C compiler including Microsoft Visual C++.

                Just my twenty agoroth.

                Shlomi Fish

                > --
                > Moshe Zadka <moshez@...>
                > There is no GOD but Python, and HTTP is its prophet.
                >
                >
                > ------------------------------------------------------------------------
                > Free Conference Calling with Firetalk!
                > Click Here!
                > http://click.egroups.com/1/5480/12/_/_/_/962699363/
                > ------------------------------------------------------------------------
                >
                > To unsubscribe from this group, send an email to:
                > hackers-il-unsubscribe@egroups.com
                >
                >
                >
                >



                ----------------------------------------------------------------------
                Shlomi Fish shlomif@...
                Home Page: http://t2.technion.ac.il/~shlomif/
                Home E-mail: shlomif@...

                The prefix "God Said" has the extraordinary logical property of
                converting any statement that follows it into a true one.
              • Moshe Zadka
                ... No, there isn t. It s just that this helps people who read the code itself (rather then the definition of PIE/pie) understand that it s a constant. Those
                Message 7 of 25 , Jul 6 11:25 AM
                • 0 Attachment
                  On Thu, 6 Jul 2000, Chen Shapira wrote:

                  >
                  > > Why not
                  > >
                  > > const int PIE = 4;
                  > >
                  > > (that removes the temptation to change PIE)
                  >
                  > you are not debating the case of my letters, are you? there must be a subtle
                  > point here that I missed.

                  No, there isn't. It's just that this helps people who read the code itself
                  (rather then the definition of PIE/pie) understand that it's a constant.
                  Those people don't give a flying f**k whether it's a #define or a const,
                  or just an int -- they want to know what the hell it is doing in your
                  code, and that is best documented by case.

                  --
                  Moshe Zadka <moshez@...>
                  There is no GOD but Python, and HTTP is its prophet.
                • Moshe Zadka
                  ... Optimizing before you even profile is very unproductive ... And the problem with always passing around pointers to structs is? ... Ummmmm...thinking before
                  Message 8 of 25 , Jul 6 11:54 AM
                  • 0 Attachment
                    On Thu, 6 Jul 2000, Shlomi Fish wrote:

                    > Actually, when I programmed Freecell Solver I used macros for all the
                    > board and card access routines. I just did not want to take the risk that
                    > they will run as functions with their extra overhead. I'm doing quite a
                    > lot of board and card lookups and movements there.

                    Optimizing before you even profile is very unproductive

                    > Some of my macros would not have been possible as functions because they
                    > receive a struct as a parameter and operate on it. Naturally, passing an
                    > entire struct as a function argument is very impractical, and plus it
                    > cannot be modified. I suppose I would have used a pointer had I written
                    > them as functions.

                    And the problem with always passing around pointers to structs is?

                    > I think my program would be much slower if they were functions, and I did
                    > not think of gcc's inline at the time. Not to mention that I wanted it to
                    > compile on any C compiler including Microsoft Visual C++.

                    Ummmmm...thinking before you type can be a valuable skill. MSVC++ has
                    inline by virtue of being a C++ compiler.

                    --
                    Moshe Zadka <moshez@...>
                    There is no GOD but Python, and HTTP is its prophet.
                  • Shlomi Fish
                    ... I beg your pardon, but I have some a priori knowledge about how my program is going to run, how many times a function will be called, and thus I have an
                    Message 9 of 25 , Jul 7 12:53 PM
                    • 0 Attachment
                      On Thu, 6 Jul 2000, Moshe Zadka wrote:

                      > On Thu, 6 Jul 2000, Shlomi Fish wrote:
                      >
                      > > Actually, when I programmed Freecell Solver I used macros for all the
                      > > board and card access routines. I just did not want to take the risk that
                      > > they will run as functions with their extra overhead. I'm doing quite a
                      > > lot of board and card lookups and movements there.
                      >
                      > Optimizing before you even profile is very unproductive
                      >

                      I beg your pardon, but I have some a priori knowledge about how my program
                      is going to run, how many times a function will be called, and thus I
                      have an idea of what to implement as a macro.

                      I don't think it is wise to write a program without a good thought about
                      he it should be optimized a priory. Writing code with poor performance
                      just to get a program which you can run, wastes more time in comparison
                      to thinking about the implementation and then writing a high-performance
                      code.

                      Don't get me wrong: I did have to optimize the code between Freecell
                      Solver 0.2 and Freecell Sovler 0.4, and as a result it now runs dozens of
                      time faster. But I still think my decision to use macros instead of
                      functions was in its place.

                      > > Some of my macros would not have been possible as functions because they
                      > > receive a struct as a parameter and operate on it. Naturally, passing an
                      > > entire struct as a function argument is very impractical, and plus it
                      > > cannot be modified. I suppose I would have used a pointer had I written
                      > > them as functions.
                      >
                      > And the problem with always passing around pointers to structs is?
                      >

                      There's no problem with that, only that a macro is still faster. Of course
                      a smart compiler that can handle inline functions _might_ optimize
                      functions which receives pointers to structures to the same speed of their
                      corresponding macros. But I didn't want to take that chance.

                      > > I think my program would be much slower if they were functions, and I did
                      > > not think of gcc's inline at the time. Not to mention that I wanted it to
                      > > compile on any C compiler including Microsoft Visual C++.
                      >
                      > Ummmmm...thinking before you type can be a valuable skill. MSVC++ has
                      > inline by virtue of being a C++ compiler.
                      >

                      Yes, but I wanted this code to be ANSI C, not C++. I'm not sure if MSVC
                      has inline support in ANSI C modules. And even if it has there are other
                      compilers (like all those crammy UNIX cc's) which don't. And I wanted to
                      stick to the stanard and not depend on a compiler specific feature.


                      If anynone would like to download the Freecell Solver source and see all
                      the macros which I had to write (actually I wrote two versions of each
                      macro), he can download it from my homepage:

                      http://vipe.technion.ac.il/~shlomif/freecell-solver/

                      FYI, Freecell Solver is freely distributable under the public domain.

                      > --
                      > Moshe Zadka <moshez@...>
                      > There is no GOD but Python, and HTTP is its prophet.
                      >
                      >
                      > ------------------------------------------------------------------------
                      > Remember four years of good friends, bad clothes, explosive chemistry
                      > experiments.
                      > http://click.egroups.com/1/5532/12/_/_/_/962909705/
                      > ------------------------------------------------------------------------
                      >
                      > To unsubscribe from this group, send an email to:
                      > hackers-il-unsubscribe@egroups.com
                      >
                      >
                      >
                      >



                      ----------------------------------------------------------------------
                      Shlomi Fish shlomif@...
                      Home Page: http://t2.technion.ac.il/~shlomif/
                      Home E-mail: shlomif@...

                      The prefix "God Said" has the extraordinary logical property of
                      converting any statement that follows it into a true one.
                    • Oleg Goldshmidt
                      ... I don t think there is extra overhead to an inlined function call as compared to a macro. They are basically the same. Of course, inlining is no more than
                      Message 10 of 25 , Jul 8 9:10 AM
                      • 0 Attachment
                        Shlomi Fish <shlomif@...> writes:

                        > Actually, when I programmed Freecell Solver I used macros for all the
                        > board and card access routines. I just did not want to take the risk that
                        > they will run as functions with their extra overhead.

                        I don't think there is extra overhead to an inlined function call as
                        compared to a macro. They are basically the same. Of course, inlining
                        is no more than a hint to the compiler, not a directive, so you cannot
                        be 100% sure that your function will be inlined. On the other hand,
                        it might be a good idea to trust the compiler that it has a good
                        reason not to inline.

                        If you are sure that none of the bad properties of C macros are
                        important, and the design arguments I listed are not important,
                        then there is no problem with macros. From your description, it looks
                        like you use them in your own code only, and not in an interface, so
                        the issues I listed are not relevant to you.

                        > Some of my macros would not have been possible as functions because they
                        > receive a struct as a parameter and operate on it. Naturally, passing an
                        > entire struct as a function argument is very impractical, and plus it
                        > cannot be modified. I suppose I would have used a pointer had I written
                        > them as functions.

                        Precisely.

                        > I think my program would be much slower if they were functions, and I did
                        > not think of gcc's inline at the time. Not to mention that I wanted it to
                        > compile on any C compiler including Microsoft Visual C++.

                        C++ compilers all have inline. If it is C code, then portability is an
                        issue indeed.

                        Overall, if I understand your situation correctly, you have a good
                        case, but caution is always in order.

                        --
                        Oleg Goldshmidt <ogoldsh@...>
                        "... We work but wit, and not by witchcraft;
                        And wit depends on dilatory time." [Shakespeare]
                      • Omer Mussaev
                        ... Can t be expressed better :) for example, I do not use upper-case for consts. This does not mattter much, since I believe that consitstency is above canon.
                        Message 11 of 25 , Jul 9 12:47 AM
                        • 0 Attachment
                          Oleg Goldshmidt wrote:

                          > Chen Shapira <chen@...> writes:
                          >
                          > > > Why not
                          > > >
                          > > > const int PIE = 4;
                          > > >
                          > > > (that removes the temptation to change PIE)

                          > Capitalized PIE will look like conventional macro and will stand out
                          > in the code, and you'll see your constants clearly. Decide for
                          > yourself if it is important or not.

                          > More importantly. If you maintain any code written by your Hungarian
                          > (or Ukrainian) co-workers, maintain whatever conventions they happened
                          > to be using. Even if it is Hungarian.

                          Can't be expressed better :)

                          for example, I do not use upper-case for consts. This does not mattter
                          much, since I believe that consitstency is above canon.


                          > --
                          > Oleg Goldshmidt <ogoldsh@...>
                          > "... We work but wit, and not by witchcraft;
                          > And wit depends on dilatory time." [Shakespeare]
                          >
                          > ------------------------------------------------------------------------
                          > Free Conference Calling with Firetalk!
                          > Click Here!
                          > http://click.egroups.com/1/5480/12/_/_/_/962906737/
                          > ------------------------------------------------------------------------
                          >
                          > To unsubscribe from this group, send an email to:
                          > hackers-il-unsubscribe@egroups.com

                          --
                          Omer Mussaev 051-308-214 mailto:omerm@...
                          systems programmer, Mercury Interactive/RND/Conduct/core
                        • Omer Mussaev
                          ... In addition to points you had cleared out, there are following important, IMHO, issues: being consistent in routine work, since you do overlook the routine
                          Message 12 of 25 , Jul 10 4:34 AM
                          • 0 Attachment
                            Chen Shapira wrote:

                            > > I don't think there is extra overhead to an inlined function call as
                            > > compared to a macro. They are basically the same. Of course, inlining
                            > > is no more than a hint to the compiler, not a directive, so you cannot
                            > > be 100% sure that your function will be inlined. On the other hand,
                            > > it might be a good idea to trust the compiler that it has a good
                            > > reason not to inline.
                            >
                            > Not knowing whether a function was inlined or not can be annoying while
                            > debugging. Especially on diffrent machines with diffrent compilers.
                            > One of the good reasons to uppercase #define is to know what to expect while
                            > debugging.
                            >
                            > and on the same point: "hard" optimizations of code, especially for modern
                            > processors (with pipelines) can cause some wierdities - like blocks of code
                            > disapearing, assigments ignored, and erasing a comment makes the code run
                            > faster...
                            >
                            > > If you are sure that none of the bad properties of C macros are
                            > > important, and the design arguments I listed are not important,
                            > > then there is no problem with macros. From your description, it looks
                            > > like you use them in your own code only, and not in an interface, so
                            > > the issues I listed are not relevant to you.
                            >
                            > So to some up:
                            > Use macros on Array sizes, and when efficiency is really on the line.
                            > Use inlined functions when efficiency is on the line, but consistancy and
                            > predictability isn't, and consider portability too.
                            > Remember that you are risking the debug
                            >
                            > anything I lost?

                            In addition to points you had cleared out, there are following important, IMHO,

                            issues:
                            being consistent in routine work, since you do overlook the routine pieces
                            while debugging
                            being consistent in debugging approach, since you can not learn from random
                            distribution

                            Thus, having a set of nice macros to do the job is good, as long as you are
                            familiar
                            with those macros, the code they evaluate to and the code that may come out of
                            optimizer.

                            On the other side, if you can tell when a function that is marked as inlined is
                            going
                            to be inlined indeed, you can surely benefit from the fact that funcion is a
                            nice thing
                            to debug.


                            > ------------------------------------------------------------------------
                            > CLICK HERE AND START SAVING ON LONG DISTANCE BILLS TODAY!
                            > http://click.egroups.com/1/6755/12/_/_/_/963230352/
                            > ------------------------------------------------------------------------
                            >
                            > To unsubscribe from this group, send an email to:
                            > hackers-il-unsubscribe@egroups.com

                            --
                            Omer Mussaev 051-308-214 mailto:omerm@...
                            systems programmer, Mercury Interactive/RND/Conduct/core
                          • Moshe Zadka
                            ... The solution is easy: never debug an optimized version of your program. If your program runs differently with optimizations, it s a bug in the optimize,
                            Message 13 of 25 , Jul 10 5:24 AM
                            • 0 Attachment
                              On Mon, 10 Jul 2000, Chen Shapira wrote:

                              > Not knowing whether a function was inlined or not can be annoying while
                              > debugging. Especially on diffrent machines with diffrent compilers.
                              > One of the good reasons to uppercase #define is to know what to expect while
                              > debugging.

                              The solution is easy: never debug an optimized version of your program. If
                              your program runs differently with optimizations, it's a bug in the
                              optimize, anyway. (well, with the exception of relying on undefined
                              behaviour, which is usually one of the easier bugs to fix)

                              > Use macros on Array sizes, and when efficiency is really on the line.
                              > Use inlined functions when efficiency is on the line, but consistancy and
                              > predictability isn't, and consider portability too.
                              > Remember that you are risking the debug

                              Debugging macros is usually harder, so I'm not really sure if it's clearly
                              a disadvantage to the debug to inline.
                              --
                              Moshe Zadka <moshez@...>
                              There is no GOD but Python, and HTTP is its prophet.
                              http://advogato.org/person/moshez
                            • Chen Shapira
                              ... Not knowing whether a function was inlined or not can be annoying while debugging. Especially on diffrent machines with diffrent compilers. One of the good
                              Message 14 of 25 , Jul 10 5:53 AM
                              • 0 Attachment
                                > I don't think there is extra overhead to an inlined function call as
                                > compared to a macro. They are basically the same. Of course, inlining
                                > is no more than a hint to the compiler, not a directive, so you cannot
                                > be 100% sure that your function will be inlined. On the other hand,
                                > it might be a good idea to trust the compiler that it has a good
                                > reason not to inline.

                                Not knowing whether a function was inlined or not can be annoying while
                                debugging. Especially on diffrent machines with diffrent compilers.
                                One of the good reasons to uppercase #define is to know what to expect while
                                debugging.

                                and on the same point: "hard" optimizations of code, especially for modern
                                processors (with pipelines) can cause some wierdities - like blocks of code
                                disapearing, assigments ignored, and erasing a comment makes the code run
                                faster...

                                > If you are sure that none of the bad properties of C macros are
                                > important, and the design arguments I listed are not important,
                                > then there is no problem with macros. From your description, it looks
                                > like you use them in your own code only, and not in an interface, so
                                > the issues I listed are not relevant to you.

                                So to some up:
                                Use macros on Array sizes, and when efficiency is really on the line.
                                Use inlined functions when efficiency is on the line, but consistancy and
                                predictability isn't, and consider portability too.
                                Remember that you are risking the debug

                                anything I lost?
                              • Oleg Goldshmidt
                                ... My first comment was: Use macros and inlining in the guts of your implementation, but not in the interface. -- Oleg Goldshmidt
                                Message 15 of 25 , Jul 10 10:11 AM
                                • 0 Attachment
                                  Chen Shapira <chen@...> writes:

                                  > So to some up:
                                  > Use macros on Array sizes, and when efficiency is really on the line.
                                  > Use inlined functions when efficiency is on the line, but consistancy and
                                  > predictability isn't, and consider portability too.
                                  > Remember that you are risking the debug
                                  >
                                  > anything I lost?

                                  My first comment was: Use macros and inlining in the guts of your
                                  implementation, but not in the interface.

                                  --
                                  Oleg Goldshmidt <ogoldsh@...>
                                  "... We work by wit, and not by witchcraft;
                                  And wit depends on dilatory time." [Shakespeare]
                                Your message has been successfully submitted and would be delivered to recipients shortly.