dev-cpp-users — Dev-C++ users discussion list

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Ioannis Vranos
> Sent: Saturday, May 31, 2003 3:22 AM
> To: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> I just checked it and it seems you are right. Don't know why yet.
> 
> 
> However does the above style make the compiler to give it an 
> address? That
> would be very strange. I shall check the standard now.


TC++PL on pages 199,200 says that const has by default internal linkage. So
the definition must be accomanied by the keyword extern too.


So my code becomes:


temp2.cpp:

extern const int x=17;


temp.cpp:

#include <iostream>


extern const int x;


int main()
{
 const unsigned char *p=reinterpret_cast<const unsigned char *>(&x);
 
 
 // Shows x representation in memory in byte values
 // including padding bits
 for(unsigned long i=0; i<sizeof(x); ++i)
   std::cout<<static_cast<short>(p[i])<<" ";


}


C:\c>g++ temp.cpp temp2.cpp -o temp

C:\c>temp
17 0 0 0
C:\c>


So in this case the compiler can know if the const object or *reference* is
accessed in another translation unit.



However why a compiler would "inline" const int x=7; and  would not be able
to "inline" const int &x=7; isn't clear and would be nice if you explained
it to us. And please do not involve L1/L2 caches, we are talking about
inline substitution here. And my CPU may have no cache.




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

I assume gcc is a bit naughty. However, as long as I know about the
problem, it does allow me to write working code that is portable to other
compilers.

/Per W

On Sat, 31 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Ioannis Vranos [mailto:iv...@em...]
> > Sent: Saturday, May 31, 2003 3:13 AM
> > To: Dev-C++ Mailing List (dev...@li...)
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > > -----Original Message-----
> > > From: Per Westermark [mailto:pw...@ia...]
> > > Sent: Saturday, May 31, 2003 6:38 AM
> > > To: Ioannis Vranos
> > > Cc: Dev-C++ Mailing List
> > > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > > inicializations
> > >
> > >
> > > See below
> > >
> > >
> > > If you know that you need to take the address in another file, then
> > > declare it as:
> > >     extern const int SIZE = 7;
> >
> >
> > I am sorry to tell you this, but this is *nonsense*. The C++
> > standard doesn't require to define it like this.
>
>
>
> I just checked it and it seems you are right. Don't know why yet.
>
>
> However does the above style make the compiler to give it an address? That
> would be very strange. I shall check the standard now.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

Please.

I'm not talking about C++ standard.
I'm talking about a real gcc 3.2 behaviour.
This isn't what I think but what my compiler does:

--- def.cc ---
const int x = 7;
--- ref.cc ---
#include <stdio.h>
extern const int x;
int main() {
    printf("value x = %d\n",x);
    printf("addr x = %p\n",&x);
    return 0;
}
--- build ---
>g++ -c def.c
>g++ -c ref.c
>g++ def.o ref.o -lstdc++ -o test.exe
--- result ---
ref.o(.text+0x3f):ref.cc: undefined reference to `x'
ref.o(.text+0x54):ref.cc: undefined reference to `x'
--- def.s ---
        .file   "def.cc"
        .text
        .align 4
_x:
        .long   7
--- ref.s ---
        .file   "ref.cc"
        .def    ___main;        .scl    2;      .type   32;     .endef
        .text
LC0:
        .ascii "value x = %d\12\0"
LC1:
        .ascii "addr x = %p\12\0"
        .align 2
.globl _main
        .def    _main;  .scl    2;      .type   32;     .endef
_main:
LFB1:
        pushl   %ebp
LCFI0:
        movl    %esp, %ebp
LCFI1:
        subl    $8, %esp
LCFI2:
        andl    $-16, %esp
        movl    $0, %eax
        movl    %eax, -4(%ebp)
        movl    -4(%ebp), %eax
        call    __alloca
        call    ___main
        subl    $8, %esp
        pushl   _x
        pushl   $LC0
LCFI3:
        call    _printf
        addl    $16, %esp
        subl    $8, %esp
        pushl   $_x
        pushl   $LC1
        call    _printf
        addl    $16, %esp
        movl    $0, %eax
        leave
        ret
LFE1:
        .def    _printf;        .scl    2;      .type   32;     .endef
--- end ---

As you can see, def.cc doesn't export the const int x.

If I instead make the following change, everything will work ok, since
now, x is exported from def.o.

--- def.cc ---
extern int x = 7;
--- def.s ---
        .file   "def.cc"
.globl _x
        .text
        .align 4
_x:
        .long   7
--- end ---

/Per W

