Bizarre compiler error

[Alan Williams-Key]

I am being bugged by some bizarre compiler errors when compiling in debug
configuration (but not in release). Here is a test function...

void test()
{
int i = 1;
ASSERT(i==0);
}

When I compile this on my PC I get the following

D:\...\File.cpp(32806) : warning C4305: 'initializing' : truncation from
'int' to 'short'
D:\...\File.cpp(32806) : warning C4309: 'initializing' : truncation of
constant value

Does anyone have any ideas what is causing this. As far as I can see there
is no truncation going on in this function.

Alan

 

[Doug Harrison [MVP]]

I am being bugged by some bizarre compiler errors when compiling in debug
configuration (but not in release). Here is a test function...

void test()
{
int i = 1;
ASSERT(i==0);
}

When I compile this on my PC I get the following

D:\...\File.cpp(32806) : warning C4305: 'initializing' : truncation from
'int' to 'short'
D:\...\File.cpp(32806) : warning C4309: 'initializing' : truncation of
constant value

Does anyone have any ideas what is causing this. As far as I can see there
is no truncation going on in this function.

My first thought is that the error is occurring in a different function
than you posted. Assuming this is the right function, and ASSERT does what
I think it does, the error has to be due to either a preprocessor mishap or
a compiler bug. You can compile with /P to examine the preprocessor output.
You can compile the function in its own file to rule out a compiler bug
triggered by whatever precedes the function in your very large source file.

 

[Alan Williams-Key]

My first thought is that the error is occurring in a different function
than you posted. Assuming this is the right function, and ASSERT does what
I think it does, the error has to be due to either a preprocessor mishap or
a compiler bug. You can compile with /P to examine the preprocessor output.
You can compile the function in its own file to rule out a compiler bug
triggered by whatever precedes the function in your very large source file.

Thanks. I found this one using your suggestion. Within the ASSERT there was
"AfxAssertFailedLine(THIS_FILE, 32822)"
and I guess 32822 is the fly in the ointment. The other problems (5 of them)
are similar. The debug version is including a line number in the debug
version of library routines (eg the "new" statement).

OK, I have a large file and I guess this just means my debug builds will
generate these warning messages. Thanks for your help.

Alan

 

[David Wilkinson]

Thanks. I found this one using your suggestion. Within the ASSERT there was
"AfxAssertFailedLine(THIS_FILE, 32822)"
and I guess 32822 is the fly in the ointment. The other problems (5 of them)
are similar. The debug version is including a line number in the debug
version of library routines (eg the "new" statement).

OK, I have a large file and I guess this just means my debug builds will
generate these warning messages. Thanks for your help.

Alan:

Why don't you just split this file up into smaller pieces?

 

[Alan Williams-Key]

Yep, that's the obvious thing to do. I was not experienced with VS C++ when I
started this project and if I were starting it now I would split my classes
into files completely differently. It's somthing that has to be done with
care, though, and although I can split a class out into a separate file I'm
not sure if VS will recognise its new home if I then add a new function
member. Is there a trick I need to know?

Alan

 

[David Wilkinson]

Yep, that's the obvious thing to do. I was not experienced with VS C++ when I
started this project and if I were starting it now I would split my classes
into files completely differently. It's somthing that has to be done with
care, though, and although I can split a class out into a separate file I'm
not sure if VS will recognise its new home if I then add a new function
member. Is there a trick I need to know?

Alan:

It shouldn't be any problem. You don't have to split the header file if you
don't want; just split the implementation file.

I assume this file is not all one class? But even if it is, you can still split
the implementation into multiple pieces.

 

[Doug Harrison [MVP]]

Thanks. I found this one using your suggestion. Within the ASSERT there was
"AfxAssertFailedLine(THIS_FILE, 32822)"
and I guess 32822 is the fly in the ointment.

Given these declarations, and assuming a 32 bit (or more) compiler, I don't
see why that's a problem:

#define ASSERT(f) DEBUG_ONLY((void) ((f) || !::AfxAssertFailedLine(THIS_FILE, __LINE__) || (AfxDebugBreak(), 0)))
BOOL AFXAPI AfxAssertFailedLine(LPCSTR lpszFileName, int nLine);

The function you presented earlier was:

void test()
{
int i = 1;
ASSERT(i==0);
}

What does the line "int i = 1;" look like in the /P file? Moreover, I can't
repro the problem in VC 2008 by running this program and compiling its
output:

// a.cpp

#include <stdio.h>

int main()
{
FILE* fp = fopen("b.cpp", "w");
fputs("#include <stdio.h>\n", fp);
fputs("void print(int n) { printf(\"%d\\n\", n); }\n", fp);
for (int i = 0; i < 32900; ++i)
fputc('\n', fp);
fputs("int main() { print(__LINE__); }\n", fp);
fclose(fp);
}

So either int is getting replaced by short in your file (which makes me
wonder how you can link), there's a compiler bug, or the problem lies
elsewhere. What version of the compiler are you using?

The other problems (5 of them)
are similar. The debug version is including a line number in the debug
version of library routines (eg the "new" statement).

OK, I have a large file and I guess this just means my debug builds will
generate these warning messages. Thanks for your help.

Unless it's machine-generated, I'd want to split it into manageable pieces
preferably no larger than a few hundred lines each even if I wasn't getting
errors.