- new benchmark for my read/write algorithm... - 1 Update
- rules of initialisation in loop (in c and in c+++) - 7 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 07 09:47AM +0100 > Also, you can check to see if the return value of XADD, say count, is > (count & 0x0000FFFF) == 0xFFFF. That means the writers just intruded > into the reader logic, and an exception should be thrown. Humm... Then you would have to end the process. Rolling back the XADD woudln't be possible because another thread would rely on the state asynchronously. |
| fir <profesor.fir@gmail.com>: Mar 07 04:09PM -0800 W dniu czwartek, 7 marca 2019 23:08:20 UTC+1 użytkownik Paavo Helde napisał: > RAII, which is the strongest point of C++, ever. If you want this to > happen only once, you define x outside of the loop or as a static (if > appropriate). ok but this is not a good thing, its silly old c has it right way it is if you put Some x; in a loop the stack pointer dont moves back and forth every loop turn as it would be silly assigments in loop, ok , but initialisiation ? no, it is silly (it is silly becouse every turn in a loop you use the same variable so why destroing and re-creating it (it is silly as i already said), and if you want to re=set the value assigment is a way to go |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 07 07:11PM -0500 On 3/7/19 17:08, Paavo Helde wrote: ... > RAII, which is the strongest point of C++, ever. If you want this to > happen only once, you define x outside of the loop or as a static (if > appropriate). RAII is an idiom, which in C++ can be implemented by relying upon the pairing of constructor calls with destructor calls to acquire and release the relevant resource. That pairing is not itself RAII. An extreme counter-example would be a class that used the exact same pairing to release a resource in the constructor, and reacquire it in the destructor (obviously, the handle for any resource managed in that fashion would not be stored in a non-static member variable). I'm not saying that it would be reasonable to do so. I'm only using that example to point out that it's only when you use that pairing in a particular way that it implements RAII. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 08 06:08AM +0100 On 08.03.2019 01:09, fir wrote: > old c has it right way it is if you put Some x; in a loop the stack > pointer dont moves back and forth every loop turn as it would be > silly There is no need for a stack pointer adjustment. Cheers & hth., - Alf |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 08 07:55AM +0200 On 8.03.2019 2:09, fir wrote: > assigments in loop, ok , but initialisiation ? no, it is silly > (it is silly becouse every turn in a loop > you use the same variable so why destroing and re-creating it (it is silly as i already said), and if you want to re=set the value assigment is a way to go You sound like thinking that destroying and re-creating were automatically somehow more expensive than re-assignment. However, C++ is not some kind of script language where destroying and re-creating a variable would mean updating of some dynamic map. Destroying and re-creation might well be non-ops in C++. If the variable holds a resource like dynamically allocated memory or an open file handle, it might indeed be more expensive to destroy and re-create it all the time. On the other hand, leaving it undestroyed would mean the resource is kept around for longer than needed. For example, if iteration 0 requires a memory buffer of 100 MB and the rest of the loop iterations require a memory buffer of 1 MB, then in case of buffer reuse the unneeded 99 MB are unnecessarily held around for the whole loop duration. If this might be a problem or not depends on the situation. You cannot say that one way is automatically better than the other. Thankfully, C++ allows to use both ways as needed, after studying the performance profiler results. |
| David Brown <david.brown@hesbynett.no>: Mar 08 08:30AM +0100 On 08/03/2019 01:09, fir wrote: > ok > but this is not a good thing, its silly > old c has it right way it is if you put Some x; in a loop the stack pointer dont moves back and forth every loop turn as it would be silly C and C++ do this in /exactly/ the same way. > assigments in loop, ok , but initialisiation ? no, it is silly > (it is silly becouse every turn in a loop > you use the same variable so why destroing and re-creating it (it is silly as i already said), and if you want to re=set the value assigment is a way to go C does this too. But for both C and C++, the compiler can be smart about it. In neither case will you see the stack pointer being moved up and down - compilers combine stack pointer movements for efficiency. In C++, if the variable "x" inside the loop is a simple type that doesn't actually do anything in the constructor or destructor, then the cost is zero. /Logically/ the variable is constructed and destructed, but the generated code won't do more than necessary. |
| fir <profesor.fir@gmail.com>: Mar 08 12:55AM -0800 W dniu piątek, 8 marca 2019 06:55:59 UTC+1 użytkownik Paavo Helde napisał: > other. > Thankfully, C++ allows to use both ways as needed, after studying the > performance profiler results. looking that loop goes out of block end enters each block each turn in the loop {}{}{}{}{} is posibly an error, more apropriate would be to look at it that loop leaves block on break but not by continue (or default wind back/ next if you want to resize wariable in loop you sementaically can just call some resize on it not destroint and recreating it besides does you maybe know, or somebody thet when you got (in C, primary sasking on C here) struct Some {int x,t,z; }; for(;;) { Some x = { 10, 20, 30 }; } is this line inside a loop considered always as an initialization or is it considered maybe as assigment / some combination of initialization and assigment can you remind me if for(;;) { x = { 10, 20, 30 }; } works in c? im far from the compiler and cant check, and i dont remember |
| David Brown <david.brown@hesbynett.no>: Mar 08 10:40AM +0100 On 08/03/2019 09:55, fir wrote: > is this line inside a loop considered always as an initialization or > is it considered maybe as assigment / some combination of > initialization and assigment It is a definition and initialisation. As far as C is concerned, the lifetime of "x" starts when the loop's block is entered, and ends when the loop's block ends. Logically, "x" is created anew at the start of the block (once per loop), then initialised anew with these values. At the end of the loop, it is destroyed. In C, "constructing" an automatic variable is usually no more than a stack pointer change, or using a register. Initialisation is just setting the data in the stack frame or the register. "Destruction" is restoring the stack pointer. Initialisation and assignment of local variables is generally identical - you don't see a difference between "int x; x = 1;" and "int x = 1;" (except for const variables, and other syntactic details). In C++, objects can have more complicated constructors, destructors, initialisation and assignment - but the principle is /exactly/ the same. And in both cases, the compiler is free to optimise the code. Almost invariably (when there are no VLA's or other big stack allocations), compilers will do all necessary stack pointer manipulation in the function prologue and epilogue, and not bother moving it up and down within loops like this. This is identical for C and C++. > x = { 10, 20, 30 }; > } > works in c? im far from the compiler and cant check, and i dont remember It works for initialisation, but not for assignment. struct Some { int x, t, z; }; struct Some foo(void) { struct Some x = {1, 2, 3}; // OK in C and C++ return x; } struct Some foo2(void) { struct Some x; x = (struct Some) {1, 2, 3}; // OK in C, not in C++ return x; } struct Some foo3(void) { struct Some x; x = {1, 2, 3}; // OK in C++11, not in C return x; } (Compound literals as used in foo2 are in C99 and C11, but not in C++ except as compiler extensions - gcc allows them in C++, but I don't know about other compilers.) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment