I'm not sure the first option would be as afficient as the second one: the compiler may naively construct a temporary object and then copy its content to the array item (i.e. another freshly allocated object). On the other hand, with the second approach you have to take care of memory clean up (and someone as already pointed out, you may incour in aliasing problems).
And, of course, Nemanja's observations hold true.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
I wouldn't store raw pointers in a collection. As a general rule always keep some kind of object in there - either what you're trying to store or some reference like object. If you keep raw pointers in there you'll end up with exception safety and potential aliasing problems.
So the rule of thumb I use is: If you want to maintain a collection of objects of a single type then store them by value. If you want to maintain a collection of objects and access them polymorphically store something like std::shared_ptr or std::unique_ptr.
PS: One final point - using CArray is a bad idea - it breaks fairly often when using non-POD objects (it uses a really naive internal copy based on memcpy) and is really conservative when it has to grow.
Me think it depend on the object itself, not the collection.
If the object (class) can be copied with ease (performance issue) than it can be easier to just use the first option; if the object is complex, then it might be more optimal to use a pointers in the collection.
I personally use pointers (but with STL collections, not MFC collections).
I don't know if rvalue reference (VS2010 c++0x) can be used with CArray (this enable the "move" semantic that will "move" objects instead of copiyng them); but probably the MFC collection are being deprecated in the later VS releases in favor of STL (but that'nother whole story).
If the size of the type is comparable to a pointer, then it doesn't matter. But if your using larger types, you will probably want to utilize...
It's been a while since I examined the MFC source code but I found that it performed full memory copies when resizing (NOTE: this might different for the various MFC versions). This full memory copy would be negligible if your storing pointers.
Also, I think when you are passing in an object for CArray a separate copy is made of the object (when storing the element in the array) regardless of whether you pass it in by value or by reference. This would be some more overhead to consider.
Hi. I'm trying to save a web page as bitmap. I've created a simple Browser Helper Object but now I'm stuck at how to convert the web page to image. I've tried creating a bitmap screenshot of the browser but that didn't work with pages that require scrolling.
Writing a simple Win32 Console App to read the header of a WAV file.
Aim was to test my understanding of File IO, but seem to have uncovered a problem with my understanding of strings instead when I got some unexpected output.
The code below results in output such as: RIFF
If char ch defines ch as a character array of size 4, why does cout << ch appear to output additional bytes beyond the end of ch?
I have a SDI app using FormView that's not resizable but will have a large and small size. I would like to create small and large dialogs and then have the view display the correct dialog depending on user choice. I don't want to use multiple views because I don't want to recode handlers, etc. My plan is to i.e. have button ID_OK1 in small dialog and button ID_OK2 in large dialog both to to OnOK() so my code only has to be written once. Any ideas would be appreciated. Thanks,
I was thinking about doing resizing but I have another app that allows resizing and it was a bit tedious to change control sizes, rearrange based on the new window size and update font sizes. I was hoping to layout 2 dialogs in the resource editor and then just switch between the two. Is there an easier way to resize controls instead of calc window size, scale controls then move to new relative positions?
So at run time I can set View_IDD_TO_USE to the resource for IDD_DIALOG1 or IDD_DIALOG2. The form view then gets created with whichever of the resources I choose. I create the event handlers in the view, i.e. OnOK(). The controls in each dialog need to be the same including names so that when the view creates the handlers they can be mapped, i.e. there must be a control named ID_OK on each dialog so the view can correctly map ID_OK to OnOK().
That means no duplicated code, only two dialogs which doesn't add to much overhead. This works great for what I'm doing.
Thanks to Scott McPhillips for the direction.
Last Visit: 12-Aug-20 3:11 Last Update: 12-Aug-20 3:11