On Sat, 31 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 6:38 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > See below
> >
> >
> > If you know that you need to take the address in another file, then
> > declare it as:
> >     extern const int SIZE = 7;
>
>
> I am sorry to tell you this, but this is *nonsense*. The C++ standard
> doesn't require to define it like this.
>
>
> I can define a const object in the global namespace:
>
> const int x=7;
>
>
>
> and in another file I can do this:
>
>
> #include <iostream>
>
>
> extern const int x;
>
> // ...
>
>
> void f()
> {
>    const unsigned char *p=reinterpret_cast<const unsigned char *>(&x);
>
>
>  // Shows SIZE representation in memory in byte values
>  // including padding bits
>    for(unsigned long i=0; i<sizeof(x); ++i)
>       std::cout<<static_cast<short>(p[i])<<" ";
> }
>
>
>
>
>
>
>
> > It doesn't. Either make sure that the file that declares SIZE
> > takes it's
> > address, or declare it as 'extern const int SIZE = 7;'
>
>
>
> Please direct me in the C++ standard where it mentions such a requirement.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: Ioannis Vranos [mailto:iv...@em...] 
> Sent: Saturday, May 31, 2003 3:13 AM
> To: Dev-C++ Mailing List (dev...@li...)
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...] 
> > Sent: Saturday, May 31, 2003 6:38 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> > inicializations
> > 
> > 
> > See below
> > 
> > 
> > If you know that you need to take the address in another file, then
> > declare it as:
> >     extern const int SIZE = 7;
> 
> 
> I am sorry to tell you this, but this is *nonsense*. The C++ 
> standard doesn't require to define it like this.



I just checked it and it seems you are right. Don't know why yet.


However does the above style make the compiler to give it an address? That
would be very strange. I shall check the standard now.




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Saturday, May 31, 2003 6:38 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> See below
> 
> 
> If you know that you need to take the address in another file, then
> declare it as:
>     extern const int SIZE = 7;


I am sorry to tell you this, but this is *nonsense*. The C++ standard
doesn't require to define it like this.


I can define a const object in the global namespace:

const int x=7;



and in another file I can do this:


#include <iostream>


extern const int x;

// ...


void f()
{
   const unsigned char *p=reinterpret_cast<const unsigned char *>(&x);
 
 
 // Shows SIZE representation in memory in byte values
 // including padding bits
   for(unsigned long i=0; i<sizeof(x); ++i)
      std::cout<<static_cast<short>(p[i])<<" ";
}







> It doesn't. Either make sure that the file that declares SIZE 
> takes it's
> address, or declare it as 'extern const int SIZE = 7;'



Please direct me in the C++ standard where it mentions such a requirement.




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

See below

/Per W

On Sat, 31 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 3:18 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > Give a declaration:
> >
> >   const int SIZE = 7;
> >
> > If you don't take the address of it, the compiler will generate code
> > looking like:
>
>
> It is difficult for the compiler to know if I use its address in another
> file. Usually the linker notices the uses in other files.
>

If you know that you need to take the address in another file, then
declare it as:
    extern const int SIZE = 7;

>
>
> >
> >   pushl $7
> >
> > If you take the address of it, the compiler will notice and
> > generate code
> > like:
> >
> >   pushl $_SIZE
> >
> >   ...
> >
> >   _SIZE:
> >     .long 7
> >
> > where the second case will store _SIZE in .text and not in .data.
>
>
> I can't understand the above very much but I do not think the compiler cn
> check every file for this, only the linker. Also what if I make obj files
> and then add some code in a cpp file that uses the address, make a new obj
> annd then link all objs together?
>

It doesn't. Either make sure that the file that declares SIZE takes it's
address, or declare it as 'extern const int SIZE = 7;'

>
>
> > You will be able to take the address of SIZE from one object
> > file. If you
> > declare 'const int SIZE = 7;' in another file to and try to take the
> > address of it, you will correctly get a linker error. If you
> > in the other
> > file declares 'extern const int SIZE', that file will always
> > reference the
> > variable SIZE, since it can't do any inlining.
>
>
>
> This is a bit difficult. You know, extern const int SIZE; is a *definition*
> in the absense of another definition and takes the default value 0.
>

extern const int SIZE; will just tell the compiler that somewhere in some
other object file, there is a symbol SIZE. The compile unit that sees this
declaration will not allocate any variable, so no default value either.

>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@te...>]

A small correction:



> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Saturday, May 31, 2003 3:18 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> Give a declaration:
> 
>   const int SIZE = 7;
> 
> If you don't take the address of it, the compiler will generate code
> looking like:


It is difficult for the compiler to know if I use its address in another
file. Usually the linker notices the uses in other files.



> 
>   pushl $7
> 
> If you take the address of it, the compiler will notice and 
> generate code
> like:
> 
>   pushl $_SIZE
> 
>   ...
> 
>   _SIZE:
>     .long 7
> 
> where the second case will store _SIZE in .text and not in .data.


I can't understand the above very much but I do not think the compiler cn
check every file for this, only the linker. Also what if I make obj files
and then add some code in a cpp file that uses the address, make a new obj
annd then link all objs together?


 
> You will be able to take the address of SIZE from one object 
> file. If you
> declare 'const int SIZE = 7;' in another file to and try to take the
> address of it, you will correctly get a linker error. If you 
> in the other
> file declares 'extern const int SIZE', that file will always 
> reference the
> variable SIZE, since it can't do any inlining.



=> This is a bit difficult. You know, extern const int SIZE=17; is a
*definition* in the absense of another definition.



Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@te...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Saturday, May 31, 2003 3:18 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> Give a declaration:
> 
>   const int SIZE = 7;
> 
> If you don't take the address of it, the compiler will generate code
> looking like:


It is difficult for the compiler to know if I use its address in another
file. Usually the linker notices the uses in other files.



> 
>   pushl $7
> 
> If you take the address of it, the compiler will notice and 
> generate code
> like:
> 
>   pushl $_SIZE
> 
>   ...
> 
>   _SIZE:
>     .long 7
> 
> where the second case will store _SIZE in .text and not in .data.


