|
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.
|
|
|
|
|
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);
assert(n1 == "bananas");
}
<div class="ForumSig">Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p</div>
|
|
|
|
|
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. 
#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
|
|
|
|
|
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?
|
|
|
|
|
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.
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]
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Hi
I want to run a dialog box doing some setting before I open a new MDI child. I did following:
BOOL CMyApp::InitInstance()
{
....
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()
{
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
|
|
|
|
|
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.
|
|
|
|
|
Please note that:
void CMainFrame::CMFileNewSetting()
{
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
|
|
|
|
|
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?
|
|
|
|
|
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?
[/edit]
Regards,
Sandip.
|
|
|
|
|
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,
|
|
|
|
|
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
|
|
|
|
|
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()
{
......
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,
|
|
|
|
|
Since it blocks the message pump, using MessageBox() is rarely a good thing to use for debugging. Use TRACE() instead.
"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
|
|
|
|
|
OK, I will use TRACE(). Thanks.
The bug is not from "MessageBox". Even I deleted the "MessageBox". It crashed also.
Thanks,
|
|
|
|
|
transoft wrote: The bug is not from "MessageBox". Even I deleted the "MessageBox". It crashed also.
I'm aware of that. The suggestion was not meant to resolve your problem.
"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
|
|
|
|
|
I used wizard to create a new MDI project and added same things in the new MDI. It works just fine.
I think I did something wrong before I PostMessage.
It is very hard to find this type of bugs.
Thanks,
modified on Tuesday, September 8, 2009 10:45 AM
|
|
|
|
|
Is it possible to resize an image using something like GDI+ without using MFC or Win32. If so does anyone have any examples?
Thanks in advance
|
|
|
|
|
GeeBru wrote: Is it possible to resize an image using something like GDI+ without using MFC or Win32.
Well since GDI+ is part of Win32 then I think the answer is probably 'No!'. Maybe it would be better to try and explain what you are trying to achieve, and why.
|
|
|
|
|
Ah silly me then  thanks for the quick reply.
What I need to do is shrink a JPG by calling a C function as I have a different application that calls C functions from within a DLL and I'm unsure how to go about creating the function. As the application cannot pass windows handles etc then I wondered if GDI+ could do it without needing that kind of thing.
Thanks.
|
|
|
|
|
I'm not sure I understand how the pieces fit together in your description here, perhaps you could elaborate?
However, GDI+ operates on DeviceContexts rather than Windows, so as long as you can instantiate a DC you can do all the GDI+ing necessary. Whether you do this in C, C++, C# or any other language is largely your own choice.
GeeBru wrote: As the application cannot pass windows handles
Any reason why not?
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
