// at beginning of line

Discussion in 'C Programming' started by Federico, Jun 1, 2011.

  1. Federico

    Federico Guest

    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.
    Federico, Jun 1, 2011
    #1
    1. Advertising

  2. Federico

    Ben Pfaff Guest

    Federico <> writes:

    > //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.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jun 1, 2011
    #2
    1. Advertising

  3. Federico

    Angel Guest

    On 2011-06-01, Federico <> wrote:
    > 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.


    --
    "C provides a programmer with more than enough rope to hang himself.
    C++ provides a firing squad, blindfold and last cigarette."
    - seen in comp.lang.c
    Angel, Jun 1, 2011
    #3
  4. Federico <> writes:
    > 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.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 1, 2011
    #4
  5. Federico

    Federico Guest

    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.


    Angel writes:
    > On 2011-06-01, Federico <> wrote:
    >> 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.
    Federico, Jun 1, 2011
    #5
  6. Federico <> writes:
    > Angel writes:
    >> On 2011-06-01, Federico <> wrote:
    >>> 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.

    >
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 1, 2011
    #6
  7. Federico

    Angel Guest

    On 2011-06-01, Federico <> wrote:
    [ top posting fixed ]
    > Angel writes:
    >> On 2011-06-01, Federico <> wrote:
    >>> 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.

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


    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.


    --
    "C provides a programmer with more than enough rope to hang himself.
    C++ provides a firing squad, blindfold and last cigarette."
    - seen in comp.lang.c
    Angel, Jun 1, 2011
    #7
  8. Federico

    Shao Miller Guest

    On 6/1/2011 2:44 PM, Federico wrote:
    > 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
    Shao Miller, Jun 2, 2011
    #8
  9. On Jun 1, 10:56 pm, Keith Thompson <> wrote:
    > (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.
    Malcolm McLean, Jun 2, 2011
    #9
  10. Federico

    Jorgen Grahn Guest

    On Thu, 2011-06-02, Malcolm McLean wrote:
    > On Jun 1, 10:56 pm, Keith Thompson <> wrote:
    >> (I think most modern C compilers do recognize
    >> "//" comments by default.)
    >>

    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 2, 2011
    #10
  11. Federico

    Chris H Guest

    In message <>, Jorgen Grahn
    <> writes
    >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.



    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jun 2, 2011
    #11
  12. Federico

    James Kuyper Guest

    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.
    --
    James Kuyper
    James Kuyper, Jun 2, 2011
    #12
  13. Federico

    Chris H Guest

    In message <is7nst$vr5$>, James Kuyper
    <> writes
    >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.


    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.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jun 2, 2011
    #13
  14. Federico

    James Kuyper Guest

    On 06/02/2011 06:35 AM, Chris H wrote:
    > In message <is7nst$vr5$>, James Kuyper
    > <> writes
    >> On 06/02/2011 03:40 AM, Chris H wrote:
    >> ...

    ....
    >>> 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.

    >
    > It can't be slower!


    I don't see why not; the c99 adoption rate isn't 0.
    --
    James Kuyper
    James Kuyper, Jun 2, 2011
    #14
  15. Federico

    Chris H Guest

    In message <20110602151809.10832c14@kubuntu>, Lorenzo Villari
    <> writes
    >On Thu, 2 Jun 2011 11:35:42 +0100
    >Chris H <> wrote:
    >
    >>
    >> It can't be slower!
    >>

    >
    >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.


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jun 2, 2011
    #15
  16. Federico

    Federico Guest

    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.

    Keith Thompson writes:
    > Federico <> writes:
    >> Angel writes:
    >>> On 2011-06-01, Federico <> wrote:
    >>>> 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.

    >>
    >> 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.
    Federico, Jun 2, 2011
    #16
  17. Federico

    Ben Pfaff Guest

    Federico <> writes:

    > 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.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jun 2, 2011
    #17
  18. Federico <> writes:
    > Keith Thompson writes:
    >> Federico <> writes:
    >>> Angel writes:
    >>>> On 2011-06-01, Federico <> wrote:
    >>>>> 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.
    >>>
    >>> 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.

    >
    > 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

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 2, 2011
    #18
  19. Federico

    Ian Collins Guest

    On 06/ 2/11 10:35 PM, Chris H wrote:
    > In message<is7nst$vr5$>, James Kuyper
    > <> writes
    >> 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.

    >
    > 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.


    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.

    --
    Ian Collins
    Ian Collins, Jun 2, 2011
    #19
  20. Federico

    Chris H Guest

    In message <>, Ian Collins <ian-
    > writes
    >On 06/ 2/11 10:35 PM, Chris H wrote:
    >> In message<is7nst$vr5$>, James Kuyper
    >> <> writes
    >>> 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.

    >>
    >> 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.

    >
    >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.


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jun 3, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raj Mudaliar
    Replies:
    0
    Views:
    2,244
    Raj Mudaliar
    Jul 14, 2003
  2. Alan Silver
    Replies:
    2
    Views:
    370
    Alan Silver
    Nov 14, 2005
  3. Randy Kramer
    Replies:
    3
    Views:
    115
    Andrew Johnson
    Mar 26, 2006
  4. Jesse B.
    Replies:
    9
    Views:
    219
    Jesse B.
    Mar 27, 2010
  5. Jesse B.
    Replies:
    27
    Views:
    238
    thunk
    Apr 3, 2010
Loading...

Share This Page