I can't understand the above very much but I do not think the compiler cn
check every file for this, only the linker. Also what if I make obj files
and then add some code in a cpp file that uses the address, make a new obj
annd then link all objs together?


 
> You will be able to take the address of SIZE from one object 
> file. If you
> declare 'const int SIZE = 7;' in another file to and try to take the
> address of it, you will correctly get a linker error. If you 
> in the other
> file declares 'extern const int SIZE', that file will always 
> reference the
> variable SIZE, since it can't do any inlining.



This is a bit difficult. You know, extern const int SIZE; is a *definition*
in the absense of another definition and takes the default value 0.




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: RES: [Dev-C++] Optimizing C code, what is best??

[Per W. <pw...@ia...>]

It is nice that you can laugh at my code. However, I DID benchmark
the code before writing the previous mail...

Don't stare yourself blind at number of instructions in the assembler
file.

Machine 1: Pentium II, 2*400MHz, 512MB PC100, W2K Pro
Machine 2: AMD Athlon 1300MHz, 1GB PC133, WinXP Pro
Machine 3: AMD XP2600+, 1GB 400MHz CL2.5, WinXP Pro
Machine 4: Celeron 2*566MHz, 512MB PC100, GNU/Linux Debian 3.0

Test 1: Loop from original mail
Test 2: Optimization 1
Test 3: Optimization 2 - the one I sent in mail
Test 4: Loop unrolling - failed because of code size/complexity

All times are in seconds calendar time, with the test program running at
>= 98% (except of course for the two dual-processor machines).

Machine  1:     2:    3:    4:     Note:
Test 1:  198    60    32    193    (compiler inlined code)
Test 2:  233    54    29    223    (compiler inlined code)
Test 3:  100    24    12    168    (compiler inlined code)
Test 4:  198    71    37    132    (compiler unrolled loop 10 times)

The big loss for Test 4 was that it wasn't inlined, and since I made 1
billion calls with vector length 7, the method call time was significant.

Machine 1-3 used gcc 3.2 with -O3, -march=pentium3
Machine 4 used gcc 2.95 with -O3, -march=pentium

---

Same tests as above, but with -O2, i.e. no inlining

Machine  1:     2:    3:    4:
Test 1:  263    84    45    298
Test 2:  303    72    39    304
Test 3:  233    68    36    255
Test 4:  199    71    37    231

---

Conclusion: Loop alternative 3 was always advantageous for all
processors, with or without inlining. With inlining off, the manual
inlining of alternative 4 gave a further improvement for the P2 and
Celeron machines, while being just a bit slower for the AMD machines.

As can be seen, the different constructs did make a significant
difference, especially when inlining. Are you really sure that the above
results are just a laugh, and that nowadays, you don't have to bother
about your code anymore? If such a quick rewrite can be made to a
function consuming 50% of the total runtime, I'd say it is work
looking at the function.

---

#include <time.h>
#include <stdio.h>

typedef unsigned __int64 DWORD64;
typedef unsigned short WORD;


class CTestClass {
    public:
        enum {
            rows = 20,
            cols = 7
        };
        short *sData[rows];
        CTestClass();
        DWORD64 computeDistance1(short *src,const WORD &wRow,const WORD
&wColFrom,const WORD &wColTo) const;
        DWORD64 computeDistance2(short *src,const WORD wRow,const WORD
wColFrom,const WORD wColTo) const;
        DWORD64 computeDistance3(short *src,const WORD wRow,const WORD
wColFrom,const WORD wColTo) const;
        DWORD64 computeDistance4(short *src,const WORD wRow,const WORD
wColFrom,const WORD wColTo) const;
};

CTestClass::CTestClass() {
    for (int r = 0; r < rows; r++) {
        sData[r] = new short[cols];
        for (int c = 0; c < cols; c++) {
            sData[r][c] = r+c;
        }
    }
}

DWORD64 CTestClass::computeDistance1(short *src,const WORD &wRow,const
WORD &wColFrom,const WORD &wColTo) const {
    DWORD64 qwDist = 0;
    int iA;
    short *sp = sData[wRow];
    for (WORD wCol = wColFrom; wCol <= wColTo; ++wCol) {
        iA = src[wCol] - sp[wCol];
        qwDist += iA*iA;
    }
    return qwDist;
}

DWORD64 CTestClass::computeDistance2(short *src,const WORD wRow,WORD
wColFrom,const WORD wColTo) const {
    DWORD64 qwDist = 0;
    int iA;
    short *sp = sData[wRow] + wColFrom;
    src += wColFrom;
    while (wColFrom++ <= wColTo) {
        iA = *src++ - *sp++;
        qwDist += iA*iA;
    }
    return qwDist;
}

DWORD64 CTestClass::computeDistance3(short *src,const WORD wRow,WORD
wColFrom,const WORD wColTo) const {
    DWORD64 qwDist = 0;
    int iA;
    short *sp = sData[wRow] + wColFrom;
    short *end = src + wColTo;
    src += wColFrom;
    while (src <= end) {
        iA = *src++ - *sp++;
        qwDist += iA*iA;
    }
    return qwDist;
}

