C / C++ / MFC

Re: Overloading cast & assignment not enough for ==?

7-Sep-09 11:22

I wrote a generic template-based identifier class but am getting compilation errors with the is-equal operator. Anybody know how to fix this? The following code is a distillation of the problem. I get compilation errors for the conditional expressions within the assert()s. The error text in the comments is paraphrased from Visual 2008 C++ Express. I don't get these errors when the core type and the literal are an integral type, e.g., int. I assume this is due to implicit integral conversions.

#include <iostream>
#include <assert.h>

using namespace std;

class Name
{
public:
	Name(const string t_) : t(t_) { }
	Name() { }
	Name(const Name & t_) : t(t_.t) { }
	Name & operator=(const string & rhs) { t = rhs; return *this; }
	operator const string & () const { return t; }
	operator string & () { return t; }
private:
	string t;
};

int main()
{
	Name n1 = "bananas", n2 = "bananas";
	assert(n1 == n2);	// Couldn't deduce template arg for string from Name
	assert(n1 == "bananas");	// No operator found for LH operand of type Name
}

I'm thinking I need to overload the == operator. I tried that but ran into even more problems.

FWIW, my identifier class is similar to BOOST_STRONG_TYPEDEF() except that I want to be able to use the core type (possibly with implicit conversion) as an initializer to the derived type and as an argument to a derived-type parameter. I also want to use the derived type as an initializer to the core type. Here's an example of that:

BOOST_STRONG_TYPEDEF(string, S)
void f(S s) { }
int main() { S s = "abc"; f("def"); string str = s; }

Thanks!

CPallini7-Sep-09 11:54

CPallini

7-Sep-09 11:54

dplong wrote:
I'm thinking I need to overload the == operator. I tried that but ran into even more problems.

Well I think you need. BTW what are the problems?
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]

Re: Overloading cast & assignment not enough for ==?

dplong7-Sep-09 12:30

Re: Overloading cast & assignment not enough for ==?

7-Sep-09 12:30

Oh, sorry:

"I get compilation errors for the conditional expressions within the assert()s. The error text in the comments is paraphrased from Visual 2008 C++ Express."

Basically, how do I get rid of those errors? I would like to be able to

1. compare two instances of my Name class for equality and

2. compare an instance of Name with an instance of its core type, string.

Like pointers, I only need to cast, assign, and compare for equality/inequality. For example, it doesn't make sense to add identifiers, like adding GUIDs.

Stuart Dootson7-Sep-09 14:41

Stuart Dootson

7-Sep-09 14:41

