|
bool is an proper type and can be used to overload functions the way you want.
Looks like Microsoft is wrong. Again.
he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)
Awasu v0.4a[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Are you sure you're not doing a Unicode build?
the thingies above resove fine (for me) when TCHAR is actually a char.
However, when TCHAR resolves to unsigned short, it's of course ambigous (should it expand to 16 bit, or reduce to one?)
Those who not hear the music think the dancers are mad. [sighist] [Agile Programming]
|
|
|
|
|
Joe Woodbury wrote:
Once again I have gotten bitten by VC++ treating the "bool" type as the rough equivilant of "void".
That is not entirely correct I believe, and depending on what TCHAR expands to it might actually be that the VC compiler (even that you don't state version) might actually be correct.
If you are compiling the displayed code as Unicode, meaning TCHAR expands to either the C++ required type wchar_t, or the MS invented undigned short (this depends upon both compiler version and compiler flags!), there would be an equally bad match for both bool and unsigned char for the char literal ','.
|
|
|
|
|
I've identified the problem.
Since the character is not defined as a wchar_t (either with L or _T), in UNICODE mode, it is still a char. The compiler must then fit the plain char with the "best" match, but [in my tests] never considers wchar_t if there is an alternate available. It will even pick int over wchar_t.
In my opinion, bool should never be selected. Even if there were only one function with a bool argument, I want an error to be generated. (For example, given void function(bool isValid);, function(1) should generate an error.)
char should pick wchar_t before to int, or at least a switch should be available to force this behavior.
|
|
|
|
|
I would imagine Christian would have a good idea which direction the compiler should try first. He seems to have researched this type of stuff. Interesting question.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
*grin* I actually answered and then read your answer, expecting you to have said the same, but leaping in anyhow, because Microsoft are correct. char to int is guarenteed in the standard. You can do this:
char a = 65;
and this
int a = 'a';
so it stands to reason that the compiler will attempt that conversion.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Joe Woodbury wrote:
It will even pick int over wchar_t.
In standard C++, conversion between char and int is implicit.
Joe Woodbury wrote:
char should pick wchar_t before to int, or at least a switch should be available to force this behavior.
I disagree. char to int is embedded in the C++ standard.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
In standard C++, conversion between char and int is implicit.
... char to int is embedded in the C++ standard.
Close.
After some research and reading I realized why the compiler is behaving the way it is. When trying to determine which overloaded function to use, if an exact match is not found, the compiler then checks promotions, then conversions.
char to int is a promotion.
char to wchar_t is a conversion. (char is is a numeric value that can represent an ASCII character (0-127) and by definition, the first 127 characters of UNICODE exactly match ASCII. Thus, if the char is in the range 0-127, it appears to be a promotion. However, since by defintion char is a numeric value and wchar_t is a character value, it still is a conversion.)
Anything "going to" a bool, except true or false (or an expression that resolves to true or false), is a conversion, thus the ambiguity I encountered. I still believe, however, that any conversion should take precedence over a conversion to bool.
(I still firmly believe conversions to bool should be optionally disallowed.)
|
|
|
|
|
What might be part of the problem here is that char is signed and wchar_t is unsigned. Thus char -> wchar_t is a degenerative conversion given that over half the range of char can not be properly mapped to wchar_t. However, char -> bool is a well defined conversion given that char fully maps into a bool.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
How icon run my program as any programs in computer,for example i programmed an organizer and i want to run it as any programms,how i can build it ,,any one help me?
|
|
|
|
|
BOOL CWnd::GetWindowPlacement(WINDOWPLACEMENT* lpwndpl) const
{
<code>ASSERT(::IsWindow(m_hWnd));</code>
lpwndpl->length = sizeof(WINDOWPLACEMENT);
return ::GetWindowPlacement(m_hWnd, lpwndpl);
}
Crash says its not a window. However in my code I am getting a nonNUll pointer:
for (int i = 0 ; i <imageDisplayVectorsize ; i++)
{
CImageDisplay* imageDisplay =ImageDisplayVector[i];
imageDisplay->GetWindowPlacement(&wp);
I've used my ImageDisplayVector elsewhere as
int vecSize = ImageDisplayVector.size();
for (int i = 0; i < vecSize; i++)
{
CImageDisplay * pImageTemp = ImageDisplayVector[i];
pImageTemp->ShowWindow(SW_SHOW);
}
and the windows show up (first I'd hidden them) with no problem. Which makes me think my pointer is fine.
SO why does the GetWindowPl think its not a window?
How shall I approach the debugging of this problem?
Appreciate your help,
ns
|
|
|
|
|
Hello Everybody:
This is the weirdest thing that I experienced with MFC. In a project that I'm working, there is a class that is derived from a CScrollView that displays images. When I run the program and the CScrollView is visible on the screen, sometimes it shows up as a text editor. It stays as an text editor and the images shows up. There are some occasions that the text editor just stays there. By any chance any of you guys experienced this before? Any place that you guys can suggest that I can start looking? It's been hard to spot because the code is written by someone else. I tried in the CScrollView's OnInitialUpdate and I don't find anything. This is happens in a Win2k and a WinXP machine. Any answer is more than welcome.
Best regards,
Luis E. Cuadrado
 )
|
|
|
|
|
I spent a while debugging this.:
I had a loop:
for (int i = 0; i &< nSize; i++) ;
{
vec[i]->someMethod();
}
where I was storing pointers to a class in the STL vector.
Well, eventually I saw why my code was crashing......(the  . What puzzles me is that the variable i was still holding its final value of nSize + 1 when it finished with the for(). Besides which my code should have complained that i was not declared.....since its within the for ....
Maybe i am wrong in my scope assumptions?
Appreciate your help,
ns
|
|
|
|
|
Declaring a variable inside the for() is the same as declaring it outside the for(). I'd certainly prefer this not to be the case. As an aside you should be using STL iterators.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
I could...but thats the appeal of an STL vector for me instead of some other container- accessing by index ............ But it would save me from this sort of mishap 
Thanks much. I was mistaken in my scoping assumption then.....
Appreciate your help,
ns
|
|
|
|
|
ns wrote:
I was mistaken in my scoping assumption
Actually, you're right. Microsoft is wrong in this case. Very annoying when you're trying to code for multiple platforms.
he he he. I like it in the kitchen! - Marc Clifton (on taking the heat when being flamed)
Awasu v0.4a[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Hasn't this change been introduced only recently to the standard?
And, although it solves a common nuisance, it can make existing code break silently (though admittedly badly written). A bad move, I'd say...
Those who not hear the music think the dancers are mad. [sighist] [Agile Programming]
|
|
|
|
|
peterchen wrote:
Hasn't this change been introduced only recently to the standard?
Depends if you work for Microsoft and/or consider half a decade to be "recent", or if you consider the ISO C++ standard to be a document Microsoft should follow.
|
|
|
|
|
As I understand it, this was in the proposed revisions, then taken out, then put back in.
If you want the standards behavior you can add extra braces:
{for (int i = 0; i < 10; i++)<br />
{<br />
...<br />
}}
Incidentally, you can turn this enforcement on in VC++.NET.
|
|
|
|
|
Joe Woodbury wrote:
Incidentally, you can turn this enforcement on in VC++.NET.
That might be what you believe, and what Micros~1 wants to fool you into believing - the truth is that you're only screwed from the side, and not directly from behind, with that "fix".
for (int i=...) {}<br />
for (short i=...) {<br />
}
|
|
|
|
|
Mike Nordell wrote:
for (int i=...) {}
for (short i=...) {
// guess type of 'i'
}
short
I just checked (and it does what it advertises.)
|
|
|
|
|
ns wrote:
What puzzles me is that the variable i was still holding its final value ...
This is a well known bug in Microsofts compilers, and even in their "latest and greatest" the bug persists, only in a much more evil form:
for (int i=...) {}<br />
for (short i= ...) {<br />
}
There is but one solution to this problem: To the top of every source file wanting to keep scope of for-loop-variables, add
#ifdef _MSC_VER<br />
#define for if(0) {} else for<br />
#endif
|
|
|
|
|
But his snippet has nothing to do with the "well known" bug?! Or am I missing something?
Those who not hear the music think the dancers are mad. [sighist] [Agile Programming]
|
|
|
|
|
peterchen wrote:
But his snippet has nothing to do with the "well known" bug?!
Yes it has.
Or am I missing something?
Yes you are. This is about scoping of for-loop-variables. Once the for-loop is ended (in the example the terminating semicolon), 'i' is no longer valid. Yet, inside the (artificial and superflous) scope; 'i', which is no more (if following international rules, which MS are not), is still accessible from the broken compiler(s).
|
|
|
|
|
Actually, there's a peculiar inconsistancy with the standard. The opening brace of a for loop is essentially considered superfluous and a hidden brace is implied as being before the declaration.
However, in a do loop, the closing brace is NOT considered to be after the while condition. (Frankly, I wish it were, but it isn't.)
Finally, in Visual Studio .NET, you can turn on enforcement of the standard for scopes of for loops (/Zc:forScope) You can also turn off Microsoft extensions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
