|
Hello everyone,
I think if we define foo as char array, for example,
char foo [32];
then foo, &foo and &foo[0] should be the same, right?
For example, the following 3 statements are the same,
strcpy (foo, goo);
strcpy (&foo, goo);
strcpy (&foo[0], goo);
Any comments?
I am very interested in how C treats foo and &foo and make them the same?
thanks in advance,
George
|
|
|
|
|
I think that you will find this to be compiler dependent.
foo is the array, so C/C++ treats the array name as a pointer to the array and thus it is a pointer of the same value as &foo[0].
With some compilers however, I have seen where the compiler stores a pointer to the array (like &foo[0] and then &foo is a pointer to that pointer... so I would stay away from this syntax.
Jim
|
|
|
|
|
Thanks Jim,
I have tested that on Visual Studio, foo and &foo are the same. I think you mean on some other compiler, they may be different.
Here is my test program in Visual Studio.
<br />
int main (int argc, char** argv)<br />
{<br />
char foo [1024];<br />
unsigned int p;<br />
unsigned int q;<br />
p = foo;<br />
q = &foo;<br />
<br />
return 0;<br />
}<br />
I am interested in the cases when "&foo is a pointer to that pointer". I am wondering what is wrong if I still treat foo and &foo the same in this situation? Could you provide more information and analysis please?
regards,
George
|
|
|
|
|
I do not recall where I have seen it. It was several years ago on an embedded compiler... seems like green hills or perhaps wind river. If you are using microsoft, I don't think you will have a problem treating foo and &foo as equals.
Jim Fisher
|
|
|
|
|
Thanks all the same, Jim.
regards,
George
|
|
|
|
|
I was a little intrigued by your question, and made up a little test...
UINT p, q;
char foo [100];
p = (UINT)foo;
q = (UINT) (&foo);
ASSERT(p == q);
char *bar = foo;
p = (UINT) bar;
q = (UINT) (&bar);
ASSERT(p == q);
And you were indeed right. foo and &foo were the same value, but bar and &bar were not. Part of the problem is that we're both cheating and looking at the variables as raw numbers (which I find useful to do conceptually), but the compiler has the advantage of looking at them knowing there type.
So foo is a number, but is known to be an array, while &foo happens through an implementation detail you can't rely on to be true on another day of the week to be the same number, but is treated differently as it has a different type (pointer to an array).
Hard casting like you did can be useful, but it can also be dangerous.
Short answer: compiler dependent. If you rely on it, prepare to be shot in the foot.
Iain.
|
|
|
|
|
Thanks Iain,
So, the best practice is not to use &foo? 
regards,
George
|
|
|
|
|
There's nothing wrong with using &foo - but not as a number. Use it as a "pointer to an array" and let the compiler worry about location details.
"Is it wrong to do..." is not something I can possibly answer in the general case.
But taking your strcpy example...
char foo [100];
strcpy (foo, "iain"); is fine
strcpy (&(foo[0]), "iain"); is fine, but ugly
strcpy (&foo, "iain"); is syntactically wrong, and I'm surprised you don't get a warning at least. It just happens to work on this compiler.
char *bar = new char [100];
strcpy (bar, "iain"); is fine
strcpy (&(bar[0]), "iain"); is fine, but ugly
strcpy (&bar, "iain"); will fail - and mostlikely crash stuff.
As you see, the only difference between "getting away with it", and "failing" is what's written a few lines up, relying on &array == array is a really bad idea, even if you will always get away with it. Imagine you come back in 3 years, your boss says "this needs to be longer - make it dynamically sized", and your code will crash with you being puzzled.
Iain.
|
|
|
|
|
Great comments, thanks Iain!
regards,
George
|
|
|
|
|
In C code an if statement such as:
if(A || B)
will shortcut, i.e. if A is true, it will branch and not even check B.
On the other hand in the case of:
if(A && B)
a shortcut branch is taken if A is false and B is not even checked.
While this is often useful, I have a situation where I would like to disable shortcuts. Is this possible in VC++?
Jim Fisher
-- modified at 0:35 Tuesday 14th August, 2007
|
|
|
|
|
Its pretty deep in the assumptions of C that you will have this shortcutting behaviour, and as you mention, is very useful.
ie.
if (pointer && pointer->otherpointer)
{
...
}
would crash if pointer was null, and there wasn't this shortcutting behaviour.
I'm assuming that A and B are complex expressions, or function calls.
In which case you can do...
BOOL A = Something_I_Insist_On_Being_Done ();
BOOL B = Other_Thing ();
if (A || B)
{
...
}
If a compiler flag did exist then you'd have terrible trouble understanding why you used it when you look back in two years time. To avoid that, you'd end up writing so many comments you may as well have done the preconditions early as I did in my example.
Iain.
ps. Never forget the impact on your successor - especially as that may be you on a monday morning with a hangover...
|
|
|
|
|
It's called short-circuit evaluation, and has been part of C for decades. Why would you want to "disable" it?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
when building software for avionics (DO-178B) Level A (critical to safety) one must test every path in the code.
The difficult paths to prove they have been taken are generally the "shortcut" paths. Thus it is often easier to test the crash cases yourself as:
if(pointer != NULL)
{
if(pointer->object)
{
do whatever
One can still do this even with short cutting, it is just expressions such as:
if((A || B) && (C || D))
These have several shortcut paths.
To defeat this, one could convert the bools to unsigned int and
// no shortcutting on bit ops as the compiler thinks I need all 16 bits
X = (A | B) & (C | D);
if(X != 0)
{
do this or that
But this seems more awkward and harder to manage (code reviews etc) than just defeating the shortcut code generation...
Make sense or no?
Jim Fisher
|
|
|
|
|
Hi,
I am using Visual Studio 6 for compilation of source code however i am getting "fatal error C1001: INTERNAL COMPILER ERROR". Can you pls help me to remove this compilation problem.
Thanks
Pankaj
|
|
|
|
|
MSDN Library says:
Fatal Error C1001
INTERNAL COMPILER ERROR
(compiler file 'file', line number)
This error is most often generated in one of two cases:
Failure to recover the compiler's internal state following detection of a syntax error in the program. The first pass of the compiler will occasionally fail when attempting to recover its state following the detection of a malformed program. Typically, the compiler will have printed an error message (or messages) and will later produce an internal compiler error. In most cases, fixing the errors reported in your code and recompiling will solve the problem.
Failure of the code generator to find a way to generate correct code for a construct. This is most often caused by the interaction of an expression and an optimization option. The optimization has generated a tree which the compiler does not know how to handle. Such a problem can often be fixed by removing one or more optimization options when compiling the particular function containing the line indicated in the error message.
If no error messages have been emitted prior to the internal compiler error, then the next step is to determine which pass of the compiler is emitting the internal compiler error. This can be determined by recompiling the application with the /Bd option included. The /Bd option will cause each pass to print its name and arguments when it is invoked. The last pass invoked before the error is emitted is the one responsible.
If the pass indicated is P1, then the likely problem is still error recovery, as in number one above, but it is happening before the compiler has had a chance to emit the error message for the error it has just discovered. In such a case, examine the line on which the internal compiler error is reported. This line may also contain an unreported syntax error. Fixing any errors you find on that line will solve the internal compiler error in most cases. If you cannot find any error on that line or on the line previous to the one reported, contact Microsoft Product Support Services for help.
If the pass indicated is P2, then the problem can usually be fixed by removing one or more optimization options (or using a different code generator). You can determine which option is at fault by removing them one at a time and recompiling until the message goes away. Generally the last one removed is the problem and all other optimizations can be used safely. The most common culprits are /Og, /Oi, and /Oa. Once the offending optimization is discovered, it need not be turned off for the entire compilation. The offending optimization can be disabled with the optimize pragma while compiling the function where the error occurred, but enabled for the rest of the module.
More rarely, such errors occur at very low optimization levels or even when optimization is disabled. In such cases, rewriting the line where the error is reported (or possibly several lines including the one causing the error) may be a solution. If none of these options works, consult the technical support help file or the technical support section in one of your manuals.
Jim
|
|
|
|
|
Thanks Jim for your reply however I am still facing same compilation problem after removing all /Og, /Oi, and /Oa option. In fact I am using the default VS 6.0 optimization option.
|
|
|
|
|
E.g.
double dbInf=1/sin(0);
currently I check it as:
//=====================
char sz[4096];
sprintf(sz,"%f",dbInf);
if(strchr(sz,'#')) //true means the double is infinite number.
//========================
in my program, I have million of doubles needed to be checked, above checking code is very slow.
my Q is:
how to check it directly without using sprintf() and strchr()?
or how to check it faster?
thx.
|
|
|
|
|
There is the CRT function _finite(double)[^], but it is not working. 
Maxwell Chen
|
|
|
|
|
#include <math.h>
#include <float.h>
...
double dbInf = 1.0 / sin((double)0);
if (0 == _finite(dbInf))
{
}
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
I tried to run my ActiveX-embled MFC Application on Computer with out VC++ install and It doesn't work
But It work on another computer with vc++ 6.0 installed
Can someone suggest the solution?
|
|
|
|
|
Register that ActiveX control with regsvr32.exe.
Maxwell Chen
|
|
|
|
|
|
Hello everybody,
Is there any documention around which describes the name mangling sheme of this sw.
I googled around but found nothing useful.
I have a .dll which is compiled within the same solution and it exports the functions as "functionname" without leading
underscore
In the same solution I want to use this .dll as a lib for a normal .exe and this insists that to link to
"_functionname" (with underscore) which is of course not found in the .dll/.lib
The functions are decleared as extern "C" as usual and also the __declspec(dllexport) is like normal.
Anybody any idea?
bb |~ bb
|
|
|
|
|
Harald Krause wrote: Is there any documention around which describes the name mangling sheme of this sw.
Microsoft Visual C++ Name Mangling[^]
Harald Krause wrote: I have a .dll which is compiled within the same solution and it exports the functions as "functionname" without leading
underscore In the same solution I want to use this .dll as a lib for a normal .exe
You have to view the actual export symbols with the tool "Dependency Walker".
Harald Krause wrote: this insists that to link to
"_functionname" (with underscore) which is of course not found in the .dll/.lib
The functions are decleared as extern "C" as usual and also the __declspec(dllexport) is like normal.
This is the standard pure C export behavior.
Maxwell Chen
|
|
|
|
|
How to treat Image files in drawing DFD, as Entity or as Data Store...?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
