Efficiency

[js]

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 << "0123456789ABCD EF" [ Printit ] ;

or :

const char hexdigits [17] = "0123456789ABCD EF" ;

cout << hexdigits [ Printit ] ;


Or doesn't it matter ?

Thanks
Joe

[Ioannis Vranos]

Re: Efficiency

"js" <jb.simon@lmco. com> wrote in message
news:bf1rrm$m7n 1@cui1.lmms.lmc o.com...[color=blue]
> 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 << "0123456789ABCD EF" [ Printit ] ;
>
> or :
>
> const char hexdigits [17] = "0123456789ABCD EF" ;
>
> cout << hexdigits [ Printit ] ;[/color]


There is and a third method:


const char *hexdigits="012 3456789ABCDEF";

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

[John Harrison]

Re: Efficiency


"js" <jb.simon@lmco. com> wrote in message
news:bf1rrm$m7n 1@cui1.lmms.lmc o.com...[color=blue]
> 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 << "0123456789ABCD EF" [ Printit ] ;
>
> or :
>
> const char hexdigits [17] = "0123456789ABCD EF" ;
>
> cout << hexdigits [ Printit ] ;
>
>
> Or doesn't it matter ?[/color]

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.
[color=blue]
>
> Thanks
> Joe
>[/color]

john

[Gianni Mariani]

Re: Efficiency

js wrote:[color=blue]
> 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 << "0123456789ABCD EF" [ Printit ] ;
>
> or :
>
> const char hexdigits [17] = "0123456789ABCD EF" ;
>
> cout << hexdigits [ Printit ] ;
>
>
> Or doesn't it matter ?[/color]


These are exactly the same.

However, you could find out for yourself by testing each one.

[Michael Kochetkov]

Re: Efficiency


"js" <jb.simon@lmco. com> wrote in message
news:bf1rrm$m7n 1@cui1.lmms.lmc o.com...[color=blue]
> 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 << "0123456789ABCD EF" [ Printit ] ;
>
> or :
>
> const char hexdigits [17] = "0123456789ABCD EF" ;[/color]
A compiler is supposed to copy "0123456789ABCD EF" into hexdigits [17] here.
[color=blue]
>
> cout << hexdigits [ Printit ] ;[/color]
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).
[color=blue]
> Or doesn't it matter ?[/color]
You are to decide.

--
With regards,
Michael Kochetkov.

[Pete Becker]

Re: Efficiency

Michael Kochetkov wrote:[color=blue]
>[color=green]
> > const char hexdigits [17] = "0123456789ABCD EF" ;[/color]
> A compiler is supposed to copy "0123456789ABCD EF" into hexdigits [17] here.
>[/color]

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

[Michael Kochetkov]

Re: Efficiency


"Pete Becker" <petebecker@acm .org> wrote in message
news:3F154350.D BE527C2@acm.org ...[color=blue]
> Michael Kochetkov wrote:[color=green]
> >[color=darkred]
> > > const char hexdigits [17] = "0123456789ABCD EF" ;[/color]
> > A compiler is supposed to copy "0123456789ABCD EF" into hexdigits [17][/color][/color]
here.[color=blue][color=green]
> >[/color]
>
> 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.[/color]
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]

Re: Efficiency


"Michael Kochetkov" <Michael.Kochet kov@trustworks. commmm> wrote in message
news:3f15624c@n ews.telekom.ru. ..[color=blue]
>
> "Pete Becker" <petebecker@acm .org> wrote in message
> news:3F154350.D BE527C2@acm.org ...[color=green]
> > Michael Kochetkov wrote:[color=darkred]
> > >
> > > > const char hexdigits [17] = "0123456789ABCD EF" ;
> > > A compiler is supposed to copy "0123456789ABCD EF" into hexdigits [17][/color][/color]
> here.[color=green][color=darkred]
> > >[/color]
> >
> > 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.[/color]
> 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,[/color]
MS[color=blue]
> VC7.1, Borland 5.6, Intel C++ 7.1, DigitalMars 8.34, g++ 3.2 behave the[/color]
way[color=blue]
> I have described with maximum optimization been set.[/color]
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.

[Gianni Mariani]

Re: Efficiency

Michael Kochetkov wrote:

[discussion trimmed]
[color=blue]
>
> 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.
>[/color]


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

const char hexdigits [17] = "0123456789ABCD EF" ;

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.

[Michael Kochetkov]

Re: Efficiency


"Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
news:bf3ni7$35d @dispatch.conce ntric.net...[color=blue]
> Michael Kochetkov wrote:
>
> [discussion trimmed][/color]
It is a pity.
[color=blue]
>[color=green]
> >
> > So, I mean that in fact this is not usually done by direct[/color][/color]
initialization of[color=blue][color=green]
> > the array in the executable image at least in Win32 world.
> >[/color]
>
>
> void func2( int Printit )
> {
> cout << "0123456789ABCD EF" [ Printit ] ;
> }
>
> const char hexdigits [17] = "0123456789ABCD EF" ;
>
> void func2( int Printit )
> {
> cout << hexdigits [ Printit ] ;
> }
>
>
> What seems to be the problem ?[/color]
The key words were about hexdigits [xxx] on the stack.

--
With regards,
Michael Kochetkov.

[Thomas Matthews]

Re: Efficiency

