|
For the first situation...
VCF::String::size_type and string::size_type are not the same type, so neither of the function calls match perfectly. However, both could match using implicit casting rules, hence the ambiguity. If you intend to call the first one, make sure the parameter is string::size_type rather than VCF::String::size_type
For the second situation...
Again, neither overload matches perfectly. You're calling a function called h from a non-const this pointer. The compiler can either implicitly convert this to a const pointer and call the first one, or it can implicitly convert E to an int and call the second one. Neither conversion has preference over the other, so there is an ambiguity. The reason uncommenting the other definition of h works is because it is a perfect match to the function call - there is no conversion required.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you very much for the reply.
Please forget about the VCF::String thing. It was a typo on my side.
Here is a code I made for this question ( it compiles
class Cond
{
public:
typedef std::basic_string<wchar_t> MyString;
Cond() { };
virtual ~Cond(void) { };
Cond( const Cond& other ) {
*this = other;
};
Cond& operator= ( const Cond& other ) {
return *this;
};
bool split( const MyString& s, MyString::size_type* p = NULL );
bool split( MyString& s, const bool& trim );
};
inline
bool Cond::split( const MyString& s, MyString::size_type* p )
{
return true;
}
inline
bool Cond::split( MyString& s, const bool& trim )
{
MyString::size_type p;
if ( split( s, &p ) )
{
s = s.substr( p + 1 );
return true;
}
return false;
}
I get the error message:
1>d:\projs\libraries\vcfex\src\conditions\test.h(51) : error C2666: 'vcfex::Cond::split' : 2 overloads have similar conversions
1> d:\projs\libraries\vcfex\src\conditions\test.h(37): could be 'bool vcfex::Cond::split(vcfex::Cond::MyString &,const bool &)'
1> d:\projs\libraries\vcfex\src\conditions\test.h(36): or 'bool vcfex::Cond::split(const vcfex::Cond::MyString &,stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type *)'
1> with
1> [
1> _CharT=wchar_t,
1> _Traits=stlp_std::char_traits<wchar_t>,
1> _Alloc=stlp_std::allocator<wchar_t>
1> ]
1> while trying to match the argument list '(vcfex::Cond::MyString, stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type *)'
1> with
1> [
1> _CharT=wchar_t,
1> _Traits=stlp_std::char_traits<wchar_t>,
1> _Alloc=stlp_std::allocator<wchar_t>
1> ]
1> note: qualification adjustment (const/volatile) may be causing the ambiguity
It puzzles me that the C++ standard ( or is just vc80 ? ) is asking
me to specify const_cast when intuitively the compiler should
resolve the two overloads 'without effort'.
A comment on this after the next point.
I understand what you say at the second point.
I agree but I am really surprised at the same time.
I always considered a const function just as a way to tell the compler that that function is not going to change the 'this' pointer. So I can certainly use it from a non-const function.
This is true. And what you say seems probably true too.
Now I know that this 'const' specifier may affect the overload resolution too.
So at the end it seems that the standard C++ is treating a difference between
const and non-const at the same level as a difference between types completely
unrelated. This, even when the the const specifier is just there to tell that
what is specified as const will not be changed by the function using that instance
( the 'this' or the MyString instance )
At this point I wonder if this is one limit of the C++ ( IMHO of course ),
or if it really necessary to have it like that.
Cheers,
Marcello
|
|
|
|
|
Marcello wrote: So at the end it seems that the standard C++ is treating a difference betweenconst and non-const at the same level as a difference between types completelyunrelated. This, even when the the const specifier is just there to tell thatwhat is specified as const will not be changed by the function using that instance
const isn't just there to portray information to the compiler, it actually changes the type. So char* and const char* are as different (to the compiler) as char* and float. The difference between the two examples is that the compiler has rules for implicity converting between the first pair, but not the second.
So const on a function definition doesn't just tell the compiler that the function doesn't modify any of the class members, it also changes the way the compiler handles ambiguity resolution, as you've found out - because the type of the function is different. Incidentally, this is also why you can have two identical function signatures that differ only in their "constness" - they are different types.
As for your first point, neither of the functions is an exact match, but both of them can be satisfied by implicit conversion rules, so the call is ambiguous. In this case, the first parameter is a MyString&, which matches the second function but not the first, and the second parameter is a MyString::size_type* which matches the first function, but not the second. However, MyString& can be implicitly converted to const MyString&, and also MyString::size_type* can be implicitly converted to const bool&, and the compiler really has no way of knowing which you intended. It has no choice but to flag the ambiguity. Casting either parameter explicitly should remove the ambiguity.
As you have hinted, the VS2005 compiler is much more strict than previous compilers, but it is behaving according to the standard.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
When transmitting these types of values across networks, do I have to consider endianess, or is the IEEE standard defined identically for every platform?
|
|
|
|
|
You need to consider endianess for float/double as well.
I believe the IEEE standard just applies to the break down of bits for mantessa/exponent, bias, ... for a value in raw byte format.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I have a dialog application and would like to include a logo bitmap...
Anyone know an easy way to accomplish this?
|
|
|
|
|
LCI wrote: ...a logo bitmap...
Are you referring to a splash screen?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Not sure what a splash screen is.
But say i have a bitmap logo of walt Disney for example. I just want to be able to have that come up towards the top of my dialog application.
In addition to this, i would also like to know how to change the MFC logo at the top left to one of my choice .
|
|
|
|
|
You can create your icon and load that icon instead of the default MFC application icon.
Knock out "T" from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
LCI wrote: I just want to be able to have that come up towards the top of my dialog application.
As part of the dialog, like a background?
LCI wrote: In addition to this, i would also like to know how to change the MFC logo at the top left to one of my choice .
The easiest way to solve this is to replace the .ico file in the res folder. Then rebuild your project.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
HICON m_hIcon = (HICON)::LoadImage(AfxGetResourceHandle(),
MAKEINTRESOURCE(IDR_XYZ), IMAGE_ICON,
16, 16, 0);
SetIcon (m_hIcon,false);
ModifyStyleEx(0, WS_EX_APPWINDOW);
This is what you can do to set the icon in the bitmap form on the dialog of your application when IDR_XYZ is the id of the icon you wnt to display
Vision is Always important and so is your ATTITUDE.
Wishes.
Anshuman Dandekar
|
|
|
|
|
You can place a static control on your dialog and call SetBitmap() on it (for MFC) or send it the STM_SETIMAGE message (for Win32)
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
yaa Actually that dialo box is created using Resources or Its
Run Time dialog box
krishna
|
|
|
|
|
|
Hi all,
I have a simple question.
I used
::UpdateWindow(m_hWnd); and ::UpdateWindow(::GetParent(m_hWnd));
in my program so i can see the updated control data on window dlg data. It only works during debug but when the program is not running in debug mode, it freeze and I can no longer see the control updates.
May I please know how to fix that problem so I can see updates on the dialog controls/static.
Thanks
|
|
|
|
|
A common problem in release (vs. debug) builds is the use of uninitialized variables (which contain garbage in release mode and zero in debug mode). Check your code for these. If the problem persists, you'll need to post a code snippet (not your entire app!) in order to get more help.
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
pnpfriend wrote: I used
::UpdateWindow(m_hWnd); and ::UpdateWindow(::GetParent(m_hWnd));
in my program so i can see the updated control data on window dlg data.
What exactly are you updating? UpdateWindow() updates the client area of the specified window (or control) by sending a WM_PAINT message to it. Is that what you are expecting?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Yes.. I think that I am expecting.
I have static control that keep track of num of files in the loop like 1 2 3 4 5 ..
in debug mode, you can see the num of files: increasing as the loop goes on even you open other windows. If it is not running in debug mode, the increasment still as soon as i touch other windows. It looks like the program is freezed but busy working.
Isn't ::UpdateWindow(m_hWnd) solution to this? What am I doing wrong?
Thanks
|
|
|
|
|
pnpfriend wrote: Isn't ::UpdateWindow(m_hWnd) solution to this?
Not hardly.
pnpfriend wrote: What am I doing wrong?
You need to create two CStatic variables, one for each control. Make sure the DoDataExchange() method is correct:
void CMyDialog::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_STATIC1, m_static1);
DDX_Control(pDX, IDC_STATIC2, m_static2);
}Now when you need to update them, simply call SetWindowText() like:
int nCounter = 1;
CString strCounter;
strCounter.Format("%d", nCounter);
m_static1.SetWindowText(strCounter);
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Yes David.
That's what I have.
It gets updated.. But it is just doesn't show it anymore as soon as after I touch or click or focus on other windows.
The dialog looks like it got frozen. It no longer update any controls on dialog. All the dialog controls become alive or awake again when it gets out from the loop.
I thought inorder to prevent from dialog to get looks frozen, I have to call ::UpdateWindow(m_hWnd) to update or redraw the whole dialog including every controls that I have on dialog.
|
|
|
|
|
pnpfriend wrote: It no longer update any controls on dialog. All the dialog controls become alive or awake again when it gets out from the loop.
That indicates that you're doing the work in the main UI thread. The UI is not going to be responsive as a result. You can use SetWindowText() to update the control immediately if that's the only problem you have, otherwise move the loop to a worker thread.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Thanks
I had changed to worker thread.
it is working.
thanks.
|
|
|
|
|
thanks for your answers.
What I meant is:If there is a simple way like in Visual Basic where you right click at the properties of the button and you can change the back color the color you want.
Is there some thing like this in visual studio C++?
thanks again
|
|
|
|
|
|
There is nothing like what want in VC++,we have to write it
from Scratch.
Fly Like An Eagle With MIGHTY POWER.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