DWORD64 CTestClass::computeDistance4(short *src,const WORD wRow,WORD
wColFrom,const WORD wColTo) const {
    DWORD64 qwDist = 0;
    int iA;
    short *sp = sData[wRow] + wColFrom;
    short *end = src + wColTo;
    src += wColFrom;

    while (src <= end) {
        iA = *src++ - *sp++;
        qwDist += iA*iA;
        if (src > end) break;

        iA = *src++ - *sp++;
        qwDist += iA*iA;
        if (src > end) break;

        iA = *src++ - *sp++;
        qwDist += iA*iA;
        if (src > end) break;

        iA = *src++ - *sp++;
        qwDist += iA*iA;
    }
    return qwDist;
}

int main() {
    CTestClass tst;
    short v[CTestClass::cols] = {4,7,3,2,1,8,3};
    int i;
    time_t t0,t1,t2,t3,t4;
    DWORD64 r1,r2,r3,r4;

    t0 = time(NULL);
    printf("start\n");
    for (i = 0; i < 1000000000; i++) {
        r1 = tst.computeDistance1(v,5,0,tst.cols-1);
    }
    t1 = time(NULL);
    printf("1 (%u) %I64u\n",(unsigned)(t1-t0),r1);
    for (i = 0; i < 1000000000; i++) {
        r2 = tst.computeDistance2(v,5,0,tst.cols-1);
    }
    t2 = time(NULL);
    printf("2 (%u) %I64u\n",(unsigned)(t2-t1),r2);
    for (i = 0; i < 1000000000; i++) {
        r3 = tst.computeDistance3(v,5,0,tst.cols-1);
    }
    t3 = time(NULL);
    printf("3 (%u) %I64u\n",(unsigned)(t3-t2),r3);
    for (i = 0; i < 1000000000; i++) {
        r4 = tst.computeDistance4(v,5,0,tst.cols-1);
    }
    t4 = time(NULL);
    printf("4 (%u) %I64u\n",(unsigned)(t4-t3),r4);
}

/Per W

On Fri, 30 May 2003, Daniel K. O. wrote:

>
> >From Per:
>  >      while (src <= end) {
>  >          iA = *src++ - *sp++;
>  >          dwDist2 += iA*iA;
>  >      }
>
> >From Zodiaq:
>  >  >                 for( WORD wCol = wColFrom; wCol <= wColTo; ++wCol )
>  >  >                 {
>  >  >                         iA = src[ wCol ] - sP[ wCol ];
>  >  >                         dwDist += iA * iA;
>  >  >                 }
>
>
>
>
> It was really funny those recent comments about "the best way to write C
> code for optimization".
> Yeah, some years ago most compilers were just "smart assemblers". But
> nowadays, worrying about stuffs like 'array[i++]' vs. '*pointer++' trying to
> make it "easier" to the compiler doesn't make much sense. If your compiler
> can't figure obvious stuffs - like iterating throgh an array - and make the
> best code for it, the best way is to find a better compiler.
> And GCC is a mature compiler; comments like "it can optimize in a way it
> won't work" without any test-case that proves it has a *serious* bug, is a
> little malicious.
>
> Just before writing this mail, I tried with a small sample:
>
> ---
> int foo2(int vet1[], int vet2[], int n)
> {
>         int* i1 = vet1, *i2 = vet2, *j = vet1+n;
>         int c;
>         while(i1!=j)
>                 c += *i1++ + *i2++;
>         return c;
> }
>
> int foo1(int vet1[], int vet2[], int n)
> {
>         int i, c;
>         for (i=0; i<n; i++)
>                 c += vet1[i] + vet2[i];
>         return c;
> }
> ---
>
>
> And compiled it with:
>
> -S -march=pentium3 -O2
>
>
> The results:
>     foo1  --  30 lines
>     foo2  --  29 lines
>
> With just 1 instruction less (for this small example), I don't see the point
> in rewriting the code to make it faster. If I want to spend my time making
> it faster, better do it directly in assembly, not through C.
> So, my question: do you guys think that really worth being so "paranoic"
> about such details? I mean, obviously the algorithm design is important, but
> is really needed to even care about the different ways to write the same
> command, to see "which one is faster"?
>
>
>
>
>
>
> Daniel K. O.
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

Give a declaration:

  const int SIZE = 7;

If you don't take the address of it, the compiler will generate code
looking like:

  pushl $7

If you take the address of it, the compiler will notice and generate code
like:

  pushl $_SIZE

  ...

  _SIZE:
    .long 7

where the second case will store _SIZE in .text and not in .data.

You will be able to take the address of SIZE from one object file. If you
declare 'const int SIZE = 7;' in another file to and try to take the
address of it, you will correctly get a linker error. If you in the other
file declares 'extern const int SIZE', that file will always reference the
variable SIZE, since it can't do any inlining.

/Per W

On Fri, 30 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 2:04 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > Oops, goofed a bit. See below.
> >
> > But then again
> > > - 'a const &int = <value>' is a complicated declaration
> > just to get a
> >
> > Should of course be 'const int SIZE = <value>'
> >
> > > "magic" address to compare against.
>
>
> I still do not understand what you mean by the above. The language rules are
> language rules. A global const variable has an address (at least it behaves
> as it has, when we want to use this address).
>
> Only references do not have their own address.
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RES: [Dev-C++] Optimizing C code, what is best??

