Efficiency

[Pete Becker]

Re: Efficiency

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

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]

Re: Efficiency


"Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
news:bf43tt$35m @dispatch.conce ntric.net...[color=blue]
> Michael Kochetkov wrote:[color=green]
> > "Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
> > news:bf3rgj$35c @dispatch.conce ntric.net...
> >[color=darkred]
> >>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[/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=darkred]
> >>
> >>.... this option below:
> >>[/color][/color]
>
> CODE-A
>[color=green][color=darkred]
> >>const char hexdigits [17] = "0123456789ABCD EF" ;
> >>
> >>void func2( int Printit )
> >>{
> >> cout << hexdigits [ Printit ] ;
> >>}
> >>
> >>is better than
> >>
> >>[/color][/color]
>
> CODE-B
>[color=green][color=darkred]
> >>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[/color][/color]
given a[color=blue][color=green]
> > useful hint about the code for the OP and those who given answers[/color][/color]
before.[color=blue][color=green]
> > 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[/color][/color]
that a[color=blue][color=green]
> > 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[/color][/color]
only[color=blue][color=green]
> > them. To my surprise all of them used copying.
> > Franckly speaking, I was reluctant to peep into the Standard but I think[/color][/color]
the[color=blue][color=green]
> > 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[/color][/color]
is[color=blue][color=green]
> > true then a compiler must use copying in the second example.[/color]
>
> This is where I think you could be wrong.[/color]
You may want to clarify it in comp.std.c++.
[color=blue]
>[color=green]
> > So, the recurrent hints are the possible const_cast and recursive[/color][/color]
functions.[color=blue][color=green]
> > And if I am right then your first example is not better or worse then[/color][/color]
the[color=blue][color=green]
> > 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).[/color]
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]

Re: Efficiency

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

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]

Re: Efficiency


"Pete Becker" <petebecker@acm .org> wrote in message
news:3F15A46C.7 7EFFBE6@acm.org ...[color=blue]
> Michael Kochetkov wrote:[color=green]
> >
> > void
> > f(bool b)
> > {
> > const char str[] = "aaaaaaaaa" ;[/color]
>
> Sheesh. You've been talking about a static LOCAL variable? No wonder.[/color]
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).
[color=blue]
> Yes, the variable must be initialized on the first call to the function.
> But that wasn't part of the original problem.[/color]
???
The original post was about the efficiency of the following:
//////////////////////////////////
cout << "0123456789ABCD EF" [ Printit ] ;

or :

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

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]

Re: Efficiency


"Pete Becker" <petebecker@acm .org> wrote in message
news:3F15AB13.2 D602457@acm.org ...[color=blue]
> Michael Kochetkov wrote:[color=green]
> >
> > "Pete Becker" <petebecker@acm .org> wrote in message
> > news:3F15A46C.7 7EFFBE6@acm.org ...[color=darkred]
> > > Michael Kochetkov wrote:
> > > >
> > > > void
> > > > f(bool b)
> > > > {
> > > > const char str[] = "aaaaaaaaa" ;
> > >
> > > Sheesh. You've been talking about a static LOCAL variable? No wonder.[/color]
> > No, not about static. Static is not interesting. Just about local. But[/color][/color]
you[color=blue][color=green]
> > might mean not static, but global (and it is does not matter indeed).[/color]
>
> Whoops, sorry. Local it is. And local vs. global does matter. Locals are
> initialized every time they are reached.[/color]
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 :).
[color=blue]
>[color=green]
> >[color=darkred]
> > > Yes, the variable must be initialized on the first call to the[/color][/color][/color]
function.[color=blue][color=green][color=darkred]
> > > But that wasn't part of the original problem.[/color]
> > ???
> > The original post was about the efficiency of the following:
> > //////////////////////////////////
> > cout << "0123456789ABCD EF" [ Printit ] ;
> >
> > or :
> >
> > const char hexdigits [17] = "0123456789ABCD EF" ;
> >
> > cout << hexdigits [ Printit ] ;
> > //////////////////////////////////
> >
> > hexdigits and call of << operator are in the same scope.[/color]
>
> 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.[/color]
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]

Re: Efficiency

<snip>
[color=blue]
> 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[/color]
may[color=blue]
> appear to be local.[/color]

<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]

Re: Efficiency



Michael Kochetkov wrote:[color=blue]
> "Joe Simon" <jb.simon@lmco. com> wrote in message
> news:bf6h20$m7n 3@cui1.lmms.lmc o.com...
>[color=green]
>><snip>
>>[color=darkred]
>>>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[/color]
>>
>>may
>>[color=darkred]
>>>appear to be local.[/color]
>>
>><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[/color]
>
> way,
>[color=green]
>>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,[/color]
>
> and
>[color=green]
>>then access it from within the member function.
>>
>>I was trying to keep it local because that is the only place it is used.[/color]
>
> In case the const char hexdigits [17] = "0123456789ABCD EF" ; declaration is
> global or local static then there is a chance it would be equivalent to just
> const char* str = "0123456789ABCD EF";. 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 << "0123456789ABCD EF";
> 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 = "0123456789ABCD EF";
> namespace {
> const char* str = "0123456789ABCD EF";
> }
> const char* str = "0123456789ABCD EF";
> 3. Declare local static pointer
> void f () {
> static const char* str = "0123456789ABCD EF";
> }
> 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 = "0123456789ABCD EF";
> }
>
> 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.
>
>[/color]
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[] = "0123456789ABCD EF"; /* static by default in C++ */

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

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

So these two program fragment should be the same efficient:

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

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

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

Re: Efficiency



Petr Maxa wrote:

[color=blue]
> /* 3rd version - less efficient */
> void f()
> {
> const char hexastring[] = "0123456789ABCD EF";
> 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.
>
>
>[/color]

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]

Re: Efficiency


"Petr Maxa" <Petr.Maxa@siem ens.com> wrote in message
news:1058531739 .455559@hermes. sbs.sk...[color=blue]
>
>
> Michael Kochetkov wrote:[color=green]
> > "Joe Simon" <jb.simon@lmco. com> wrote in message
> > news:bf6h20$m7n 3@cui1.lmms.lmc o.com...
> >[color=darkred]
> >><snip>
> >>
> >>>I am absolutely agree with you. And in general, or generally speaking[/color][/color][/color]
or[color=blue][color=green][color=darkred]
> >>>upon the whole the second variant is slower because in general[/color][/color][/color]
hexdigits[color=blue][color=green][color=darkred]
> >>
> >>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[/color][/color][/color]
that[color=blue][color=green][color=darkred]
> >>the storage is only allocated once.
> >>
> >>That is what I meant by efficient. Granted it doesn't take long either[/color]
> >
> > way,
> >[color=darkred]
> >>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,[/color]
> >
> > and
> >[color=darkred]
> >>then access it from within the member function.
> >>
> >>I was trying to keep it local because that is the only place it is used.[/color]
> >
> > In case the const char hexdigits [17] = "0123456789ABCD EF" ; declaration[/color][/color]
is[color=blue][color=green]
> > global or local static then there is a chance it would be equivalent to[/color][/color]
just[color=blue][color=green]
> > const char* str = "0123456789ABCD EF";. The key point is _const_ in const
> > char hexdigits []declaration. If it was char hexdigits [] a compiler[/color][/color]
would[color=blue][color=green]
> > have to copy the contents of literal string into hexdigits by all means
> > (whether hexdigits global, static or local). You shall realize that[/color][/color]
array[color=blue][color=green]
> > is a contaiter and you are usually supposed to change its contents[/color][/color]
whilest[color=blue][color=green]
> > leaving the original sample along. But the const makes it a little[/color][/color]
different[color=blue][color=green]
> > 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[/color][/color]
optimization[color=blue][color=green]
> > 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[/color][/color]
single[color=blue][color=green]
> > place it may appear to be the best choice)
> > cout << "0123456789ABCD EF";
> > 2. Declare global, global static (depricated, use unnamed namespace[/color][/color]
instead)[color=blue][color=green]
> > pointer. It may be enforced by some corporate standards of coding:
> > static const char* str = "0123456789ABCD EF";
> > namespace {
> > const char* str = "0123456789ABCD EF";
> > }
> > const char* str = "0123456789ABCD EF";
> > 3. Declare local static pointer
> > void f () {
> > static const char* str = "0123456789ABCD EF";
> > }
> > 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 = "0123456789ABCD EF";
> > }
> >
> > And I could hadly give a prove to using array of const chars in your[/color][/color]
case. A[color=blue][color=green]
> > professional programmer that may look at your code is used to think that
> > you, another professional programmer, would hardly complicate the code[/color][/color]
for[color=blue][color=green]
> > no particular reason. He would probably look for the perpose for such a
> > construction. And such unusual solutions makes the code harder to read[/color][/color]
and[color=blue][color=green]
> > understand. I wonder if this thread may serve as the illustration of[/color][/color]
what I[color=blue][color=green]
> > say. And, please, note, that all of this is just my opinion and it is[/color][/color]
not a[color=blue][color=green]
> > kind of obligatory rules.
> >
> > --
> > With regards,
> > Michael Kochetkov.
> >
> >[/color]
> 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[] = "0123456789ABCD EF"; /* static by default in C++[/color]
*/
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 = "0123456789ABCD EF";
then I am afraid you mix it up with
const char* const str = "0123456789ABCD EF";

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

--
With regards,
Michael Kochetkov.

[Petr Maxa]

Re: Efficiency



Michael Kochetkov wrote:
[color=blue][color=green]
>>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[] = "0123456789ABCD EF"; /* static by default in C++[/color]
>
> */
> 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.[/color]

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.