C / C++ / MFC

Cedric Moonen10-Dec-07 21:00

Cedric Moonen

10-Dec-07 21:00

I will explain you with an example: suppose you are writing a string class (CMyString). This class has a constructor that accepts a char array:

class CMyString
{
  CMyString(const char* pBuffer);
};

Suppose now you have a function that accepts a CMyString as parameter:

void MyFunction(const CMyString& myString)
{
...
}

You can perfectly do something like that in your code:

MyFunction("TestString");

Because of your constructor that accepts a char array, an object of CMyString will be created by calling the constructor. This is an implicit conversion, and sometimes, you do not want that to happen. In that case, you should use the explicit keyword to make sure the user knows what he is doing. He will then need to explicitely create the object when calling the function:

MyFunction(CMyString("TestString"));

Cédric Moonen
Software developer

Charting control [v1.2]

George_George10-Dec-07 21:10

10-Dec-07 21:10

Thanks Cédric Moonen,

Any practical benefits we could get if we use explicit keyword?

regards,
George

Cedric Moonen10-Dec-07 21:17

Cedric Moonen

10-Dec-07 21:17

If you create a library, sometimes you want to avoid 'confusion' by disallowing implicit conversions for the end user (like the one I showed you before).

Cédric Moonen
Software developer

Charting control [v1.2]

George_George10-Dec-07 21:33

10-Dec-07 21:33

Cool, thanks Cédric!

But from your sample, I can not see why implicit conversion will cause any confusions. It brings flexibility I think. Smile | :)

Could you point out what confusion do you mean please?

regards,
George

Nelek10-Dec-07 23:36

Nelek

10-Dec-07 23:36

It is quite clear (or I think so)

Imagine that you derive your CMyString from CString and it can receive a CString as entry parameter, but you have added some funcionality to the derived class by overloading. If you use:

CString strTemp = otherClass.strParameter;
MyFunction (strTemp);

The compiler won't maybe complain, but in the release version you have a bad running result because you are using the added methode inside MyFunction and the CString doesn't have it.

If you force the user by declaring explicit, then the compiler should complain. So it will be needed to use insteads:

CString strTemp = otherClass.strParameter;
MyFunction (CMyString (strTemp));

MyFunction (CMyString (otherClass.strParameter));

you will use the data that are comming from the string of otherClass.strParameter but you will be able to use your overloaded/added methodes in CMyString.

The use of that, as cedric already said, Libraries, Dlls that are going to be used by anyone (in example).

Or have I understood you false, cedric?

Greetings.
--------
M.D.V. Wink | ;)

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

George_George11-Dec-07 0:14

11-Dec-07 0:14

Hi Nelek,

I do not quite agree with you in the sample. I think it is a coding error in MyFunction, which it should check (e.g. dynamic cast?) the type should be CMyString other than CString, any comments?

regards,
George

Nelek11-Dec-07 1:23

Nelek

11-Dec-07 1:23

You just asked for a practical use. I gave you one. if it is the best way to do it or not... I'm not enough skilled to say it.

But the fact is that Cedrics explanation is very good (at least in my opinion, i didn't know it before). You can always use google to try to find usements and/or examples.

BTW there is so much possibilities to do something as programmers in the world. What you find super is maybe nto so good for other people

Greetings.
--------
M.D.V. Wink | ;)

George_George11-Dec-07 1:41

11-Dec-07 1:41

Thanks for your help, Nelek!

regards,
George

how to use MFC data Types in win 32 dll

Nelek10-Dec-07 23:27

Nelek

10-Dec-07 23:27

Very simple but very good explained, thanks for

Greetings.
--------
M.D.V. Wink | ;)

kmani_soft10-Dec-07 18:57

kmani_soft

10-Dec-07 18:57

hi ....

i have developed one win 32 dll application ..in that application
i want to use CString how can i use this ...tell me how to use the MFC data types with in Win 32 Dll Application

i also included #include "afxcoll.h"

how can i use CString datatype in win32 dll

Thanks in advance....

Nothing is Impossible...

Re: how to use MFC data Types in win 32 dll

CPallini10-Dec-07 22:37

Re: how to use MFC data Types in win 32 dll

10-Dec-07 22:37

kmani_soft wrote:
i want to use CString how can i use this ...tell me how to use the MFC data types with in Win 32 Dll Application

Why?

use std::string instead.

Anyway, have a look at http://msdn2.microsoft.com/en-us/library/5bzxfsea(VS.80).aspx[^]
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.

Mark Salsbery11-Dec-07 6:23

Mark Salsbery

11-Dec-07 6:23

CStringT is no longer just part of MFC. Just use the appropriate
header file:

Header       Use for
 
cstringt.h   MFC-only string objects
atlstr.h     Non-MFC string objects

Mark Salsbery
Microsoft MVP - Visual C++

Java | [Coffee]

string array v.s. int array

George_George10-Dec-07 18:51

10-Dec-07 18:51

Hello everyone,

I find strange result in the following program.

1. For string array, dereferencing it will result in the string itself, but for int array, dereferencing it will result in the address of the array;

2. When dereferencing it twice (operator **), why the result is always the 1st element in both string array sample and int array sample?

int main()

{
	wchar_t me[] = L"Hello World \n";
	wchar_t (*me2_ptr)[14] = &me;
	wcout << *me2_ptr << endl;	// output Hello World
	wcout << **me2_ptr << endl; // output H

	int values[] = { 10, 20, 30, 40, 55, 60, 70, 80, 90, 100 };
	int (*pval)[10] = &values;
	wcout << *pval << endl;  // output 0x0017f6f0
	wcout << **pval << endl; // output 10

	return 0;
}

thanks in advance,
George

Doc Lobster10-Dec-07 22:10

Doc Lobster

10-Dec-07 22:10

Hi,

I'm not exactly sure why you are using wchar_t (*me2_ptr)[14] = &me; and its equivalent for the int.

However, look at things like this:

me2_ptr - is a pointer on a pointer on a wchar_t
*me2_ptr - is a pointer on a wchar_t
**me2_ptr - is a wchar_t

pval - is a pointer on a pointer on a int
*pval - is a pointer on a int
**pval is a int

If you call operator<< on a pointer on a wchar_t it assumes its target is a c-string and delivers the string itself. If you call operator<< on a pointer on a int it just delivers the value of the pointer. This is just the way operator<< is implemented.

George_George10-Dec-07 22:33

10-Dec-07 22:33

Thanks Doc,

Why *me2_ptr - is a pointer on a pointer on a wchar_t*? I think &me is a pointer to wchar_t, right?

Since in the following code, you can see &me is the same as me,

int main()
{
	char buf[] = "Hello World \n";

	_ASSERT (buf == &buf);

	return 0;
}

regards,
George

CPallini10-Dec-07 22:21

10-Dec-07 22:21

The depicted behavior is not so strange...

George_George wrote:
1. For string array, dereferencing it will result in the string itself, but for int array, dereferencing it will result in the address of the array;

In fact the behavior is quite similar: the name (or the address-of operator & applied on the name, remembering past posts... Smile | :)

) of the int array returns the address of the memory containing the integer values as well the name of the character array returns the address of the memory containing the character values;
you find a noticeable difference in the output only because a (C-like) string is nothing more than the pointer to the memory holding the zero-terminated character sequence, hence whenever wcout finds a (wide) character pointer, it prints the characters belonging to the pointed memory.

George_George wrote:
When dereferencing it twice (operator **), why the result is always the 1st element in both string array sample and int array sample?

Again, nothing strange here. Given a int pointer, say int *p, deferencing it means: "take the content of the pointed memory", namely the integer value at address p (that coincide with the first int element of the array). The same point applies to the character array.

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.

George_George10-Dec-07 22:40

Re: string array v.s. int array [modified]

10-Dec-07 22:40

Hi CPallini,

What makes me confused is, in my test program before, the address of a string array should be the same as the string array itself. For example below, buf is the same as &buf.

int main()
{
	char buf[] = "Hello World \n";

	_ASSERT (buf == &buf);

	return 0;
}

I think in the code posted in the question, me2_ptr = &me, and it is the same as me, without dereferencing it, if we simply wcout << me2_ptr, result should be the same as wcount << me? Why we need to dereferencing it by operator * in order to get the same output of wcout << me?

regards,
George

CPallini10-Dec-07 22:51

10-Dec-07 22:51

Because you defined (correctly) it as pointer to an array address (i.e. another pointer), i.e.
*me2_ptr contains the address of me (the same address returned by &me).
Hence me2_ptr isn't a pointer to w_chars, but instead a pointer to a pointer of w_charss (added: that turns out to be the same address...).

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.

modified on Tuesday, December 11, 2007 5:41:54 AM

George_George10-Dec-07 23:15

10-Dec-07 23:15

Hi CPallini,

If you have Visual Studio at hand, you can debug my sample program, and you can find that me is the same as me2_ptr (you can watch it), so me2_ptr is the same as me, I do not know why *me2_ptr is also the same as me?

regards,
George

CPallini10-Dec-07 23:41

10-Dec-07 23:41

You're right. *me2_ptr and me2_ptr both hold the same address (but are different types, this way wcout behaves differently on them), this probably is related to the fact that dereferencing an array name (i.e. *me2_ptr) should return the same address returned by the array name itself.

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.

George_George11-Dec-07 1:54

11-Dec-07 1:54

Thanks CPallini,

I think you mean,

1. *me2_ptr is value of array type, and wcout is overloaded to print out the string array;
2. me2_ptr is address of array type, and wcount will print the address of array.

Right?

regards,
George

CPallini11-Dec-07 2:11

11-Dec-07 2:11

Technically the ostream extraction operator << is overloaded, but, poorly speaking the answer is yes.
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.

Iain Clarke, Warrior Programmer

Iain Clarke, Warrior Programmer11-Dec-07 6:08

11-Dec-07 6:08

Cpallini has already explained at some length (to me too!) how the address of an array has the same value for convenience to printf (and it's relations).

The two bits of code you've shown do the same thing with derefencing. The only difference is that the wcout is clever enough to go "oh, I won't give a number, I'll give a lump of text - aren't I helpful?".

The short answer to question 2
BECAUSE.

Longer answer...
Because it has been defined that way by people cleverer than us.

Is this feature causing you problems?

Iain.

George_George11-Dec-07 21:14