[Daniel K. O. <dan...@ya...>]

From Per:
 >      while (src <= end) {
 >          iA = *src++ - *sp++;
 >          dwDist2 += iA*iA;
 >      }

From Zodiaq:
 >  >                 for( WORD wCol = wColFrom; wCol <= wColTo; ++wCol )
 >  >                 {
 >  >                         iA = src[ wCol ] - sP[ wCol ];
 >  >                         dwDist += iA * iA;
 >  >                 }




It was really funny those recent comments about "the best way to write C
code for optimization".
Yeah, some years ago most compilers were just "smart assemblers". But
nowadays, worrying about stuffs like 'array[i++]' vs. '*pointer++' trying to
make it "easier" to the compiler doesn't make much sense. If your compiler
can't figure obvious stuffs - like iterating throgh an array - and make the
best code for it, the best way is to find a better compiler.
And GCC is a mature compiler; comments like "it can optimize in a way it
won't work" without any test-case that proves it has a *serious* bug, is a
little malicious.

Just before writing this mail, I tried with a small sample:

---
int foo2(int vet1[], int vet2[], int n)
{
        int* i1 = vet1, *i2 = vet2, *j = vet1+n;
        int c;
        while(i1!=j)
                c += *i1++ + *i2++;
        return c;
}

int foo1(int vet1[], int vet2[], int n)
{
        int i, c;
        for (i=0; i<n; i++)
                c += vet1[i] + vet2[i];
        return c;
}
---


And compiled it with:

-S -march=pentium3 -O2


The results:
    foo1  --  30 lines
    foo2  --  29 lines

With just 1 instruction less (for this small example), I don't see the point
in rewriting the code to make it faster. If I want to spend my time making
it faster, better do it directly in assembly, not through C.
So, my question: do you guys think that really worth being so "paranoic"
about such details? I mean, obviously the algorithm design is important, but
is really needed to even care about the different ways to write the same
command, to see "which one is faster"?






Daniel K. O.

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@te...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...]=20
> Sent: Saturday, May 31, 2003 2:04 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array=20
> inicializations
>=20
>=20
> Oops, goofed a bit. See below.
>
> But then again
> > - 'a const &int =3D <value>' is a complicated declaration=20
> just to get a
>=20
> Should of course be 'const int SIZE =3D <value>'
>=20
> > "magic" address to compare against.


I still do not understand what you mean by the above. The language rules =
are
language rules. A global const variable has an address (at least it =
behaves
as it has, when we want to use this address).=20

Only references do not have their own address.




Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@te...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Saturday, May 31, 2003 1:45 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> If you try to compare the address of SIZE from two different 
> modules, you
> will - I haven't tested for different compilers - probably 
> get a linker
> error, since both object files will contain a _SIZE symbol. 


But that would be broken behaviour. So I do not think we will get a linker
error.



> But then again
> - 'a const &int = <value>' is a complicated declaration just to get a
> "magic" address to compare against.


I do not understand the above. The compiler has to produce an address when
we use that address, the same way that inline functons do have an address.



Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

Oops, goofed a bit. See below.

/Per W

On Sat, 31 May 2003, Per Westermark wrote:

> If you check gcc, it will allocate a SIZE symbol in the text area, if
> someone tries to take the address of it. By storing it in the text area,
> you will get a GP if you try to write to it, since the text area is
> write-protected for most operating systems.
>
> Since you are not allowed to change it, you can't use it as a target for a
> memory copy. If you use it as the source for a memory copy, it doesn't
> matter where it is - or if there is multiple copies of the value - since
> the copy would still copy the value of the const symbol.
>
> If you try to compare the address of SIZE from two different modules, you
> will - I haven't tested for different compilers - probably get a linker
> error, since both object files will contain a _SIZE symbol. But then again
> - 'a const &int = <value>' is a complicated declaration just to get a

Should of course be 'const int SIZE = <value>'

> "magic" address to compare against.
>
> /Per W
>
> On Fri, 30 May 2003, Ioannis Vranos wrote:
>
> > > -----Original Message-----
> > > From: Per Westermark [mailto:pw...@ia...]
> > > Sent: Saturday, May 31, 2003 12:19 AM
> > > To: Ioannis Vranos
> > > Cc: Dev-C++ Mailing List
> > > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > > inicializations
> > >
> > >
> > > At least for scalar data types, it doesn't matter if a global const xx
> > > variable is used in other modules.
> >
> >
> > Why? Imagine in another unit:
> >
> >
> > extern const int SIZE;
> >
> > void f()
> > {
> >   cout<<&SIZE;
> > }
> >
> >
> >
> > > Since the compiler inlines the value of the const variable
> > > everytime it is
> > > used, there is no need to keep a global reference for use by
> > > other source
> > > files.
> >
> >
> > What if we use its address in another unit? What about this:
> >
> > #include <cstring>
> >
> > extern const int SIZE;
> >
> > // in a function ...
> >
> > using std::memcpy;
> >
> > // ...
> >
> > int *p=new int;
> >
> > memcpy(p, &SIZE, sizeof(*p));
> >
> >
> >
> >
> > Ioannis Vranos
> >
> > * Programming pages: http://www.noicys.freeurl.com
> > * Alternative URL 1: http://run.to/noicys
> > * Alternative URL 2: http://www.noicys.cjb.net
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: eBay
> > Get office equipment for less on eBay!
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

