// at beginning of line

[Federico]

Hello. I'd like to understand the following piece of source:

..........

fscanf ( Infile, "%3s %6s", string1, string2);
//fscanf(Infile,"%5s %5s",string3,string4);

^^--------- I don't know the meaning of this double slash.

Thank you in advance.
Federico.

 

[Ben Pfaff]

//fscanf(Infile,"%5s %5s",string3,string4);

^^--------- I don't know the meaning of this double slash.

In C99, it introduces a comment that runs until the end of the
line.

 

[Angel]

Hello. I'd like to understand the following piece of source:

.........

fscanf ( Infile, "%3s %6s", string1, string2);
//fscanf(Infile,"%5s %5s",string3,string4);

^^--------- I don't know the meaning of this double slash.

That line is commented out. Everything after // up till the end of the
line is a comment.

This construction comes from C++, but several compilers (like gcc) made
it available as an extension to C. In C99, this was made official.

 

[Keith Thompson]

Hello. I'd like to understand the following piece of source:

.........

fscanf ( Infile, "%3s %6s", string1, string2);
//fscanf(Infile,"%5s %5s",string3,string4);

^^--------- I don't know the meaning of this double slash.

It introduces a comment, which extends from the "//" to the end of
the line.

It's one of two forms of comments supported by C. The other is
introduced by "/*" and terminated by "*/". (There's more to it
than that, but I won't get into the gory details.)

Note that the C90 standard didn't support "//" comments, only
"/* ... */" comments. C99 introduced "//" comments (borrowed
from C++, and ultimately from BCPL). So your C compiler might not
recognize "//" comments, or might require some option to cause it
to recognize them. (I think most modern C compilers do recognize
"//" comments by default.)

 

[Federico]

Thank u. My compiler is for C not C++ and he gives an error of
"unexpected token - missing semicolon?".

Would it be acceptable to replace with a normal comment /* ... */ ? Or
even delete the line all in all ?

Federico.

 

[Keith Thompson]

Thank u. My compiler is for C not C++ and he gives an error of
"unexpected token - missing semicolon?".

It would have been *extremely* helpful if you had mentioned that in the
first place.

Would it be acceptable to replace with a normal comment /* ... */ ? Or
even delete the line all in all ?

Sure. Or find out how to get your C compiler (which one are you using?)
to recognize // comments.

 

[Angel]

That line is commented out. Everything after // up till the end of the
line is a comment.

This construction comes from C++, but several compilers (like gcc) made
it available as an extension to C. In C99, this was made official.

Thank u. My compiler is for C not C++ and he gives an error of
"unexpected token - missing semicolon?".[/QUOTE]

You may have to tell your compiler to use the C99 standard. With GNU's
gcc, adding -std=c99 to the command line does that. I don't know for
other compilers, consult your documentation.

Would it be acceptable to replace with a normal comment /* ... */ ? Or
even delete the line all in all ?

Yes to both. As far as the compiler is concerned, comments are white
space and are ignored completely.

 

[Shao Miller]

Hello. I'd like to understand the following piece of source:

.........

fscanf ( Infile, "%3s %6s", string1, string2);
//fscanf(Infile,"%5s %5s",string3,string4);

^^--------- I don't know the meaning of this double slash.

You might also enjoy:

fscanf(Infile, "%3s %6s", string1, string2);
#if 0
fscanf(Infile, "%5s %5s", string3, string4);
#endif

or even:

#define TEST_MODE 0
...
fscanf(Infile, "%3s %6s", string1, string2);
#if TEST_MODE
fscanf(Infile, "%5s %5s", string3, string4);
#endif

or maybe:

#define TEST_MODE 0
...
#if !TEST_MODE
fscanf(Infile, "%3s %6s", string1, string2);
#else
fscanf(Infile, "%5s %5s", string3, string4);
#endif

 

[Malcolm McLean]

(I think most modern C compilers do recognize
"//" comments by default.)

My MPI (message passing interface) compiler didn't.
I had written everything in strict ANSI C, with the exception of slash
slash comments, because I thought that surely they were universally
accepted by now. They're also handy for allowing you to comment out
code with slash star comments. On MPI you can't run a debugger, so
it's important to be able to comment out code to try to track down
bugs.

However the cluster compiler wouldn't accept the code. Minor nuisance,
but in programming minor nuisances have a way of becoming major
nuisances.

 

[Jorgen Grahn]

My MPI (message passing interface) compiler didn't.

[Googled it. It's related to some grid computing environment.]

I had written everything in strict ANSI C, with the exception of slash
slash comments, because I thought that surely they were universally
accepted by now.

It's a somewhat unfortunate choice in general, because it prevents you
from using C89 tools on the code (such as gcc -std=c89). If you don't
have C99 tools available, you become reliant on sloppy tools which
accept C89 + // comments + an unknown other set of extensions (such as
gcc -std=gnu89).

They're also handy for allowing you to comment out
code with slash star comments. On MPI you can't run a debugger, so
it's important to be able to comment out code to try to track down
bugs.

I almost always use #if 0 for such things.

I rarely use // even in C++ code; it's IME rare to have to something
that needs documentation, yet not need more than a few words. I prefer
block comments of full sentences. // comments often appear as cryptic
footnotes, squeezed together to the right.

All IMHO of course.

However the cluster compiler wouldn't accept the code. Minor nuisance,
but in programming minor nuisances have a way of becoming major
nuisances.

There are more desirable C99 features you're missing, like the ability
to declare variables where they are used rather than at the top of the
enclosing block. I really miss that when I have to use C89.

/Jorgen

 

[Chris H]

On Thu, 2011-06-02, Malcolm McLean wrote:
It's a somewhat unfortunate choice in general, because it prevents you
from using C89 tools on the code (such as gcc -std=c89). If you don't
have C99 tools available, you become reliant on sloppy tools which
accept C89 + // comments + an unknown other set of extensions (such as
gcc -std=gnu89).

