stray"\26" in program

[Grzesiek]

Hi

I have Main.cpp and Hello.cpp files in my Dev C++ project.


Main.cpp


#include "Hello.cpp"


int main(){
return 0;



}


Hello.cpp

#include<stdio.h>


int main(){
printf("Hello World!");
getchar();
return 0;


}


//here is a square char and it rises error

My question is: Suppose i cant modify Hello.cpp. What can i do to
make
the compiler to ignore the square at the end of Hello.cpp file?


Regrads


Grzesiek Wilanowski

 

[Martin Ambuhl]

Hi
I have Main.cpp and Hello.cpp files in my Dev C++ project.

For most implementations, filenames ending in ".cpp" are C++ source
files, and those implementations use a C++ compiler to handle them.
<is for the different programming language C, and
source files for C usually end in ".c". Implementations vary, of
course, and other conventions may hold for yours, although I would guess
not, since I believe yours is based on gcc. In any case, you need to
make sure that your C source files are not treated as C++. If you mean
to be using C++, that different language is addressed in

Main.cpp

#include "Hello.cpp"

Since filenames ending in ".c" for C or in ".cpp" for the off-topic
language C++ almost always have executable code or definitions, they are
rarely used for headers. Headers should, with a few exceptions, be
reserved for #defines or non-defining declarations. In fact, your
"Hello.cpp" contains definitions conflicting with those in "Main.cpp"

int main(){
return 0;
}

The code above does nothing.

Hello.cpp

#include<stdio.h>

^^ whitespace is cheap. Use it.

int main(){

^^^^^^^^^^
You now have two different functions named main. There is no way for
the linker to know which one is the right one.

printf("Hello World!");
getchar();
return 0;


}

//here is a square char and it rises error

Obviously, you should delete the stray character. But that won't solve
your problem.

My question is: Suppose i cant modify Hello.cpp. What can i do to
make
the compiler to ignore the square at the end of Hello.cpp file?

Nothing. You need to delete the extraneous character.

Regrads

(Just so you know: "Regards")

 

[Keith Thompson]

I have Main.cpp and Hello.cpp files in my Dev C++ project.

The ".cpp" suffix is usually used for C++, not for C. If you're
programming in C++, you're in the wrong newsgroup. But you don't use
any C++-specific features in either program, so ...

Main.cpp


#include "Hello.cpp"


int main(){

In C, this is ok, but "int main(void)" is preferred.

return 0;



}


Hello.cpp

#include<stdio.h>


int main(){
printf("Hello World!");

You should terminate the output with a '\n' character:

printf("Hello World!\n");

getchar();
return 0;


}

Why do you include "Hello.cpp" in "Main.cpp"? That gives you two
main() functions in one translation unit.

//here is a square char and it rises error

My question is: Suppose i cant modify Hello.cpp. What can i do to
make the compiler to ignore the square at the end of Hello.cpp file?

It's your file; why wouldn't you be able to modify it?

You say in the subject header that you have a "\26" character. I'm
only guessing, but do you mean character decimal 26, or control-Z?
Some systems use that character to mark end-of-file. Apparently your
compiler doesn't accept it -- and the language doesn't require it to.
There may or may not be a way to cause it to do so, but that's a
question about your compiler, not about the language. Consult your
compiler's documentation, or ask in a forum where your compiler is
topical.

 

[Barry Schwarz]

Hi

I have Main.cpp and Hello.cpp files in my Dev C++ project.


Main.cpp


#include "Hello.cpp"


int main(){
return 0;



}


Hello.cpp

#include<stdio.h>


int main(){
printf("Hello World!");
getchar();
return 0;


}


//here is a square char and it rises error

My question is: Suppose i cant modify Hello.cpp. What can i do to
make
the compiler to ignore the square at the end of Hello.cpp file?

Even without the weird character, the code would not compile cleanly.
Your translation unit has two functions with the same name. Neither
function signature complies with the standard. And why do you have C
code in what most compilers consider a C++ source file. Or if you
want it to be C++ code, you should be asking in comp.lang.c++.

If you cannot modify the included file, one option is to never include
it any source file you want to compile. Another option would be to
surround the #include directive with /*...*/ comment delimiters. A
third would be to imbed the #include directive within a set of
#if 0...#endif directives. It is possible that your compiler has a
special option to ignore this extraneous character but you would have
to ask about that in a group that discusses your compiler.

Seriously, what kind of help were you expecting? "My source has
syntax errors but I'm not allowed to change it" is a situation without
solution.


Remove del for email

 

[Army1987]

Even without the weird character, the code would not compile cleanly.
Your translation unit has two functions with the same name. Neither
function signature complies with the standard.

What?
The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
*or* *equivalent*
And int main() is equivalent (in this context) with int main(void),
much like int main(int, char **) int argc, char **argv { } is
equivalent with int main(int argc, char *argv[]) { /* ... */ }.

 

[Barry Schwarz]

Even without the weird character, the code would not compile cleanly.
Your translation unit has two functions with the same name. Neither
function signature complies with the standard.

What?
The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
*or* *equivalent*

In footnote 9 to section you quote (yes footnotes may not be
normative), the standard provides examples of what the committee meant
by equivalent (using a typedef for int or char **argv).

And int main() is equivalent (in this context) with int main(void),
much like int main(int, char **) int argc, char **argv { } is
equivalent with int main(int argc, char *argv[]) { /* ... */ }.

int main() does not specify either no parameters or two parameters.
(As you quoted, these are the only two standard definitions.)
Therefore it is not equivalent. In this context, it may be irrelevant
(only because main is not called recursively) but there is no reason
not to define it correctly. For a beginner, it easier to learn to do
it right than to unlearn a bad habit that should never have developed
in the first place.


Remove del for email

 

[Army1987]

On Mon, 02 Jul 2007 22:07:14 -0700, Grzesiek
int main(){ [snip]
int main(){ [snip]
Your translation unit has two functions with the same name. Neither
function signature complies with the standard.

What?
The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
*or* *equivalent*

In footnote 9 to section you quote (yes footnotes may not be
normative), the standard provides examples of what the committee meant
by equivalent (using a typedef for int or char **argv).

And int main() is equivalent (in this context) with int main(void),
much like int main(int, char **) int argc, char **argv { } is
equivalent with int main(int argc, char *argv[]) { /* ... */ }.

int main() does not specify either no parameters or two parameters.
(As you quoted, these are the only two standard definitions.)
Therefore it is not equivalent. In this context, it may be irrelevant
(only because main is not called recursively) but there is no reason
not to define it correctly. For a beginner, it easier to learn to do
it right than to unlearn a bad habit that should never have developed
in the first place.

I agree, but your claim that int main() doesn't comply with the
standard is wrong.

 

[Barry Schwarz]

snip

I agree, but your claim that int main() doesn't comply with the
standard is wrong.

By your own quote, the definition must specify no arguments or two.
Which of these does int main() specify?


Remove del for email

 

[Peter Nilsson]

... the definition must specify no arguments or two.

'some other implementation-defined manner' aside, it must
specify zero or two _parameters_. Arguments are expressions
supplied when the function is called.

Which of these does int main() specify?

6.7.5.3p14: "...An empty list in a function declarator that
is part of a definition of that function specifies that
the function has no parameters."

 

[Jack Klein]

snip

By your own quote, the definition must specify no arguments or two.
Which of these does int main() specify?

In a function definition, empty parentheses define exactly no
arguments. For the purpose of defining the function,

int main()

....is exactly equivalent to:

int main(void)

Paragraph 14 of 6.7.5.3 Function declarators (including prototypes):

"An identifier list declares only the identifiers of the parameters of
the function. An empty list in a function declarator that is part of a
definition of that function specifies that the function has no
parameters. The empty list in a function declarator that is not part
of a definition of that function specifies that no information about
the number or types of the parameters is supplied."

Specifically the second sentence.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

'some other implementation-defined manner' aside, it must
specify zero or two _parameters_. Arguments are expressions
supplied when the function is called.


6.7.5.3p14: "...An empty list in a function declarator that
is part of a definition of that function specifies that
the function has no parameters."

The more I look at this, the more bewildered I become. I think the
standard is impressively ambiguous on this (relatively minor) point.

As a practical matter of programming, there's no good reason to write

int main() { /* ... */ }

rather than

int main(void) { /* ... */ }

The latter is certainly correct; the former, if it's correct at all,
depends on the fact that the empty parentheses mean one thing in a
function definition, and something else in a prototype that's not part
of a definition.

As for what the standard says, 6.7.5.3p14 is as you say above. Here's
5.1.2.2.1p1:

The function called at program startup is named main. The
implementation declares no prototype for this function. It shall
be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though
any names may be used, as they are local to the function in which
they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent;9) or in some other implementation-defined manner.

Footnote 9 says:

Thus, int can be replaced by a typedef name defined as int, or the
type of argv can be written as char ** argv, and so on.

Clearly the "or equivalent" phrase is intended to allow for the
variations mentioned in the footnote.

But what is the "scope" of the "or equivalent" phrase? Does it apply
starting at "It shall be defined", or at "or with two parameters"? If
the former, then 'int main() { /* ... */ }' is legal; if not, it
isn't.

I had nearly convinced myself that the "or equivalent" applies only to
the two-parameter form, until I realized that it would mean that 'int
main' could be replaced with 'typedef_for_int main' for the
two-parameter form, but *not* for the zero-parameter form. That just
seems silly.

On the other hand, I'm not entirely convinced by an argument that
depends on *assuming* that the standard is sensible.

I think I'll raise this in comp.std.c.

 

[Richard Heathfield]

Keith Thompson said:

But what is the "scope" of the "or equivalent" phrase? Does it apply
starting at "It shall be defined", or at "or with two parameters"? If
the former, then 'int main() { /* ... */ }' is legal; if not, it
isn't.

We've been here before, Keith (back in the days when we had quite a few
more clueful people than latterly); the prospect of searching
DejaGoogle palls somewhat, however, so I'm just going to IIRC.

IIRC, most clueful people thought that it meant this:

It shall be defined with:

(a) a return type of int and with no parameters
(b) or with two parameters [...]
(c) or equivalent;
(d) or in some other implementation-defined manner.

Personally, I don't think that makes sense. The "with no" and "with two"
make a natural pattern, which would lead to this interpretation:

It shall be defined with a return type of int and:

(a) with no parameters
(b) or with two parameters [...]
(c) or equivalent
(d) or in some other implementation-defined manner.

The C Committee already knew (BEFORE C99) that people were getting main
wrong, and that this could cause problems, and they had a great chance
to fix it. Instead, all they did was add to the confusion.

All they had to say for main's type was something like this:

"It shall be defined with a return type of int. It shall have either no
parameters or two parameters. If it has two parameters, the first shall
have type int, and the second shall have type char **. Thus, the
following main function declarators are legal:

int main()
int main(void)
int main(int argc, char **argv)

as are any other forms that have precisely the same semantics."

They didn't even need to mention "some other implementation-defined
manner" because implementations /already/ have discretion to provide
extensions.

I think I'll raise this in comp.std.c.

What makes you think they'll know what it means?

 

[Army1987]

snip

By your own quote, the definition must specify no arguments or two.
Which of these does int main() specify?

int main() { ... } specifies no argument.
int main(int, char**) int argc, char **argv { ... } specifies two
arguments.
A *declaration* such as int main(); wouldn't specify anything.