If you check gcc, it will allocate a SIZE symbol in the text area, if
someone tries to take the address of it. By storing it in the text area,
you will get a GP if you try to write to it, since the text area is
write-protected for most operating systems.

Since you are not allowed to change it, you can't use it as a target for a
memory copy. If you use it as the source for a memory copy, it doesn't
matter where it is - or if there is multiple copies of the value - since
the copy would still copy the value of the const symbol.

If you try to compare the address of SIZE from two different modules, you
will - I haven't tested for different compilers - probably get a linker
error, since both object files will contain a _SIZE symbol. But then again
- 'a const &int = <value>' is a complicated declaration just to get a
"magic" address to compare against.

/Per W

On Fri, 30 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Saturday, May 31, 2003 12:19 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > At least for scalar data types, it doesn't matter if a global const xx
> > variable is used in other modules.
>
>
> Why? Imagine in another unit:
>
>
> extern const int SIZE;
>
> void f()
> {
>   cout<<&SIZE;
> }
>
>
>
> > Since the compiler inlines the value of the const variable
> > everytime it is
> > used, there is no need to keep a global reference for use by
> > other source
> > files.
>
>
> What if we use its address in another unit? What about this:
>
> #include <cstring>
>
> extern const int SIZE;
>
> // in a function ...
>
> using std::memcpy;
>
> // ...
>
> int *p=new int;
>
> memcpy(p, &SIZE, sizeof(*p));
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@te...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Saturday, May 31, 2003 12:19 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> At least for scalar data types, it doesn't matter if a global const xx
> variable is used in other modules.


Why? Imagine in another unit:


extern const int SIZE;

void f()
{
  cout<<&SIZE;
}



> Since the compiler inlines the value of the const variable 
> everytime it is
> used, there is no need to keep a global reference for use by 
> other source
> files.


What if we use its address in another unit? What about this:

#include <cstring>

extern const int SIZE;

// in a function ...

using std::memcpy;

// ...

int *p=new int;

memcpy(p, &SIZE, sizeof(*p));




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] Optimizing C code, what is best??

[Per W. <pw...@ia...>]

Some sugestions:
1 - you are summing 16-bit numbers into 32-bit, but returning 64-bit.
2 - you are sending in wRow,wColFrom,wColTo as references, despite not
having any intention of sending back any change.
3 - you are using a lot of variables in the loop.
4 - you are using a lot of indexing in the loop.

A suggested change might be:

DWORD CMyClass::computeDistSquare(const short *src,
                                  const WORD wRow,
                                  const WORD wColFrom,const
                                  WORD wColTo) const
{
    DWORD dwDist2 = 0;
    int iA;
    short *sp = sData[wRow] + wColFrom;
    short *end = src + wColTo;
    src += wColFrom;
    while (src <= end) {
        iA = *src++ - *sp++;
        dwDist2 += iA*iA;
    }
    return dwDist2;
}

Now the loop uses 5 variables instead of 7 - each variable just 32-bit
large and fitting in a single register.

/Per W

On Fri, 30 May 2003, Zodiaq wrote:

> Hello All Dev-cpp-users,
>
>   there is one function in my program that needs some optimization...
> the problem is about computing distance between parts of two
> vectors... currently it is done like this:
>
> DWORD64 computeDistance( short *src, const WORD &wRow, const WORD
> &wColFrom, const WORD &wColTo ) const
>         {
>                 DWORD dwDist = 0;
>                 INT iA;
>                 short *sP = sData[ wRow ];
>                 for( WORD wCol = wColFrom; wCol <= wColTo; ++wCol )
>                 {
>                         iA = src[ wCol ] - sP[ wCol ];
>                         dwDist += iA * iA;
>                 }
>                 return dwDist;
>       }
>
> src is element I want to compute distance from specified element of
> big array of rows... gprof shows that this function takes over 90% of
> total program time...
>
> well, I know it is not about DevC++, but since I made progs under it
> and this is quite simple problem, I hope that someone can and will
> help me...
>
> The best solution for me would be ASM code optimized for AMD Athlon
> processor (for my computer, which as only one will run this code). For
> someone with good knowledge of ASM this is only few moments, and for
> me great deal of work - I don't know ASM a bit... so please someone
> help me... thank you in advance!
>
> --
> regards, Zodiaq...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

At least for scalar data types, it doesn't matter if a global const xx
variable is used in other modules.

Since the compiler inlines the value of the const variable everytime it is
used, there is no need to keep a global reference for use by other source
files.

Since an address is 4 bytes for normal 32-bit code, any const variable <=
4 byte will consume same space for the inlined value as the address needed
to reference a real variable. However, the inlined value will
automatically follow in the instruction stream, thereby using the L1/L2
caches optimally, while an address reference to a separate storage would
have to use a different cache line in the processor.

The net result is that a global 'const int xx = <value>' is just as
efficient as if the declararation was written locally within a function.
Both alternatives will be inlined, without any global or auto variable
whatsoever.

/Per W

On Fri, 30 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: Per Westermark [mailto:pw...@ia...]
> > Sent: Friday, May 30, 2003 2:39 PM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > If the reference is declared auto, the compiler can optimize away the
> > reference, but if it's declared as a global, the compiler
> > won't optimize
> > it away, since by definition, a reference - just like a
> > pointer - is an
> > address to a value, not the value itself.
>
>
>
> Yes I agree. I was talking about local auto const references. Global const
> variables are difficult to optimise out too, because the compiler doesn't
> know if it is used in another compilation unit (file).
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Ioannis V. <iv...@te...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Friday, May 30, 2003 2:39 PM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] #DEFINE versus cont variables in array 
> inicializations
> 
> 
> If the reference is declared auto, the compiler can optimize away the
> reference, but if it's declared as a global, the compiler 
> won't optimize
> it away, since by definition, a reference - just like a 
> pointer - is an
> address to a value, not the value itself.



Yes I agree. I was talking about local auto const references. Global const
variables are difficult to optimise out too, because the compiler doesn't
know if it is used in another compilation unit (file).




Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

What smart compilers do, is to let the caller allocate the memory for the
temporary object, and then have the function perform all object
manipulation with the temporary object. On return, there is no need for
any object copying, since the resulting object is in the callers stack
frame and not in the called functions.

If the caller wants to make two calls, the compiler will - depending on
object usage - allocate one or two temporary objects that the called
function will use.

/Per W

On Fri, 30 May 2003, OROSZI Bal=E1zs wrote:

> Maxim Yemelyanov wrote:
> > Do GCC really does like this? I mean, even if return value is class, no=
t a
> > referense?
>
> Yes, that's what I said.
>
> > That's terrible then! Because you can run into trouble when the
> > returned value should be used in another function call:
> >
> > class C { ... };
> >
> > C getC(int something){ C c(something); return c; }
> >
> > void f(C& c1, C& c2);
> >
> > f(getC(1), getC(2)); <-- one of C objects will override another (becaus=
e it
> > can (or "will") be created at the same address).
>
> WHAT?
> No, what happens here is, that for getC(1) and getC(2) DIFFERENT objects
> will be returned. While would they be the same??? When you call getC(),
> then a LOCAL variable will be created. THAT local variable is returned
> without copy, as it would be destroyed anyway. So, instead of copying
> it, and destroying the local variable (as it gets out of scope at the
> end of getC), GCC will simply return c, without copy.
> I don't see why this would cause a problem. Even in your example, it
> works perfectly.
>
> I don't understand you clearly...
>
> > I agree, this can happed, if getC is declared as returning reference:
> >
> > C& getC(int something){ C c(something); return c; }
>
> It is wrong. A function should NEVER return a reference to a LOCAL
> variable, as the local variable will be destroyed, and an invalid
> reference will be returned.
>
> > , but that's what I always try to avoid
>
> That is wise :)
>
> > I usually turn off any optimization, 'cos I heard that GCC can "optimiz=
e too
> > much" :-)
>
> I almost always use level 4 optimization, but at least level 3. It
> didn't cause any trouble for me so far. Even wxWindows is compiled with
> -O4 for me, and it works fine.
> There is no problem using optimization - it won't do harm (in the 90% of
> the cases).
>
> --
> Greetings,
>    Bal=E1zs
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

[Dev-C++] Optimizing C code, what is best??

[Zodiaq <zo...@ac...>]

Hello All Dev-cpp-users,

  there is one function in my program that needs some optimization...
the problem is about computing distance between parts of two
vectors... currently it is done like this:

DWORD64 computeDistance( short *src, const WORD &wRow, const WORD
&wColFrom, const WORD &wColTo ) const
        {
                DWORD dwDist = 0;
                INT iA;
                short *sP = sData[ wRow ];
                for( WORD wCol = wColFrom; wCol <= wColTo; ++wCol )
                {
                        iA = src[ wCol ] - sP[ wCol ];
                        dwDist += iA * iA;
                }
                return dwDist;
      }

src is element I want to compute distance from specified element of
big array of rows... gprof shows that this function takes over 90% of
total program time...
      
well, I know it is not about DevC++, but since I made progs under it
and this is quite simple problem, I hope that someone can and will
help me...

The best solution for me would be ASM code optimized for AMD Athlon
processor (for my computer, which as only one will run this code). For
someone with good knowledge of ASM this is only few moments, and for
me great deal of work - I don't know ASM a bit... so please someone
help me... thank you in advance!

-- 
regards, Zodiaq...

Re: [Dev-C++] #DEFINE versus cont variables in array inicializations

[<or...@vp...>]

Maxim Yemelyanov wrote:
> Do GCC really does like this? I mean, even if return value is class, not a
> referense?

Yes, that's what I said.

> That's terrible then! Because you can run into trouble when the
> returned value should be used in another function call: 
> 
> class C { ... };
> 
> C getC(int something){ C c(something); return c; }
> 
> void f(C& c1, C& c2);
> 
> f(getC(1), getC(2)); <-- one of C objects will override another (because it
> can (or "will") be created at the same address).

WHAT?
No, what happens here is, that for getC(1) and getC(2) DIFFERENT objects 
will be returned. While would they be the same??? When you call getC(), 
then a LOCAL variable will be created. THAT local variable is returned 
without copy, as it would be destroyed anyway. So, instead of copying 
it, and destroying the local variable (as it gets out of scope at the 
end of getC), GCC will simply return c, without copy.
I don't see why this would cause a problem. Even in your example, it 
works perfectly.

