|
Regarding CArray, is it "better" to store an actual object in the collection or a pointer to an object? For the former, I'd have:
typedef CArray<CGroupInfo, CGroupInfo &> m_arrGroupInfo; and for the latter, I'd have:
typedef CArray<CGroupInfo *, CGroupInfo *> m_arrGroupInfo; At first glance, they seem analogous except I would create the object (i.e., new) in the second instance and CArray would internally do it in the first.
Thanks.
- DC
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
It depends on your needs, I believe the former makes a copy of the passed object (hence you may have a performance penalty) whilst, the latter one delegates to you the memory handling.
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
[My articles]
|
|
|
|
|
CPallini wrote: I believe the former makes a copy of the passed object...
Which the latter would too since I would be newing the object (and assigning values to its members). Correct?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
The latter doesn't make copies. It takes bare pointers. Object allocation is an 'external affair'.
[update]
Maybe I haven't got your scenario: would you use them this way:
CArray <Point , Point &> m_arr;
m_arr.Add( CPoint(10,20));
..
CArray <Point *, Point *> m_arr;
m_arr.Add( new CPoint(10,20));
..
?
For this scenario I would go for option 1 (so that the CArray takes care of object cleanup).
[/update]
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
[My articles]
|
|
|
|
|
CPallini wrote: [update]
Maybe I haven't got your scenario: would you use them this way:
// option 1CArray <point ,="" point="" &=""> m_arr;m_arr.Add( CPoint(10,20));..
// option 2CArray <point *,="" point="" *=""> m_arr;m_arr.Add( new CPoint(10,20));..
?
I've used both. I just can't seem to see a difference, or benefit, of one over the other.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
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
[My articles]
|
|
|
|
|
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.
Cheers,
Ash
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).
M.
Watched code never compiles.
|
|
|
|
|
"Better" really depends on your particular situation. If CGroupInfo is a polymorphic type you need to store pointers. If it is a small concrete type, prefer storing objects.
In any case, CArray is a bad idea. std::vector is a better alternative.
|
|
|
|
|
Just out of curiousity, do you mix MFC with std::vector.
I ask because on occasion, I have found hosting a vector as a member of a class sometimes causes false memory leak notifications via the elaborate MFC debug code.
|
|
|
|
|
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...
CTypedPtrArray
CTypedPtrList
CTypedPtrMap
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.
Please help.
|
|
|
|
|
|
|
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
RIFF╠╠╠╠¿ ↕
If char ch[4] defines ch as a character array of size 4, why does cout << ch appear to output additional bytes beyond the end of ch?
int main(int argc, char *argv[])
{
char ch[4];
register int i;
if(argc!=2)
{
cout << "Usage: WavInfo <filename>\n";
return 1;
}
ifstream in(argv[1], ios::in | ios::binary);
if(!in)
{
cout << "Cannot open file.\n";
return 1;
}
in.read(ch,4);
for(i=0; i<4; i++){cout << ch[i];}
cout << "\n";
cout << ch << "\n";
}
|
|
|
|
|
C/C++ use the null-character to indicate the end of a string, so in memory, the string would be stored as 'R' 'I' 'F' 'F' '\0'.
So to store 4 characters, you need a string char ch[5];
modified 13-Sep-18 21:01pm.
|
|
|
|
|
Thanks Thaddeus.
Problem solved!
|
|
|
|
|
Strings have to be zero terminated.
Replace
char ch[4];
with
char ch[5];
ch[4] = 0;
or something similar to have a zero after the string data.
|
|
|
|
|
Thanks guyee.
Problem solved!
|
|
|
|
|
MVS 2010 – Errors – fatal error LNK1561: entry point must be defined
- Reason:
- You are using MFC and following linker option is missing: /SUBSYSTEM:WINDOWS
- Solution 1:
- If project is created as Win32 Project this linker option will be automaticly set:
- File – New Project ... – Visual C++ – Win32 – Win32 Project
- Solution 2:
- If projec is created as General Empty Project this linker option needs to be manually added:
- RC on ProjectName – Properties – Configuration Properties – Linker – Coommand Line
- Additional Options: /SUBSYSTEM:WINDOWS
OR LET IDE TO DO THIS:
In Visual Studio IDE enter:
Project -> Properties -> Linker -> System -> SubSystem
Now choose in option combox: Windows(/SUBSYSTEM:WINDOWS)
|
|
|
|
|
Is there a question embedded in here someplace? 
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi all,
i want to know currently how many threads running in my applcation?
please tell me what api or function use for this?
or please tell me how can i do this.
thanks in advance.
|
|
|
|
|
See here[^].
You can use the code from the link, just need to replace the printf call with conditional check - if the process ID matches your own process ID, obtained via GetCurrentProcessId[^].
modified on Wednesday, January 5, 2011 6:13 AM
|
|
|
|
|
|
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,
John
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
