"Impove your programs"

[28poGNh0]

hey everyone

I has these days a fever called "Improve your progams" .So many questions I have and I hope to get some answers .

I : If I have a for loop as this one :

for(unsigned int i=0;i<(strlen(szBuffer)+2);i++)
lets say that szBuffer's length = 10;

We all know the loop goes from 0 to 9,but my head says that everytime (strlen(szBuffer)+2) be calculated

is that right or (strlen(szBuffer)+2) be calculated once

thanks for reading

[S6k9GNh0]

Yeah, store the result of strlen and iterate using that. strlen, in most implementations, just iterate through the string until it hits a null character, then returns giving the the length of the string plus the null character. Also, strlen isn't guaranteed to work if there is no null-terminated character. Next.

[LB]

Most compilers will optimize it to only be evaluated once, though.

[28poGNh0]

II : which of those two expressions is better

int main()
{
    const char *szBuffer = "string";

    cout << "First expressions" << endl;
    for(int round = 1;round < 6;round++)
    {
        for(unsigned int i=0;i<strlen(szBuffer);i++)
            cout << szBuffer[i];
        cout << endl;
    }

    cout << endl << "Second expressions" << endl;

    unsigned int var = strlen(szBuffer);

    for(int round = 1;round < 6;round++)
    {
        for(unsigned int i=0;i<var;i++)
            cout << szBuffer[i];
        cout << endl;
    }

    return 0;
}

and thanks for the reply BTW

[Disch]

Most compilers will optimize it to only be evaluated once, though.

How can they? Unless it's marked as constexpr, how can they know the function call can be safely omitted? Is it because it's a std lib function?

EDIT: I guess if it's inlined....

[Duthomhas]

Most compilers will optimize it to only be evaluated once, though.

No they can't, it is an unsafe optimization because it could potentially change the behavior of the program. The only time it can be done is if the loop body makes no function calls and has no side effects modifying the string -- which is surprisingly difficult to prove.

Inlining is a different issue.

[LB]

I stand corrected - I was assuming strlen was inline.

[Cubbi]

@Techno01: Since you posted actual loops, let's look at actual compilers

I'll modify your test this way, so that we can examine what the functions compile to separately

#include <cstring>
#include <iostream>
using namespace std;
void f1()
{
    const char *szBuffer = "string";

    cout << "First expressions" << endl;
    for(int round = 1;round < 6;round++)
    {
        for(unsigned int i=0;i<strlen(szBuffer);i++)
            cout << szBuffer[i];
        cout << endl;
    }
}

void f2()
{
    const char *szBuffer = "string";

    cout << endl << "Second expressions" << endl;

    unsigned int var = strlen(szBuffer);

    for(int round = 1;round < 6;round++)
    {
        for(unsigned int i=0;i<var;i++)
            cout << szBuffer[i];
        cout << endl;
    }

}

int main()
{
        f1();
        f2();
}

Here's what the main loop of each function became:
gcc 4.7.2 on linux, optimized for size (-Os), because with -O3 it just unrolled both loops completely, and that's too much code to post

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

f1() .L3: movsbl (%rbx), %esi movl $cout, %edi incq %rbx call operator<<(std::ostream&, char) cmpq $.LC0+6, %rbx jne .L3 movl $cout, %edi call endl(ostream&) decl %ebp je .L1 .L2: movl $.LC0, %ebx jmp .L3 .L1:

f2() .L9: movsbl (%rbx), %esi movl $cout, %edi incq %rbx call operator<<(std::ostream&, char) cmpq $.LC0+6, %rbx jne .L9 movl $cout, %edi call endl(ostream&) decl %ebp je .L7 .L8: movl $.LC0, %ebx jmp .L9 .L7:

Intel 13.1, linux, regular -Ofast

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

f1() ..B2.4: xorl %ebp, %ebp ..B2.5: movl $cout, %edi movsbl .L_2__STRING.0(%rbp), %esi call operator<<(std::ostream&, char) ..B2.6: incl %ebp cmpq $6, %rbp jb ..B2.5 ..B2.7: movl $cout, %edi movl $endl(ostream&), %esi call operator<<(ostream& (*)(ostream&)) ..B2.8: incb %bl cmpb $6, %bl jl ..B2.4

