disown
Last Activity: Apr 19 '09, 02:23 PM
Joined: Nov 13 '08
Location:
-
In order to get the complete picture, you also probably want to find out how many cpu cycles each one of those assembler instructions take, as JosAH pointed out. -
I forgot to mention lock-free techniques such as compare and swap.Leave a comment:
-
If the operation on the shared variable is atomic (one assembler instruction) you could technically skip the mutex, since you will always read a complete value. If not, you run the risk of reading a half-written variable. So best bet is to use a mutex, especially if you consider that variable sizes might change between architechtures.
If you want to protect yourself, but want better performance than with a mutex, and have many more...Leave a comment:
-
I get your point with fragmentation and stacks being continuous, and also that you need to have the exact same size of the new variable if you want to do an overwrite.
_But_ if you would extend the stack with a random access range delete (think of pulling out a plate from the middle of the stack), it would work. If simple variable 'a' refers to item 5 in the stack, and 'a' is assigned the value of a recently pushed return value (a=f()),...Leave a comment:
-
Banfa, thank you for your elaborate post.
I agree with you that this is the case. But with a small modification, it would work. One could check if the return value is replacing any old objects, and throw these orphans away. This might require deleting parts of the stack (random access), and might not be implemented for hardware reasons, I don't know. But as far as I see it, it could work. Or am I missing something?...Leave a comment:
-
Hi again. Sorry for the delay, I wanted to do some research before I felt like I could provide any useful feedback. By talking to colleagues I've found out that the stack is usually located in the L1 cache in the CPU, and that this abstractions functionality thus is hardware bound. I've never really considered that, I thought it was merely a way of handling automatic memory.
This I simply don't understand. I always...Leave a comment:
-
agreed.
I did read the article. A smart pointer (handle object) is sort of a flyweight pattern which does not directly address the real problem, but rather avoids it. You will still need to copy your flyweight smart pointer around, plus you get all the other problems related to reference counting.
My point is that what you a) do not want to spend time making a copy to return, b) do not want to be _forced_...Leave a comment:
-
Weaknessforcats , thanks for taking your time answering.
What do you mean by this? Generally avoid or only passing pointers to stack memory which goes out of scope?
This I understand. I understand that variables do go out of scope, but what I meant was that it sometimes might be useful if they don't (if they survive to the parent scope).
What I don't understand...Leave a comment:
-
Thank you for your answer. What I tried to show with my example is that I often want to put things on the caller stack. This is true on many occasions, where methods build, initializes and returns an instance. The example I showed was an example where the implementation class is unknown by the caller, which I felt was an important example, since it prohibits the caller to instantiate the variable on his stack before calling the builder method (this...Leave a comment:
-
RVO alternative
Hi,
I'm having problems with dynamic memory, and returning values from functions. Consider the following function signature:
And the calling:Code:Thing buildThing() { return ThingImpl; }
The calling can be optimized through return value optimization (RVO), such that no copying needs to take place. The caller will get the value on its stack directly, and no heap memory...Code:Thing& t = buildThing();
-
I also don't think there is any way in C++ to pass a reference to a function, and then construct a variable directly into that memory space, thus you may not fiddle with the callers stack (maybe someone knows more about this?).
Also see return by value faqLeave a comment:
-
For your example, the best thing is probably to return by value directly (i.e "int f()"), since we are dealing with simple data types, which are cheap to copy.
For larger data types, you have to choose between copying or allocating dynamically. Dynamic memory gets tricky since you need to delete it when it is no longer used. The general recommendation is to use classes (constructors and destructors) to manage this. This idiom...Leave a comment:
-
I'm trying to use this methodology to hide the implementation of a DLL library from the client. I came from Linux, trying to learn Win for my new work (a bit backwards, I know :) ).
After doing some research, I've found an equivalent discussion here:
http://www.archivum.in fo/comp.lang.c++/2008-08/msg00431.html
It basically suggests to use virtual inheritance when implementing (or extending) interfaces, and that...Leave a comment:
-
Oh, and the extra "virtual" in AImpl::m1 can be removed, I used that to try JosAH's idea.Leave a comment:
-
That doesn't help. Virtual is inherited and cannot be undone if I remember correctly. I found the answer however. I am sorry to have wasted you time, but it is always when you decide to post a question that you figure it out :)
My example is an example of the "dreaded diamond", see http://www.parashift.com/c++-faq-lit...heritance.html, Where IB and AImpl are the middle-level classes.
In order to solve...Leave a comment:
-
But it does:
Or did I misinterpret multiple inheritance?...Leave a comment:
-
Inherit an implementation
Hi all. I have a scenario where i have two interfaces, IA and IB. IB is an extension of IA. I also have two implementations of the said interfaces, AImpl and BImpl. I let BImpl inherit from AImpl in order to take care of the IA implementation part of IB. I have used this technique before in Java, but in C++ (VS and GCC), it seems like the IB methods inherited from IA needs to be re-implemented in BImpl, inheriting from AImpl does not help. Below...
No activity results to display
Leave a comment: