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

or :

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

cout << hexdigits [ Printit ] ;
Or doesn't it matter ?

Thanks
Joe

[Ioannis Vranos]

"js" <jb******@lmco.com> wrote in message
news:bf*********@cui1.lmms.lmco.com...

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

[John Harrison]

"js" <jb******@lmco.com> wrote in message
news:bf*********@cui1.lmms.lmco.com...

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

[Gianni Mariani]

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.

[Michael Kochetkov]

"js" <jb******@lmco.com> wrote in message
news:bf*********@cui1.lmms.lmco.com...

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.

[Pete Becker]

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

[Michael Kochetkov]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

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]

"Michael Kochetkov" <Mi***************@trustworks.commmm> wrote in message
news:3f******@news.telekom.ru...

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

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.

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

[Michael Kochetkov]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

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.

[Thomas Matthews]

Michael Kochetkov wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

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

[Michael Kochetkov]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

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]

"Thomas Matthews" <Th**********************@sbcglobal.net> wrote in message
news:0m************************@newssvr10.news.pro digy.com...

Michael Kochetkov wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

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.

[Pete Becker]

Michael Kochetkov wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

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

[Gianni Mariani]

Michael Kochetkov wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

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

[Pete Becker]

Michael Kochetkov wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Michael Kochetkov wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
> 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

[Michael Kochetkov]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

Michael Kochetkov wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bf********@dispatch.concentric.net...

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.

[Pete Becker]

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

[Michael Kochetkov]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

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]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Michael Kochetkov wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

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.

[Joe Simon]

<snip>

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.

<snip>

OK, it's me the OP.

That is excatly the question. What is the correct way to code this so that
the storage is only allocated once.

That is what I meant by efficient. Granted it doesn't take long either way,
even if as someone else pointed out it is only a few
nano seconds.
I do not like having things that should be constants allocated and/or
assigned over and over.

Sounds like the right way is to make the const array a class attribute, and
then access it from within the member function.

I was trying to keep it local because that is the only place it is used.

Thanks,
Joe
a few nanoseconds here and a few nanoseconds there and pretty soon you're
talking about Real Time.

[Petr Maxa]

Michael Kochetkov wrote:

"Joe Simon" <jb******@lmco.com> wrote in message
news:bf*********@cui1.lmms.lmco.com...

<snip>

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.

<snip>

OK, it's me the OP.

That is excatly the question. What is the correct way to code this so that
the storage is only allocated once.

That is what I meant by efficient. Granted it doesn't take long either

way,

even if as someone else pointed out it is only a few
nano seconds.
I do not like having things that should be constants allocated and/or
assigned over and over.

Sounds like the right way is to make the const array a class attribute,

and

then access it from within the member function.

I was trying to keep it local because that is the only place it is used.

In case the const char hexdigits [17] = "0123456789ABCDEF" ; declaration is
global or local static then there is a chance it would be equivalent to just
const char* str = "0123456789ABCDEF";. The key point is _const_ in const
char hexdigits []declaration. If it was char hexdigits [] a compiler would
have to copy the contents of literal string into hexdigits by all means
(whether hexdigits global, static or local). You shall realize that array
is a contaiter and you are usually supposed to change its contents whilest
leaving the original sample along. But the const makes it a little different
and a compiler may optimize the array initialization off for a global or
local static variable. In some cases I believe it may do it for local
(automatic) variable, but it may appear to be very unreliable optimization
and I doubt there is a compiler that does it.
IMO, in your case the most efficient ways would be:
1. Make use of the string literal directly (if you use it from the single
place it may appear to be the best choice)
cout << "0123456789ABCDEF";
2. Declare global, global static (depricated, use unnamed namespace instead)
pointer. It may be enforced by some corporate standards of coding:
static const char* str = "0123456789ABCDEF";
namespace {
const char* str = "0123456789ABCDEF";
}
const char* str = "0123456789ABCDEF";
3. Declare local static pointer
void f () {
static const char* str = "0123456789ABCDEF";
}
4. Declare local pointer (it shall be initialized each time the program
enters the f's scope, but a compiler could optimize it off easily)
void f () {
const char* str = "0123456789ABCDEF";
}

And I could hadly give a prove to using array of const chars in your case. A
professional programmer that may look at your code is used to think that
you, another professional programmer, would hardly complicate the code for
no particular reason. He would probably look for the perpose for such a
construction. And such unusual solutions makes the code harder to read and
understand. I wonder if this thread may serve as the illustration of what I
say. And, please, note, that all of this is just my opinion and it is not a
kind of obligatory rules.

--
With regards,
Michael Kochetkov.

I must disagree with You little bit. You must realize one feature of
C++'s global const objects - they are static by default, so when you
declare outside function:

const char hexastring[] = "0123456789ABCDEF"; /* static by default in C++ */

this is different, when You do the same inside a function:

void f()
{
const char hexastring[] = "0123456789ABCDEF"; /* not static !! */
}

So these two program fragment should be the same efficient:

/* 1st version - the most efficient */
const char hexastring[] = "0123456789ABCDEF"; /* static by default in C++ */
void f()
{
std::cout << hexastring;
}

/* 2nd version - also the most efficient */
void f()
{
std::cout << "0123456789ABCDEF";
}

But the following should be little bit slower, because, local const will
be copied inside the function each time it is run :

/* 3rd version - less efficient */
void f()
{
const char hexastring[] = "0123456789ABCDEF";
std::cout << hexastring;
}

Maybe with good optimization the 3rd version might be as effective as
the 1st and 2nd, moreover because the initializer of the hexastring is
constant.

Petr.

[Petr Maxa]

Petr Maxa wrote:

/* 3rd version - less efficient */
void f()
{
const char hexastring[] = "0123456789ABCDEF";
std::cout << hexastring;
}

Maybe with good optimization the 3rd version might be as effective as
the 1st and 2nd, moreover because the initializer of the hexastring is
constant.

Petr.

Now I know why the compiler in the 3rd version does copying each time
the function runs - according to the ARM, $2.5.4, page 11, strings
literals are of type char[] and not const char[] for compatibility with
classic C!!!

Petr

[Michael Kochetkov]

"Petr Maxa" <Pe*******@siemens.com> wrote in message
news:10***************@hermes.sbs.sk...

Michael Kochetkov wrote:

"Joe Simon" <jb******@lmco.com> wrote in message
news:bf*********@cui1.lmms.lmco.com...

<snip>

I am absolutely agree with you. And in general, or generally speaking orupon the whole the second variant is slower because in general hexdigits
may

appear to be local.

<snip>

OK, it's me the OP.

That is excatly the question. What is the correct way to code this so thatthe storage is only allocated once.

That is what I meant by efficient. Granted it doesn't take long either

way,

even if as someone else pointed out it is only a few
nano seconds.
I do not like having things that should be constants allocated and/or
assigned over and over.

Sounds like the right way is to make the const array a class attribute,

and

then access it from within the member function.

I was trying to keep it local because that is the only place it is used.

In case the const char hexdigits [17] = "0123456789ABCDEF" ; declaration is global or local static then there is a chance it would be equivalent to just const char* str = "0123456789ABCDEF";. The key point is _const_ in const
char hexdigits []declaration. If it was char hexdigits [] a compiler would have to copy the contents of literal string into hexdigits by all means
(whether hexdigits global, static or local). You shall realize that array is a contaiter and you are usually supposed to change its contents whilest leaving the original sample along. But the const makes it a little different and a compiler may optimize the array initialization off for a global or
local static variable. In some cases I believe it may do it for local
(automatic) variable, but it may appear to be very unreliable optimization and I doubt there is a compiler that does it.
IMO, in your case the most efficient ways would be:
1. Make use of the string literal directly (if you use it from the single place it may appear to be the best choice)
cout << "0123456789ABCDEF";
2. Declare global, global static (depricated, use unnamed namespace instead) pointer. It may be enforced by some corporate standards of coding:
static const char* str = "0123456789ABCDEF";
namespace {
const char* str = "0123456789ABCDEF";
}
const char* str = "0123456789ABCDEF";
3. Declare local static pointer
void f () {
static const char* str = "0123456789ABCDEF";
}
4. Declare local pointer (it shall be initialized each time the program
enters the f's scope, but a compiler could optimize it off easily)
void f () {
const char* str = "0123456789ABCDEF";
}

And I could hadly give a prove to using array of const chars in your case. A professional programmer that may look at your code is used to think that
you, another professional programmer, would hardly complicate the code for no particular reason. He would probably look for the perpose for such a
construction. And such unusual solutions makes the code harder to read and understand. I wonder if this thread may serve as the illustration of what I say. And, please, note, that all of this is just my opinion and it is not a kind of obligatory rules.

--
With regards,
Michael Kochetkov.

I must disagree with You little bit. You must realize one feature of
C++'s global const objects - they are static by default, so when you
declare outside function:

const char hexastring[] = "0123456789ABCDEF"; /* static by default in C++

*/
Nonsense. Provided your hexastring is declared in the global scope then it
has external linkage. If it was static as you say it would have internal
linkage.
And more over I have not considered const char hexastring[] in my last post
at all.
As for global declaration
const char* str = "0123456789ABCDEF";
then I am afraid you mix it up with
const char* const str = "0123456789ABCDEF";

Please, make sure you understand the difference between a pointer to const
and const pointer.

--
With regards,
Michael Kochetkov.

[Petr Maxa]

Michael Kochetkov wrote:

I must disagree with You little bit. You must realize one feature of
C++'s global const objects - they are static by default, so when you
declare outside function:

const char hexastring[] = "0123456789ABCDEF"; /* static by default in C++

*/
Nonsense. Provided your hexastring is declared in the global scope then it
has external linkage. If it was static as you say it would have internal
linkage.

I must insist on my word, global const object have internal linkage.
From ARM, $7.1.6, p. 110:

"In C++, the default linkage of a const object is internal. In ANSI C,
default storage class of a const object is extern. Naturally, explicitly
declaring a const object extern will provide behavior equivalent to ANSI
C, as the following:

extern const MIN = -1;

......"

You can find the same in TC++L from Stroustrup.

Petr.