C / C++ / MFC

5-Jan-11 10:12

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

CPallini5-Jan-11 10:36

CPallini

5-Jan-11 10:36

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.
Smile | :)

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]

David Crow5-Jan-11 10:50

5-Jan-11 10:50

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?

CPallini5-Jan-11 11:05

CPallini

5-Jan-11 11:05

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:

// option 1
CArray <Point , Point &> m_arr;
m_arr.Add( CPoint(10,20));
..

// option 2
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]

Smile | :)

David Crow5-Jan-11 17:22

5-Jan-11 17:22

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.

CPallini6-Jan-11 3:59

CPallini

6-Jan-11 3:59

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.

Aescleal5-Jan-11 11:37

Aescleal

5-Jan-11 11:37

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.

Maximilien6-Jan-11 1:08

Maximilien

6-Jan-11 1:08

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.

Nemanja Trifunovic6-Jan-11 3:52

Nemanja Trifunovic

6-Jan-11 3:52

"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.

utf8-cpp

bob169726-Jan-11 11:24

bob16972

6-Jan-11 11:24

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.

Saving a web page as image

bob169726-Jan-11 11:15

bob16972

6-Jan-11 11:15

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.

eight5-Jan-11 5:56

eight

5-Jan-11 5:56

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.

Re: Saving a web page as image

RaviRanjanKr5-Jan-11 6:39

RaviRanjanKr

5-Jan-11 6:39

This Link1[^] and Link2[^] may help you.

Re: Saving a web page as image

eight5-Jan-11 15:04

eight

5-Jan-11 15:04

Thanks Ravi

simple string problem - Noob

Paul Hasler5-Jan-11 3:37

Paul Hasler

5-Jan-11 3:37

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. Blush | :O

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";

}

User 74293385-Jan-11 3:50

User 7429338

5-Jan-11 3:50

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.

Paul Hasler5-Jan-11 4:00

Paul Hasler

5-Jan-11 4:00

Thanks Thaddeus.
Problem solved!

guyee5-Jan-11 3:51

guyee

5-Jan-11 3:51

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.

fatal error LNK1561 entry point must be defined

Paul Hasler5-Jan-11 4:01

Paul Hasler

5-Jan-11 4:01

Thanks guyee.
Problem solved!

Joao Araujo5-Jan-11 3:27

Joao Araujo

5-Jan-11 3:27

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)

Re: fatal error LNK1561 entry point must be defined

David Crow5-Jan-11 4:57