I don't understand you clearly...

> I agree, this can happed, if getC is declared as returning reference:
> 
> C& getC(int something){ C c(something); return c; }

It is wrong. A function should NEVER return a reference to a LOCAL 
variable, as the local variable will be destroyed, and an invalid 
reference will be returned.

> , but that's what I always try to avoid

That is wise :)

> I usually turn off any optimization, 'cos I heard that GCC can "optimize too
> much" :-)

I almost always use level 4 optimization, but at least level 3. It 
didn't cause any trouble for me so far. Even wxWindows is compiled with 
-O4 for me, and it works fine.
There is no problem using optimization - it won't do harm (in the 90% of 
the cases).

--
Greetings,
   Balázs

RE: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Per W. <pw...@ia...>]

If the reference is declared auto, the compiler can optimize away the
reference, but if it's declared as a global, the compiler won't optimize
it away, since by definition, a reference - just like a pointer - is an
address to a value, not the value itself.

If the global was declared static, then file-level global optimization
would be able to notice if no part of the the file used it as an address
and might then convert it back to just a 'const int', but then again: why
not declare it as 'const int' from the beginning, since that is the
optimal form if we don't want to play with the address of it.

/Per W

On Fri, 30 May 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of Per Westermark
> > Sent: Friday, May 30, 2003 4:23 AM
> > To: Ioannis Vranos
> > Cc: Dev-C++ Mailing List
> > Subject: RE: [Dev-C++] #DEFINE versus cont variables in array
> > inicializations
> >
> >
> > Yes, we agree that 'const int x = <value>' is efficient.
> > We don't agree that 'const int &x = <value>' is efficient.
>
>
> The reference can't be used to provide the size of a built in array, so my
> mistake for that.
>
>
> On the other hand regarding reference, a compiler would be able to optimise
> out and make it occupy no more space.
>
>
> const int &x=7;
>
>
> Can you tell me why that wouldn't be able to be equivalent to #define x 7
> when used just as a value and not accessed in any other way?
>
> As I can think of it, a const reference should be more eaiser to optimise
> out than a const variable.
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re[2]: [Dev-C++] #DEFINE versus cont variables in array inicializations

[Maxim Y. <ma...@en...>]

Hello, OROSZI!

Friday, May 30, 2003 0:10:34 You wrote to dev...@li...:
OB> Per Westermark wrote:
>> I guess you don't think of gcc as a decent compiler then.

OB> An interesting thing I found, when examining g++ deeply:
OB> GCC is so smart, it even optimizes everything possible.
OB> Suppose you have a function, that returns a class. The normal behaviour 
OB> would be: call copy constructor, return copied object.
OB> BUT if the variable was a local variable (created in the function) and 
OB> you return that, then the "theoretical" behaviour would still be: copy 
OB> object, return copied object, delete local variable, BUT gcc makes it 
OB> very different: it simply return the local object without any copy, etc. 
OB> It is not harmful, as the object would have been deleted anyway, so it 
OB> is truly easier to simply return the local variable one-in-one. It is 
OB> faster for sure.
Do GCC really does like this? I mean, even if return value is class, not a
referense? That's terrible then! Because you can run into trouble when the
returned value should be used in another function call: 

class C { ... };

C getC(int something){ C c(something); return c; }

void f(C& c1, C& c2);

f(getC(1), getC(2)); <-- one of C objects will override another (because it
can (or "will") be created at the same address).

I agree, this can happed, if getC is declared as returning reference:

C& getC(int something){ C c(something); return c; }

, but that's what I always try to avoid (yes, I have functions like 'f', they
work with std::string objects);

OB> It truly does this, as I stated - I have checked the pointer for the
OB> object, and it is the same in the function, and the after return.

OB> Interesting...
I usually turn off any optimization, 'cos I heard that GCC can "optimize too
much" :-)

-- 
Regards!
Maxim

Re[2]: [Dev-C++] customize Makefile

[<ma...@en...>]

Hello, Luigi!

 Thursday, May 29, 2003, 6:52:29 PM you wrote:
>> Thanks to everyone, your advises were nice, but, Luigi's one was the best for
>> me, thanks! Dependency checking takes just a couple of seconds on my PC, so
>> I'm very satisfied :)

LS> I'm glad that I was of help.

LS> So it looks like latest version of Dev-C++ has fixed things such
LS> that "disable fast dependency" now works as expected. Can you confirm
LS> that? Could you tell which version of Dev-C++ you are running?
4.9.8.0
Fix is simple: now they include ALL *.h files directly or indireclty #include-d
in myfile.cpp onto "myfile.o:" line in Makefile :-)

LS> If you don't mind telling: where are you from?  
LS> The "ua" appended to your mail address stands for "ucraine"? 
LS> (just a guess :-)
Yes, you're right, I'm from Ukraine, Kharkov.

LS> P.S. I think you've only replied to me ... I guess you wished to
LS> say thanks to the whole list.
Yes, I just overlooked the "From" line :-)
Thanks to everyone!

-- 
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone:  +380 572 177977
WEB:    http://enigmasoft.com.ua
e-mail: ma...@en...
ICQ:    12253836