Think you'll find it useful to add a Name constructor that takes a const char*. Reason is that C++ won't do 2 implicit conversions to get a function/operator to match - the 2 implicit conversions in this case being const char* -> string -> Name. That also permits operator== (which you will need to define - it's not one of the standard compiler provided operators) between a Name and a string literal:

#include <iostream>
#include <assert.h>

using namespace std;

class Name
{
public:
	Name(const char* t_) : t(t_) { }
	Name(const string& t_) : t(t_) { }
	Name() { }
	Name(const Name & t_) : t(t_.t) { }
	Name & operator=(const string & rhs) { t = rhs; return *this; }
	operator const string & () const { return t; }
	operator string & () { return t; }
private:
	string t;
};
bool operator==(const Name& left, const Name& right) { return string(left)==string(right); }

int main()
{
	Name n1 = "bananas", n2 = "bananas";
	assert(n1 == n2);	// Couldn't deduce template arg for string from Name
	assert(n1 == "bananas");	// No operator found for LH operand of type Name
} 

<div class="ForumSig">Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p</div>

Re: Overloading cast & assignment not enough for ==? [modified]

dplong7-Sep-09 18:39

Why do functions in the C library have short names?

7-Sep-09 18:39

Thanks a bunch, Stuart. I realized I had a few more situations to take into consideration, so this is the class now. It works like a charm. Thumbs Up | :thumbsup:

#include <string>
#include <assert.h>

using namespace std;

class Name
{
public:
	Name() { }
	Name(const string & t_) : t(t_) { }
	Name(const char * t_) : t(t_) { }
	Name & operator=(const string & rhs) { t = rhs; return *this; }
	Name & operator=(const char * rhs) { t = rhs; return *this; }
	friend bool operator==(const Name & lhs, const Name & rhs) { return lhs.t == rhs.t; }
	operator const string & () const { return t; }
	operator string & () { return t; }
private:
	string t;
};

int main()
{
	char arr[] = "bananas";
	char *arrP = arr;
	string s = "oranges";
	Name nn1 = s;
	Name n0 = string("apples");
	n0 = s;
	n0 = arr;
	n0 = arrP;
	nn1 = n0;
	Name nn2 = Name(nn1);
	Name n1 = "bananas", n2 = "bananas";
	assert(n1 == n2);
	assert(n1 == string("bananas"));
	assert(n1 == arr);
	assert(n1 == arrP);
	assert(n1 == "bananas");
}

This solution creates another problem for me, though. I was using the following template so that this behavior could be defined for any class, e.g., int, unsigned, and string:

template <class T, class D> class IdTemplate {
public:
	IdTemplate() { }
	IdTemplate(const T t_) : t(t_) { }
	IdTemplate & operator=(const T & rhs) { t = rhs; return *this; }
	friend bool operator==(const IdTemplate & lhs, const IdTemplate & rhs) { return lhs.t == rhs.t; }
	operator T & () { return t; }
	operator const T & () const { return t; }
private:
	T t;
};

However, the doubling up of the constructor and assignment operator for both string and char * makes this rather difficult because, for example, int doesn't have to consider a "shadow" type like char *. Any ideas on how to generalize the solution so that it may be represented with a template?

modified on Tuesday, September 8, 2009 1:05 AM

0x3c07-Sep-09 10:58

0x3c0

7-Sep-09 10:58

This is probably a really simple question, but I can't get my head around it. The C library that is linked with most applications uses functions like memcpy, strcat and memset. These names all seem very counter-intuitive, in comparison to CopyMemory, ConcatenateStrings and SetMemory. Likewise for calloc when compared to AllocateCleanMemory. Why is this?

My first thought was that this preserved stack space, but then I realised that the stack holds addresses, instead of method names. The only other possibility that I can think of is that C programmers dislike excessive typing, and so prefer shorter method names. Is this the reason why, or is there a technical constraint on method name length?

OSDev

Re: Why do functions in the C library have short names?

CPallini7-Sep-09 11:13

CPallini

7-Sep-09 11:13

Computafreak wrote:
The only other possibility that I can think of is that C programmers dislike excessive typing

That's true.

Computafreak wrote:
Is this the reason why, or is there a technical constraint on method name length?

Well, the linker deals also with function (methods have no place in C programmer's mind) names.

Another reason maybe historical: when the C library was firstly developed, Microsoft wasn't around... (More seriously there wasn't a plethora of functions to remember and low risk of name collisions, so, I suppose, using short names was reasonable).

BTW: C library functions have too long names for Klingon Developers.
Smile | :)

Re: Why do functions in the C library have short names?

dplong7-Sep-09 11:32

Re: Why do functions in the C library have short names?

7-Sep-09 11:32

It probably was not intentional by K&R and early C developers, but short function names in the C standard library make sense. Like Huffman coding, the length of words that humans use are inversely proportional to their frequency. For example, "I" and "ventriloquist." Since standard-library functions are used more than the programmer's own functions, they are shorter.

Richard MacCutchan7-Sep-09 11:33

Richard MacCutchan

7-Sep-09 11:33

The original C library was developed in the early days of UNIX when computers were slow and had very little storage to work with, and input/output devices that operated at fairly low speeds. In order to conserve space most library functions were named in six characters or less to prevent the compilers from taking forever to turn source into executable code. Because of that history many of the original names are still in existence.

Re: Why do functions in the C library have short names?

Stuart Dootson7-Sep-09 14:45

Stuart Dootson

7-Sep-09 14:45

C was developed as the system programming language for Unix. The C run-time library functions have LONG names compared to Unix shell commands....ls, rm, ps etc

In addition, I suspect there may have been a desire to keep identifier names short - when doing string comparisons, the worst-case time is O(N), so the smaller you make N (the string length in this case), the better. Remember, in 1970, a computer had much, much less processing power and storage bandwidth than your phone has these days...

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

ID_FILE_NEW causes application crashed [modified]

transoft7-Sep-09 10:58

7-Sep-09 10:58

Hi
I want to run a dialog box doing some setting before I open a new MDI child. I did following:

BOOL CMyApp::InitInstance()
{
....

    // Don't display a new MDI child window during startup
    if( cmdInfo.m_nShellCommand == CCommandLineInfo::FileNew )
        cmdInfo.m_nShellCommand = CCommandLineInfo::FileNothing;
....
	pMainFrame->ShowWindow(m_nCmdShow);
	pMainFrame->UpdateWindow();

    PostMessage(pMainFrame->GetSafeHwnd(), WM_COMMAND, ID_FILE_NEW_SETING, (LPARAM)0);

	return TRUE;
}

void CMainFrame::CMFileNewSetting()
{
////run dialog
   PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
.....
}

The code runs OK while I try to launch the app within the VisualStudio. But when I tried to run the App.exe, App.exe crashed. After debugging, I found out that "PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);" cause the App.exe crashed.

How can I correct this problem?

Best regards,

modified on Monday, September 7, 2009 5:13 PM

Richard MacCutchan7-Sep-09 11:36

Richard MacCutchan

7-Sep-09 11:36

transoft wrote:
PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);

You need to post the message to a HWND handle. Also note that PostMessage, of itself, does not run a dialog.

transoft7-Sep-09 16:58

7-Sep-09 16:58

Please note that:

void CMainFrame::CMFileNewSetting()
{
////run dialog
   PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
.....
}

"PostMessage" will post the message to "this" HWND.

This code runs OK when I run it in VisualStudio. But it crashed When I ran the app.exe.

Thanks

Richard MacCutchan7-Sep-09 23:25

Richard MacCutchan

7-Sep-09 23:25

The code extracts seem to be different with every message you post. What exactly is the code that you think causes the crash (i.e. how do you know it is the PostMessage() call), and what are the values of the various parameters that are being processed. Are you sure that the code you run through the debugger is the same as in the app.exe that crashes?

SandipG 7-Sep-09 21:39

SandipG

7-Sep-09 21:39

transoft wrote:
void CMainFrame::CMFileNewSetting()
{
////run dialog
PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
.....
}

Probably you should handle WPARAM and LPARAM for the above message even if you do not need them.
This will cause crash in release builds. I am not sure if app.exe is in release build. I hope it helps.

[edit]
I missed following

transoft wrote:
After debugging, I found out that "PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);" cause the App.exe crashed.

You said you could run the exe properly using VS then how come you were able to reproduce the problem in VS?
Confused | :confused:

[/edit]

Regards,
Sandip.

transoft8-Sep-09 2:12

8-Sep-09 2:12

It would not crash in VS. I can not find where the problem code located.

The debug version of code (app.exe) will crash also if running outside VS.

I think might be the location of my postmessage( ...,ID_FILE_NEW, ); where cause the problem.

Thanks,

David Crow8-Sep-09 3:31

David Crow

8-Sep-09 3:31

transoft wrote:
I want to run a dialog box doing some setting before I open a new MDI child.

This sounds like a splash screen.

transoft wrote:
After debugging, I found out that "PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);" cause the App.exe crashed.

What is a crash?

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"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

transoft8-Sep-09 3:50

8-Sep-09 3:50

Hi
The App.exe did not give me any hints. When I tried to use JIT debugger to find the bug, JIT debugger seems hanging there. It looks like stuck in a never end loop.
I tried following coide

BOOL CSignApp::InitInstance()
{

......
	// The main window has been initialized, so show and update it.
	pMainFrame->ShowWindow(m_nCmdShow);
	pMainFrame->UpdateWindow();

	MessageBox(NULL, "test", "test", IDOK);

    PostMessage(pMainFrame->;GetSafeHwnd(), WM_COMMAND, ID_FILE_NEW, (LPARAM)0);


	return TRUE;
}

I did two tests. I put "MessageBox(NULL, "test", "test", IDOK);" before and after "PostMessage(pMainFrame->GetSafeHwnd(), WM_COMMAND, ID_FILE_NEW, (LPARAM)0);"

If the MessageBox was added before PostMessage, "MessageBox" will show. After will not.

Where is the good place for sending "ID_FILE_NEW" message?

Best regards,

David Crow8-Sep-09 3:55

David Crow

8-Sep-09 3:55

Since it blocks the message pump, using MessageBox() is rarely a good thing to use for debugging. Use TRACE() instead.

transoft8-Sep-09 4:24