Efficiency

J

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

or :

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

cout << hexdigits [ Printit ] ;


Or doesn't it matter ?

Thanks
Joe
 
I

Ioannis Vranos

js said:
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
 
J

John Harrison

js said:
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
 
G

Gianni Mariani

js said:
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.
 
M

Michael Kochetkov

js said:
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.
 
P

Pete Becker

Michael said:
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
 
M

Michael Kochetkov

Pete Becker said:
Michael said:
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.
 
M

Michael Kochetkov

Michael Kochetkov said:
Pete Becker said:
Michael said:
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.
 
G

Gianni Mariani

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

Michael Kochetkov

Gianni Mariani said:
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.
 
T

Thomas Matthews

Michael said:
Michael Kochetkov wrote:

[discussion trimmed]

It is a pity.


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

Michael Kochetkov

Gianni Mariani said:
Michael said:
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.
 
M

Michael Kochetkov

Thomas Matthews said:
Michael said:
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.
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.
 
P

Pete Becker

Michael said:
Pete Becker said:
Michael said:
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
 
G

Gianni Mariani

Michael said:
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).
 
P

Pete Becker

Michael said:
Pete Becker said:
Michael said:
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
 
M

Michael Kochetkov

Gianni Mariani said:
Michael said:
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++.
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.
}
////////////////////////////////////////////////////////////////////////////
///////
 
P

Pete Becker

Michael said:
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
 
M

Michael Kochetkov

Pete Becker said:
Michael said:
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.
 
M

Michael Kochetkov

Pete Becker said:
Michael said:
Pete Becker said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top