Efficiency

Discussion in 'C++' started by js, Jul 15, 2003.

  1. js

    js Guest

    for a hex conversion, Is it more efficient to do this :

    Printit is the char whose low order bits represent the nibble to print

    cout << "0123456789ABCDEF" [ Printit ] ;

    or :

    const char hexdigits [17] = "0123456789ABCDEF" ;

    cout << hexdigits [ Printit ] ;


    Or doesn't it matter ?

    Thanks
    Joe
     
    js, Jul 15, 2003
    #1
    1. Advertising

  2. "js" <> wrote in message
    news:bf1rrm$...
    > for a hex conversion, Is it more efficient to do this :
    >
    > Printit is the char whose low order bits represent the nibble to print
    >
    > cout << "0123456789ABCDEF" [ Printit ] ;
    >
    > or :
    >
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    >
    > cout << hexdigits [ Printit ] ;



    There is and a third method:


    const char *hexdigits="0123456789ABCDEF";

    cout << hexdigits [Printit];



    It doesn't really matter. Use the one that is more convenient to you.







    --
    Ioannis

    * Programming pages: http://www.noicys.freeurl.com
    * Alternative URL 1: http://run.to/noicys
    * Alternative URL 2: http://www.noicys.cjb.net
     
    Ioannis Vranos, Jul 15, 2003
    #2
    1. Advertising

  3. "js" <> wrote in message
    news:bf1rrm$...
    > for a hex conversion, Is it more efficient to do this :
    >
    > Printit is the char whose low order bits represent the nibble to print
    >
    > cout << "0123456789ABCDEF" [ Printit ] ;
    >
    > or :
    >
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    >
    > cout << hexdigits [ Printit ] ;
    >
    >
    > Or doesn't it matter ?


    You got it. If there is any difference it will be measureable in nano
    seconds. Excessively concern for 'efficiency' at the cost of considering
    more important factors, such as clean design and legible code, is a typical
    newbie trait.

    >
    > Thanks
    > Joe
    >


    john
     
    John Harrison, Jul 16, 2003
    #3
  4. js wrote:
    > for a hex conversion, Is it more efficient to do this :
    >
    > Printit is the char whose low order bits represent the nibble to print
    >
    > cout << "0123456789ABCDEF" [ Printit ] ;
    >
    > or :
    >
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    >
    > cout << hexdigits [ Printit ] ;
    >
    >
    > Or doesn't it matter ?



    These are exactly the same.

    However, you could find out for yourself by testing each one.
     
    Gianni Mariani, Jul 16, 2003
    #4
  5. "js" <> wrote in message
    news:bf1rrm$...
    > for a hex conversion, Is it more efficient to do this :
    >
    > Printit is the char whose low order bits represent the nibble to print
    >
    > cout << "0123456789ABCDEF" [ Printit ] ;
    >
    > or :
    >
    > const char hexdigits [17] = "0123456789ABCDEF" ;

    A compiler is supposed to copy "0123456789ABCDEF" into hexdigits [17] here.

    >
    > cout << hexdigits [ Printit ] ;

    So the first variant is faster. Though such a short string may be copied
    with no loops, using memory/register operations only but the long text may
    consume considerable time and stack memory. I believe the last may appear to
    be more important because it may lead to the runtime crash (at least on
    Win32 architectures).

    > Or doesn't it matter ?

    You are to decide.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #5
  6. js

    Pete Becker Guest

    Michael Kochetkov wrote:
    >
    > > const char hexdigits [17] = "0123456789ABCDEF" ;

    > A compiler is supposed to copy "0123456789ABCDEF" into hexdigits [17] here.
    >


    There's no such requirement. In fact this is usually done by direct
    intialization of the array in the executable image, i.e. with no runtime
    overhead at all.

    --

    "To delight in war is a merit in the soldier,
    a dangerous quality in the captain, and a
    positive crime in the statesman."
    George Santayana

    "Bring them on."
    George W. Bush
     
    Pete Becker, Jul 16, 2003
    #6
  7. "Pete Becker" <> wrote in message
    news:...
    > Michael Kochetkov wrote:
    > >
    > > > const char hexdigits [17] = "0123456789ABCDEF" ;

    > > A compiler is supposed to copy "0123456789ABCDEF" into hexdigits [17]

    here.
    > >

    >
    > There's no such requirement. In fact this is usually done by direct
    > intialization of the array in the executable image, i.e. with no runtime
    > overhead at all.

    I would agree with you, but I am not a compiler or library writer so I am
    not that self-confident ;). I have carefully checked it out before posting
    and have found that at least the following compilers: MS VC6.0, MS VC7.0, MS
    VC7.1, Borland 5.6, Intel C++ 7.1, DigitalMars 8.34, g++ 3.2 behave the way
    I have described with maximum optimization been set.
    And no doubt you are aware of the fact that the special bobs are needed to
    obtain more then 4K on the stack in Win32 world.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #7
  8. "Michael Kochetkov" <> wrote in message
    news:...
    >
    > "Pete Becker" <> wrote in message
    > news:...
    > > Michael Kochetkov wrote:
    > > >
    > > > > const char hexdigits [17] = "0123456789ABCDEF" ;
    > > > A compiler is supposed to copy "0123456789ABCDEF" into hexdigits [17]

    > here.
    > > >

    > >
    > > There's no such requirement. In fact this is usually done by direct
    > > intialization of the array in the executable image, i.e. with no runtime
    > > overhead at all.

    > I would agree with you, but I am not a compiler or library writer so I am
    > not that self-confident ;). I have carefully checked it out before posting
    > and have found that at least the following compilers: MS VC6.0, MS VC7.0,

    MS
    > VC7.1, Borland 5.6, Intel C++ 7.1, DigitalMars 8.34, g++ 3.2 behave the

    way
    > I have described with maximum optimization been set.

    So, I mean that in fact this is not usually done by direct initialization of
    the array in the executable image at least in Win32 world.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #8
  9. Michael Kochetkov wrote:

    [discussion trimmed]

    >
    > So, I mean that in fact this is not usually done by direct initialization of
    > the array in the executable image at least in Win32 world.
    >



    void func2( int Printit )
    {
    cout << "0123456789ABCDEF" [ Printit ] ;
    }

    const char hexdigits [17] = "0123456789ABCDEF" ;

    void func2( int Printit )
    {
    cout << hexdigits [ Printit ] ;
    }


    What seems to be the problem ?

    These are exactly the same in terms of performance on virtually any
    platform.
     
    Gianni Mariani, Jul 16, 2003
    #9
  10. "Gianni Mariani" <> wrote in message
    news:bf3ni7$...
    > Michael Kochetkov wrote:
    >
    > [discussion trimmed]

    It is a pity.

    >
    > >
    > > So, I mean that in fact this is not usually done by direct

    initialization of
    > > the array in the executable image at least in Win32 world.
    > >

    >
    >
    > void func2( int Printit )
    > {
    > cout << "0123456789ABCDEF" [ Printit ] ;
    > }
    >
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    >
    > void func2( int Printit )
    > {
    > cout << hexdigits [ Printit ] ;
    > }
    >
    >
    > What seems to be the problem ?

    The key words were about hexdigits [xxx] on the stack.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #10
  11. Michael Kochetkov wrote:

    > "Gianni Mariani" <> wrote in message
    > news:bf3ni7$...
    >
    >>Michael Kochetkov wrote:
    >>
    >>[discussion trimmed]

    >
    > It is a pity.
    >
    >
    >>>So, I mean that in fact this is not usually done by direct

    >
    > initialization of
    >
    >>>the array in the executable image at least in Win32 world.
    >>>

    >>
    >>
    >>void func2( int Printit )
    >>{
    >>cout << "0123456789ABCDEF" [ Printit ] ;
    >>}
    >>
    >>const char hexdigits [17] = "0123456789ABCDEF" ;
    >>
    >>void func2( int Printit )
    >>{
    >>cout << hexdigits [ Printit ] ;
    >>}
    >>
    >>
    >>What seems to be the problem ?

    >
    > The key words were about hexdigits [xxx] on the stack.
    >
    > --
    > With regards,
    > Michael Kochetkov.
    >
    >

    Since the array is const, it doesn't have to be on the stack.
    It can be placed into the executable code segment as data.
    Many compilers have a separate segment for constant data.
    Some compilers will place the constant data in a separate
    location in the executable; while others will interleave it.

    --
    Thomas Matthews

    C++ newsgroup welcome message:
    http://www.slack.net/~shiva/welcome.txt
    C++ Faq: http://www.parashift.com/c -faq-lite
    C Faq: http://www.eskimo.com/~scs/c-faq/top.html
    alt.comp.lang.learn.c-c++ faq:
    http://www.raos.demon.uk/acllc-c /faq.html
    Other sites:
    http://www.josuttis.com -- C++ STL Library book
     
    Thomas Matthews, Jul 16, 2003
    #11
  12. "Gianni Mariani" <> wrote in message
    news:bf3rgj$...
    > Michael Kochetkov wrote:
    >
    > >>Michael Kochetkov wrote:
    > >>
    > >>[discussion trimmed]

    > >
    > > It is a pity.

    >
    > think of all that bandwidth we saved ... :)
    >
    > >>
    > >>What seems to be the problem ?

    > >
    > > The key words were about hexdigits [xxx] on the stack.

    >
    > The OP was unspecific here but we should point it out that


    But he was. hexdigits declaration and << operator call were in the same
    scope, at least I read it like that. Such a situation is ill-formed in a
    global scope.

    >
    >
    > .... this option below:
    >
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    >
    > void func2( int Printit )
    > {
    > cout << hexdigits [ Printit ] ;
    > }
    >
    > is better than
    >
    >
    > void func2( int Printit )
    > {
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    > cout << hexdigits [ Printit ] ;
    > }

    Well, I have not expected to start a discussion indeed. I have just given a
    useful hint about the code for the OP and those who given answers before.
    May be I shall rely on hints less.
    So, here goes some elaborations. const char hexdigits [17] and char
    hexdigits [17] are quite different indeed and I was of Pete's opinion that a
    smart compiler may omit copying. But as I have mentioned above I was not
    sure and decided to check it with industry standard compilers and not only
    them. To my surprise all of them used copying.
    Franckly speaking, I was reluctant to peep into the Standard but I think the
    following:
    const char * cp = "0123456789ABCDEF" ;
    and
    const char hexdigits [17] = "0123456789ABCDEF" ;
    are different things. And I believe, that later allows const_cast. If it is
    true then a compiler must use copying in the second example.
    So, the recurrent hints are the possible const_cast and recursive functions.
    And if I am right then your first example is not better or worse then the
    second one -- it is different.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #12
  13. "Thomas Matthews" <> wrote in message
    news:0meRa.10419$...
    > Michael Kochetkov wrote:
    >
    > > "Gianni Mariani" <> wrote in message
    > > news:bf3ni7$...
    > >
    > >>Michael Kochetkov wrote:
    > >>
    > >>[discussion trimmed]

    > >
    > > It is a pity.
    > >
    > >
    > >>>So, I mean that in fact this is not usually done by direct

    > >
    > > initialization of
    > >
    > >>>the array in the executable image at least in Win32 world.
    > >>>
    > >>
    > >>
    > >>void func2( int Printit )
    > >>{
    > >>cout << "0123456789ABCDEF" [ Printit ] ;
    > >>}
    > >>
    > >>const char hexdigits [17] = "0123456789ABCDEF" ;
    > >>
    > >>void func2( int Printit )
    > >>{
    > >>cout << hexdigits [ Printit ] ;
    > >>}
    > >>
    > >>
    > >>What seems to be the problem ?

    > >
    > > The key words were about hexdigits [xxx] on the stack.
    > >
    > > --
    > > With regards,
    > > Michael Kochetkov.
    > >
    > >

    > Since the array is const, it doesn't have to be on the stack.
    > It can be placed into the executable code segment as data.
    > Many compilers have a separate segment for constant data.
    > Some compilers will place the constant data in a separate
    > location in the executable; while others will interleave it.

    And what do you think about cons_cast and recursive functions? I believe the
    literal string and const char s[xxx] are different things and the later
    admits const_cast. IMO a programmer my expect a compiler to copy literal on
    the stack in the case we are talking about.

    If you believe const_cast is impossible then again, I emphasized in my reply
    to Pete that it is not usual thing for the modern compilers to initialize
    arrays like he supposes. And personally I really think that such an
    initialization would be broken.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #13
  14. js

    Pete Becker Guest

    Michael Kochetkov wrote:
    >
    > "Pete Becker" <> wrote in message
    > news:...
    > > Michael Kochetkov wrote:
    > > >
    > > > > const char hexdigits [17] = "0123456789ABCDEF" ;
    > > > A compiler is supposed to copy "0123456789ABCDEF" into hexdigits [17]

    > here.
    > > >

    > >
    > > There's no such requirement. In fact this is usually done by direct
    > > intialization of the array in the executable image, i.e. with no runtime
    > > overhead at all.

    > I would agree with you, but I am not a compiler or library writer so I am
    > not that self-confident ;).


    Please be more careful to distinguish between what the language requires
    ("a compiler is supposed to ...") and what various compilers do. My main
    point was that there is NO SUCH REQUIREMENT.

    --

    "To delight in war is a merit in the soldier,
    a dangerous quality in the captain, and a
    positive crime in the statesman."
    George Santayana

    "Bring them on."
    George W. Bush
     
    Pete Becker, Jul 16, 2003
    #14
  15. Michael Kochetkov wrote:
    > "Gianni Mariani" <> wrote in message
    > news:bf3rgj$...
    >
    >>Michael Kochetkov wrote:
    >>
    >>
    >>>>Michael Kochetkov wrote:
    >>>>
    >>>>[discussion trimmed]
    >>>
    >>>It is a pity.

    >>
    >>think of all that bandwidth we saved ... :)
    >>
    >>
    >>>>What seems to be the problem ?
    >>>
    >>>The key words were about hexdigits [xxx] on the stack.

    >>
    >>The OP was unspecific here but we should point it out that

    >
    >
    > But he was. hexdigits declaration and << operator call were in the same
    > scope, at least I read it like that. Such a situation is ill-formed in a
    > global scope.
    >
    >
    >>
    >>.... this option below:
    >>


    CODE-A

    >>const char hexdigits [17] = "0123456789ABCDEF" ;
    >>
    >>void func2( int Printit )
    >>{
    >> cout << hexdigits [ Printit ] ;
    >>}
    >>
    >>is better than
    >>
    >>


    CODE-B

    >>void func2( int Printit )
    >>{
    >> const char hexdigits [17] = "0123456789ABCDEF" ;
    >> cout << hexdigits [ Printit ] ;
    >>}

    >
    > Well, I have not expected to start a discussion indeed. I have just given a
    > useful hint about the code for the OP and those who given answers before.
    > May be I shall rely on hints less.
    > So, here goes some elaborations. const char hexdigits [17] and char
    > hexdigits [17] are quite different indeed and I was of Pete's opinion that a
    > smart compiler may omit copying. But as I have mentioned above I was not
    > sure and decided to check it with industry standard compilers and not only
    > them. To my surprise all of them used copying.
    > Franckly speaking, I was reluctant to peep into the Standard but I think the
    > following:
    > const char * cp = "0123456789ABCDEF" ;
    > and
    > const char hexdigits [17] = "0123456789ABCDEF" ;
    > are different things. And I believe, that later allows const_cast. If it is
    > true then a compiler must use copying in the second example.


    This is where I think you could be wrong.

    > So, the recurrent hints are the possible const_cast and recursive functions.
    > And if I am right then your first example is not better or worse then the
    > second one -- it is different.


    But is it not true that poorer but conforming compiler could do
    initialization at run-time in CODE-B while it would/could not in CODE-A?

    Hence would it not be better to write CODE-A (we could argue about
    namespaces but I'm sure we can figure that out).
     
    Gianni Mariani, Jul 16, 2003
    #15
  16. js

    Pete Becker Guest

    Michael Kochetkov wrote:
    >
    > "Pete Becker" <> wrote in message
    > news:...
    > > Michael Kochetkov wrote:
    > > >
    > > > "Pete Becker" <> wrote in message
    > > > news:...
    > > > > Michael Kochetkov wrote:
    > > > > >
    > > > > > > const char hexdigits [17] = "0123456789ABCDEF" ;
    > > > > > A compiler is supposed to copy "0123456789ABCDEF" into hexdigits

    > [17]
    > > > here.
    > > > > >
    > > > >
    > > > > There's no such requirement. In fact this is usually done by direct
    > > > > intialization of the array in the executable image, i.e. with no

    > runtime
    > > > > overhead at all.
    > > > I would agree with you, but I am not a compiler or library writer so I

    > am
    > > > not that self-confident ;).

    > >
    > > Please be more careful to distinguish between what the language requires
    > > ("a compiler is supposed to ...") and what various compilers do. My main

    > Do not you think your supposed implementation would be broken in case of
    > const_cast and recursive functions? I believe the
    > literal string and const char s[xxx] are different things and the later
    > admits const_cast..


    Of course they're different things. But both are const, and if you cast
    away const the behavior of your program is undefined. There is no
    conforming program that you can write that can detect whether there the
    contents of the string are copied into the array during startup, so
    there is no requirement that such a copy take place.

    --

    "To delight in war is a merit in the soldier,
    a dangerous quality in the captain, and a
    positive crime in the statesman."
    George Santayana

    "Bring them on."
    George W. Bush
     
    Pete Becker, Jul 16, 2003
    #16
  17. "Gianni Mariani" <> wrote in message
    news:bf43tt$...
    > Michael Kochetkov wrote:
    > > "Gianni Mariani" <> wrote in message
    > > news:bf3rgj$...
    > >
    > >>Michael Kochetkov wrote:
    > >>
    > >>
    > >>>>Michael Kochetkov wrote:
    > >>>>
    > >>>>[discussion trimmed]
    > >>>
    > >>>It is a pity.
    > >>
    > >>think of all that bandwidth we saved ... :)
    > >>
    > >>
    > >>>>What seems to be the problem ?
    > >>>
    > >>>The key words were about hexdigits [xxx] on the stack.
    > >>
    > >>The OP was unspecific here but we should point it out that

    > >
    > >
    > > But he was. hexdigits declaration and << operator call were in the same
    > > scope, at least I read it like that. Such a situation is ill-formed in a
    > > global scope.
    > >
    > >
    > >>
    > >>.... this option below:
    > >>

    >
    > CODE-A
    >
    > >>const char hexdigits [17] = "0123456789ABCDEF" ;
    > >>
    > >>void func2( int Printit )
    > >>{
    > >> cout << hexdigits [ Printit ] ;
    > >>}
    > >>
    > >>is better than
    > >>
    > >>

    >
    > CODE-B
    >
    > >>void func2( int Printit )
    > >>{
    > >> const char hexdigits [17] = "0123456789ABCDEF" ;
    > >> cout << hexdigits [ Printit ] ;
    > >>}

    > >
    > > Well, I have not expected to start a discussion indeed. I have just

    given a
    > > useful hint about the code for the OP and those who given answers

    before.
    > > May be I shall rely on hints less.
    > > So, here goes some elaborations. const char hexdigits [17] and char
    > > hexdigits [17] are quite different indeed and I was of Pete's opinion

    that a
    > > smart compiler may omit copying. But as I have mentioned above I was not
    > > sure and decided to check it with industry standard compilers and not

    only
    > > them. To my surprise all of them used copying.
    > > Franckly speaking, I was reluctant to peep into the Standard but I think

    the
    > > following:
    > > const char * cp = "0123456789ABCDEF" ;
    > > and
    > > const char hexdigits [17] = "0123456789ABCDEF" ;
    > > are different things. And I believe, that later allows const_cast. If it

    is
    > > true then a compiler must use copying in the second example.

    >
    > This is where I think you could be wrong.

    You may want to clarify it in comp.std.c++.

    >
    > > So, the recurrent hints are the possible const_cast and recursive

    functions.
    > > And if I am right then your first example is not better or worse then

    the
    > > second one -- it is different.

    >
    > But is it not true that poorer but conforming compiler could do
    > initialization at run-time in CODE-B while it would/could not in CODE-A?
    >
    > Hence would it not be better to write CODE-A (we could argue about
    > namespaces but I'm sure we can figure that out).

    It looks like it is not good day for me to speak English :). That is what I
    mean. (I have just read Pete Becker's post -- he believes the program is
    undefined. I see it now -- 7.1.5.1/4. It looks like compiler vendors try to
    make it more or less defined -- at least I do not know a compiler that is
    aggressive enough to avoid copying).
    ////////////////////////////////////////////////////////////////////////////
    ///////
    // I am reluctant to tune DMC to understand C++ streams
    #include <stdio.h>

    void
    f(bool b)
    {
    const char str[] = "aaaaaaaaa";
    if(b) {
    const_cast<char&>(str[0]) = 'b';
    }
    puts(str);
    if(b) {
    f(false);
    }
    }

    int
    main()
    {
    f(true);
    return 0; // Watcom believes this is the must.
    }
    ////////////////////////////////////////////////////////////////////////////
    ///////

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #17
  18. js

    Pete Becker Guest

    Michael Kochetkov wrote:
    >
    > void
    > f(bool b)
    > {
    > const char str[] = "aaaaaaaaa";


    Sheesh. You've been talking about a static LOCAL variable? No wonder.
    Yes, the variable must be initialized on the first call to the function.
    But that wasn't part of the original problem.

    --

    "To delight in war is a merit in the soldier,
    a dangerous quality in the captain, and a
    positive crime in the statesman."
    George Santayana

    "Bring them on."
    George W. Bush
     
    Pete Becker, Jul 16, 2003
    #18
  19. "Pete Becker" <> wrote in message
    news:...
    > Michael Kochetkov wrote:
    > >
    > > void
    > > f(bool b)
    > > {
    > > const char str[] = "aaaaaaaaa";

    >
    > Sheesh. You've been talking about a static LOCAL variable? No wonder.

    No, not about static. Static is not interesting. Just about local. But you
    might mean not static, but global (and it is does not matter indeed).

    > Yes, the variable must be initialized on the first call to the function.
    > But that wasn't part of the original problem.

    ???
    The original post was about the efficiency of the following:
    //////////////////////////////////
    cout << "0123456789ABCDEF" [ Printit ] ;

    or :

    const char hexdigits [17] = "0123456789ABCDEF" ;

    cout << hexdigits [ Printit ] ;
    //////////////////////////////////

    hexdigits and call of << operator are in the same scope. Frankly speaking, I
    have not even thought about global/static. I have just pointed out that
    there is a difference that was overlooked by previous authors. So, I believe
    I was talking about the original problem from the very begining.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #19
  20. "Pete Becker" <> wrote in message
    news:...
    > Michael Kochetkov wrote:
    > >
    > > "Pete Becker" <> wrote in message
    > > news:...
    > > > Michael Kochetkov wrote:
    > > > >
    > > > > void
    > > > > f(bool b)
    > > > > {
    > > > > const char str[] = "aaaaaaaaa";
    > > >
    > > > Sheesh. You've been talking about a static LOCAL variable? No wonder.

    > > No, not about static. Static is not interesting. Just about local. But

    you
    > > might mean not static, but global (and it is does not matter indeed).

    >
    > Whoops, sorry. Local it is. And local vs. global does matter. Locals are
    > initialized every time they are reached.

    There is static or global that does not matter in the sentence "But you
    might mean not static, but global (and it is does not matter indeed)." in my
    English :).

    >
    > >
    > > > Yes, the variable must be initialized on the first call to the

    function.
    > > > But that wasn't part of the original problem.

    > > ???
    > > The original post was about the efficiency of the following:
    > > //////////////////////////////////
    > > cout << "0123456789ABCDEF" [ Printit ] ;
    > >
    > > or :
    > >
    > > const char hexdigits [17] = "0123456789ABCDEF" ;
    > >
    > > cout << hexdigits [ Printit ] ;
    > > //////////////////////////////////
    > >
    > > hexdigits and call of << operator are in the same scope.

    >
    > No, there are no scopes here. This is a code fragment. So if you say
    > something about the code without describing limitations you're talking
    > IN GENERAL.

    I am absolutely agree with you. And in general, or generally speaking or
    upon the whole the second variant is slower because in general hexdigits may
    appear to be local.
    Eh,.. different mentality, I suppose, multiplied by my English.

    BTW, thank you for reminding about undefined behavior. I was looking for
    "const_cast" with CTRL-F and have found 5.2.2/5. I was in a hurry and have
    not noticed it was about functions parameters.

    --
    With regards,
    Michael Kochetkov.
     
    Michael Kochetkov, Jul 16, 2003
    #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. Bryan Krone

    perl efficiency -- fastest grepping?

    Bryan Krone, Nov 5, 2004, in forum: Perl
    Replies:
    1
    Views:
    1,487
    Jim Gibson
    Nov 8, 2004
  2. Trevor Hartman

    dataset efficiency question

    Trevor Hartman, Jul 3, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    403
    Trevor Hartman
    Jul 3, 2003
  3. Joseph D. DeJohn

    Custom Paging Efficiency

    Joseph D. DeJohn, Aug 6, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    361
    S. Justin Gengo
    Aug 6, 2003
  4. MC D
    Replies:
    4
    Views:
    473
    Big D
    Nov 18, 2003
  5. =?Utf-8?B?R2VvcmdlIER1cnpp?=

    Regex Efficiency Q - Manipulating Html

    =?Utf-8?B?R2VvcmdlIER1cnpp?=, Feb 28, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    309
    =?Utf-8?B?R2VvcmdlIER1cnpp?=
    Feb 28, 2004
Loading...

Share This Page