f2() ..B3.5: movb $0, %bpl ..B3.6: movzbl %bpl, %edx movl $cout, %edi movsbl .L_2__STRING.0(%rdx), %esi call operator<<(std::ostream&, char) ..B3.7: incb %bpl cmpb $6, %bpl jb ..B3.6 ..B3.8: movl $cout, %edi movl $endl(ostream&), %esi call operator<<(ostream& (*)(ostream&)) ..B3.9: incb %bl cmpb $6, %bl jl ..B3.5

I could run it on another platform, for variety, but I don't expect any differences between these two loops. If you care about performance, start by getting rid of all these calls to std::endl

[keskiverto]

void f3()
{
    const char *szBuffer = "string";

    cout << endl << "Third expressions" << endl;
    for(int round = 1;round < 6;round++)
    {
        copy( szBuffer, szBuffer+strlen(szBuffer),
              ostream_iterator<const char>(cout) );
        cout << endl;
    }
}

I don't know how to dump instructions in same format as Cubbi, but f1, f2, and f3 do compile to rather similar nevertheless.

I recall attending "program refinement" course last millennium. Purely theoretical, mostly lambda-expressions and syntactic sugar.

[28poGNh0]

Thanks @cubbi and @keskiverto for the replies

@cubbi you're close to understand what I need to know

In my head I think that f2() is better that f1() function because in f1()

every round the second for loop must calculates strlen(szBuffer)

but in f2 is been already calculated and assingned to a local variable

am I right?

also is it better to do std::cout instead of using namespace std;

thanks for reading

[Cubbi]

In my head I think that f2() is better that f1() function because in f1()
every round the second for loop must calculates strlen(szBuffer)
but in f2 is been already calculated and assingned to a local variable
am I right?

It is exactly the same in this case on the platforms I tested, but you should be able to construct a test case in which it is exactly as you say. This test case is just too easy for the today's compilers to fully analyze.

Since I'm now at work, here's some non-intel goodness:
XL C++ 11.1, on AIX, with -Os (otherwise it unrolls everything like gcc)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

f1() __L58: addi r28,r0,0 addi r27,r31,-1 __L60: addi r0,r0,6 lbz r4,1(r27) addi r27,r27,1 lwz r3,T.238.std::cout(RTOC) ori r0,r0,0x0000 ori r0,r0,0x0000 bl .std::operator(std::ostream&,char) ori r0,r0,0x0000 addi r28,r28,1 addi r0,r0,6 cmpl 0,0,r28,r0 bc BO_IF,CR0_LT,__L60 lwz r3,T.238.std::cout(RTOC) lwz r0,0(r30) lwz r11,8(r30) mtspr CTR,r0 lwz RTOC,4(r30) bcctrl BO_ALWAYS,CR0_LT lwz RTOC,20(SP) addi r29,r29,1 cmpi 0,0,r29,6 bc BO_IF,CR0_LT,__L58

f2() __L1410: addi r28,r0,0 lwz r4,T.122.NO_SYMBOL(RTOC) addi r29,r4,-1 ori r0,r0,0x0000 __L1420: addi r0,r0,6 lbz r4,1(r29) addi r29,r29,1 lwz r3,T.238.std::cout(RTOC) ori r0,r0,0x0000 bl .std::operator(std::ostream&,char) ori r0,r0,0x0000 addi r28,r28,1 addi r0,r0,6 cmpl 0,0,r28,r0 bc BO_IF,CR0_LT,__L1420 lwz r3,T.238.cout(RTOC) lwz r0,0(r31) lwz r11,8(r31) mtspr CTR,r0 lwz RTOC,4(r31) bcctrl BO_ALWAYS,CR0_LT lwz RTOC,20(SP) addi r30,r30,1 cmpi 0,0,r30,6 bc BO_IF,CR0_LT,__L1410

(there's no explicit call to endl in the loop code because it sneakily loaded a pointer to it in r31 at the top of each function.. but like intel and gcc, it simply uses the constant 6 instead of strlen(szBuffer))

[3qX21hU5]

Just a question for the OP are you asking these questions from a C or C++ perspective? If its from a C++ perspective why not use strings? Just curious.

[MiiNiPaa]

I prefer to write something like:

const size_t bfSize(strlen(szBuffer));
for(size_t i= 0; i < bfSize; ++i) {
    /*...*/
}

This way:
1) Anybody reading your code knows that bfSize is constant and will not change during loop execution.
2) I will not break optimization and/or change program behavior by adding something like strncat(szBuffer, /*...*/) inside the loop. (However getting too worried about optimization in that case is probably example of premature optimization)