Michael Kochetkov wrote:
[color=blue]
> "Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
> news:bf3ni7$35d @dispatch.conce ntric.net...
>[color=green]
>>Michael Kochetkov wrote:
>>
>>[discussion trimmed][/color]
>
> It is a pity.
>
>[color=green][color=darkred]
>>>So, I mean that in fact this is not usually done by direct[/color][/color]
>
> initialization of
>[color=green][color=darkred]
>>>the array in the executable image at least in Win32 world.
>>>[/color]
>>
>>
>>void func2( int Printit )
>>{
>>cout << "0123456789ABCD EF" [ Printit ] ;
>>}
>>
>>const char hexdigits [17] = "0123456789ABCD EF" ;
>>
>>void func2( int Printit )
>>{
>>cout << hexdigits [ Printit ] ;
>>}
>>
>>
>>What seems to be the problem ?[/color]
>
> The key words were about hexdigits [xxx] on the stack.
>
> --
> With regards,
> Michael Kochetkov.
>
>[/color]
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.l earn.c-c++ faq:

http://www.raos.demon.uk/acllc-c++/faq.html

Other sites:
http://www.josuttis.com -- C++ STL Library book

[Michael Kochetkov]

Re: Efficiency


"Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
news:bf3rgj$35c @dispatch.conce ntric.net...[color=blue]
> Michael Kochetkov wrote:
>[color=green][color=darkred]
> >>Michael Kochetkov wrote:
> >>
> >>[discussion trimmed][/color]
> >
> > It is a pity.[/color]
>
> think of all that bandwidth we saved ... :)
>[color=green][color=darkred]
> >>
> >>What seems to be the problem ?[/color]
> >
> > The key words were about hexdigits [xxx] on the stack.[/color]
>
> The OP was unspecific here but we should point it out that[/color]

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.
[color=blue]
>
>
> .... this option below:
>
> const char hexdigits [17] = "0123456789ABCD EF" ;
>
> void func2( int Printit )
> {
> cout << hexdigits [ Printit ] ;
> }
>
> is better than
>
>
> void func2( int Printit )
> {
> const char hexdigits [17] = "0123456789ABCD EF" ;
> cout << hexdigits [ Printit ] ;
> }[/color]
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 = "0123456789ABCD EF" ;
and
const char hexdigits [17] = "0123456789ABCD EF" ;
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]

Re: Efficiency


"Thomas Matthews" <Thomas_Matthew sHatesSpam@sbcg lobal.net> wrote in message
news:0meRa.1041 9$G16.300388464 6@newssvr10.new s.prodigy.com.. .[color=blue]
> Michael Kochetkov wrote:
>[color=green]
> > "Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
> > news:bf3ni7$35d @dispatch.conce ntric.net...
> >[color=darkred]
> >>Michael Kochetkov wrote:
> >>
> >>[discussion trimmed][/color]
> >
> > It is a pity.
> >
> >[color=darkred]
> >>>So, I mean that in fact this is not usually done by direct[/color]
> >
> > initialization of
> >[color=darkred]
> >>>the array in the executable image at least in Win32 world.
> >>>
> >>
> >>
> >>void func2( int Printit )
> >>{
> >>cout << "0123456789ABCD EF" [ Printit ] ;
> >>}
> >>
> >>const char hexdigits [17] = "0123456789ABCD EF" ;
> >>
> >>void func2( int Printit )
> >>{
> >>cout << hexdigits [ Printit ] ;
> >>}
> >>
> >>
> >>What seems to be the problem ?[/color]
> >
> > The key words were about hexdigits [xxx] on the stack.
> >
> > --
> > With regards,
> > Michael Kochetkov.
> >
> >[/color]
> 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.[/color]
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.

[Pete Becker]

Re: Efficiency

Michael Kochetkov wrote:[color=blue]
>
> "Pete Becker" <petebecker@acm .org> wrote in message
> news:3F154350.D BE527C2@acm.org ...[color=green]
> > Michael Kochetkov wrote:[color=darkred]
> > >
> > > > const char hexdigits [17] = "0123456789ABCD EF" ;
> > > A compiler is supposed to copy "0123456789ABCD EF" into hexdigits [17][/color][/color]
> here.[color=green][color=darkred]
> > >[/color]
> >
> > 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.[/color]
> I would agree with you, but I am not a compiler or library writer so I am
> not that self-confident ;).[/color]

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

[Gianni Mariani]

Re: Efficiency

Michael Kochetkov wrote:[color=blue]
> "Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
> news:bf3rgj$35c @dispatch.conce ntric.net...
>[color=green]
>>Michael Kochetkov wrote:
>>
>>[color=darkred]
>>>>Michael Kochetkov wrote:
>>>>
>>>>[discussion trimmed]
>>>
>>>It is a pity.[/color]
>>
>>think of all that bandwidth we saved ... :)
>>
>>[color=darkred]
>>>>What seems to be the problem ?
>>>
>>>The key words were about hexdigits [xxx] on the stack.[/color]
>>
>>The OP was unspecific here but we should point it out that[/color]
>
>
> 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.
>
>[color=green]
>>
>>.... this option below:
>>[/color][/color]

CODE-A
[color=blue][color=green]
>>const char hexdigits [17] = "0123456789ABCD EF" ;
>>
>>void func2( int Printit )
>>{
>> cout << hexdigits [ Printit ] ;
>>}
>>
>>is better than
>>
>>[/color][/color]

CODE-B
[color=blue][color=green]
>>void func2( int Printit )
>>{
>> const char hexdigits [17] = "0123456789ABCD EF" ;
>> cout << hexdigits [ Printit ] ;
>>}[/color]
>
> 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 = "0123456789ABCD EF" ;
> and
> const char hexdigits [17] = "0123456789ABCD EF" ;
> 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.[/color]

This is where I think you could be wrong.
[color=blue]
> 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.[/color]

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).