The tools that accept C90 + // are not sloppy. On the other hand GCC
is.

The // was added to C99 because the vast majority of C95 compilers had
it. The job of ISO standards is to standardise what the industry is
doing not go off on flights of fancy which is why virtually no one fully
implements C99 over a decade on.

In fact if C12 comes out on time C99 will be the standard that never
was.

 

[James Kuyper]

On 06/02/2011 03:40 AM, Chris H wrote:
....

it. The job of ISO standards is to standardise what the industry is
doing not go off on flights of fancy which is why virtually no one fully
implements C99 over a decade on.

In fact if C12 comes out on time C99 will be the standard that never
was.

That relies upon the assumption that C12 will be adopted substantially
faster than C99.

I wouldn't be the least bit surprised if compilers improve their
conformance with C12 during 2013 even more slowly than they improve
their conformance with C99, and that will continue to be the case for
many years thereafter.

 

[Chris H]

On 06/02/2011 03:40 AM, Chris H wrote:
...

That relies upon the assumption that C12 will be adopted substantially
faster than C99.

It can't be slower!

I wouldn't be the least bit surprised if compilers improve their
conformance with C12 during 2013 even more slowly than they improve
their conformance with C99, and that will continue to be the case for
many years thereafter.

You would hope that the ISO team learnt their lesson from C99 and only
added things to C12 that the *industry* wanted ie things the compiler
vendors already wanted to add. And made optional thing the majority were
never going to add.

However.... I share your pessimism.

 

[James Kuyper]

It can't be slower!

I don't see why not; the c99 adoption rate isn't 0.

 

[Chris H]

http://blogs.oracle.com/dew/entry/october_23-27_meeting_of_iso1

"We can either subsume ourselves to C++, or plan on revising the C
Standard to adopt existing technologies" I wonder what they'll do in
the end...

That was dated 2006. Some 5 years ago.

 

[Federico]

Thanks for ur help, now the program compiles fine.

However when I run it I get this error :
"PRGWMUPP caused a General Protection Fault in module <unknown>0417:1B6F.
PRGWMUPP will close."

I would like to change the source code to prevent this error, can anyone
advice how to do it ? I think maybe I need a full C++ compiler not just
basic C, would you agree ?

Many Thanks
Federico.

 

[Ben Pfaff]

However when I run it I get this error :
"PRGWMUPP caused a General Protection Fault in module <unknown>0417:1B6F.
PRGWMUPP will close."

I would like to change the source code to prevent this error, can anyone
advice how to do it ?

The program has a bug. I advise you to find the bug and fix it.

I think maybe I need a full C++ compiler not just basic C,
would you agree ?

If removal of // comments is the only change you made to allow
the program to compile as C, the choice of compiling as C versus
C++ is unlikely to be the problem.

 

[Keith Thompson]

Thanks for ur help, now the program compiles fine.

However when I run it I get this error :
"PRGWMUPP caused a General Protection Fault in module <unknown>0417:1B6F.
PRGWMUPP will close."

I would like to change the source code to prevent this error, can anyone
advice how to do it ? I think maybe I need a full C++ compiler not just
basic C, would you agree ?

Please don't top-post. See:
http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php
and almost every other followup in this newsgroup.

(And silly abbreviations like "u" for "you" are not helpful.
I understand they're popular in some places, like text messages;
this is not one of those places.)

You've shown us two lines of code, one of them a comment. We don't
have anything like enough information to guess what might be causing
your program to crash. I wouldn't think that changing from C to C++
would make any difference. Remember that C and C++ are two different
(but closely related) languages.

More suggested reading:
http://www.catb.org/~esr/faqs/smart-questions.html

 

[Ian Collins]

It can't be slower!


You would hope that the ISO team learnt their lesson from C99 and only
added things to C12 that the *industry* wanted ie things the compiler
vendors already wanted to add. And made optional thing the majority were
never going to add.

I hope they do. Because programmers want them, several major C++
compilers are already offer most of the features in the upcoming C++0x
standard.

 

[Chris H]

I hope they do. Because programmers want them, several major C++
compilers are already offer most of the features in the upcoming C++0x
standard.

That is the way it should be.

My worry is they will try and move C closer to C++. A vast amount of C
is in the embedded area on 8-128 bit systems where they don't want C++
(4 bit systems are still used but usually in assembler)

C and C++ are separate languages and should be kept that way. People who
want the features of C++ can use C++ not fit them to C otherwise the
vast majority of the C compilers will not follow the new standard.

I don't mind if the move C++ closer to C to remove the differences but
not the other way around.