[Bug c++/56959] New: unable to find string literal operator ‘operator""

[Bug c++/56959] New: unable to find string literal operator ‘operator""

[daffra.claudio at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959

             Bug #: 56959
           Summary: unable to find string literal operator ‘operator""
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daffra.claudio@gmail.com


claudio@ubuntu64:~/chtulu linux$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2

#define strCopyRight   "chtulu"\
"\nprogramming language"\
"\n[2013] LGPL (2) : daffra.claudio@gmail.com"

....

 const char *s = "\n"\
 strCopyRight\
 "\n\nUsage :\n"\
 "\n"strProjectName" : <input file> "\
 "\n\noptions\n"\
 "\nhelp file    : -h "\
 "\ninput file   : -i <input  file name>"\
 "\noutput file  : -o <output file name>"\
 "\n"; 

main.c: In function ‘void HelpFile()’:
main.c:34:2: error: unable to find string literal operator ‘operator""
strProjectName’
-rwxrwxr-x 1 claudio claudio 28532 apr 14 22:47 ch\r
claudio@ubuntu64:~/chtulu linux$

this piece of code (up) compile with error , as you see

this ohter (down) piece of code compile without error :
i must separate strProjectName with space before and after
n.b. same version of gcc in windows tdm64-gcc-4.7.1-3 work good

 const char *s = "\n"\
 strCopyRight\
 "\n\nUsage :\n"\
 "\n" strProjectName " : <input file> "\
 "\n\noptions\n"\
 "\nhelp file    : -h "\
 "\ninput file   : -i <input  file name>"\
 "\noutput file  : -o <output file name>"\
 "\n";
>From gcc-bugs-return-420269-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 14 21:28:34 2013
Return-Path: <gcc-bugs-return-420269-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3020 invoked by alias); 14 Apr 2013 21:28:34 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2976 invoked by uid 48); 14 Apr 2013 21:28:29 -0000
From: "quantheory at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
Date: Sun, 14 Apr 2013 21:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: quantheory at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: CC
Message-ID: <bug-48979-4-gOKBxeTKfb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-48979-4@http.gcc.gnu.org/bugzilla/>
References: <bug-48979-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01414.txt.bz2
Content-length: 2395


http://gcc.gnu.org/bugzilla/show_bug.cgi?idH979

Sean Santos <quantheory at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |quantheory at gmail dot com

--- Comment #16 from Sean Santos <quantheory at gmail dot com> 2013-04-14 21:28:27 UTC ---
Regarding the above comment:
"You need to have IEEE_EXCEPTIONS or IEEE_ARITHMETIC loaded *in the scoping
unit*, if you want to use IEEE 754 features."

Well, yes and no. There are three cases:

1) If you don't access those modules in a particular scope, it is
"processor-dependent" (e.g. up to the compiler) whether IEEE features are
supported. They can be on or off all the time, or there can be a compiler
option.

2) If you do access those modules, it is *still* "processor-dependent" whether
IEEE features are supported, so that doesn't change. However, this does change:

    i) The compiler is allowed to change the level of IEEE support. It is
explicitly allowed to change the degree of support for exceptions. I don't
think that the committee actually intended for support of IEEE NaN and Inf to
change based on whether or not IEEE_ARITHMETIC is in scope, but technically the
standard seems to allow it.

    ii) If IEEE_ARITHMETIC is provided, the compiler is required to provide the
IEEE_SUPPORT_* functions so that the program can query them. (However, it is
not supposed to enforce their use at compile time.)

3) If you access IEEE_ARITHMETIC and use "IEEE_NAN" and "IEEE_INF" from
IEEE_FEATURES, the compiler is required to do one of only three things:

    i) Error at compile time because it doesn't have one or both modules.
    ii) Error at compile time because it has IEEE_FEATURES, but the module
doesn't contain IEEE_NAN/IEEE_INF.
    iii) Enable support of IEEE_NAN and IEEE_INF in the scope.


TLDR: If the compiler declares that it doesn't actually have any IEEE support
(which it implicitly does by not providing these modules), it can do anything
it wants. If IEEE_FEATURES was provided, that should probably be used to turn
on IEEE features that are turned off by default because they are inefficient,
not IEEE_ARITHMETIC. If an IEEE feature isn't a significant performance hit, it
may as well be on all the time.

[Bug c++/56959] unable to find string literal operator ‘operator""

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-04-14 22:15:59 UTC ---
Are you using -std=c++11 or -std=gnu++11 or -std=c++0x or -std=gnu++-0x ? If
this is the correct behavior as the strCopyRight in this case is the custom
operator.

[Bug c++/56959] unable to find string literal operator ‘operator""

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID
           Severity|major                       |normal

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-04-14 22:42:25 UTC ---
See the section on "User-defined literals and whitespace" at
http://gcc.gnu.org/gcc-4.7/porting_to.html

[Bug c++/56959] unable to find string literal operator ‘operator""

[daffra.claudio at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959

--- Comment #3 from claudio daffra <daffra.claudio at gmail dot com> 2013-04-14 22:43:34 UTC ---
no bug, std=c++11

[Bug c++/56959] unable to find string literal operator ‘operator""

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-04-14 22:48:00 UTC ---
Also, the backslashes are a complete waste of time, you can just write:

const char *s = "\n"
strCopyRight
"\n\nUsage :\n"
"\n"strProjectName" : <input file> "
"\n\noptions\n"
"\nhelp file    : -h "
"\ninput file   : -i <input  file name>"
"\noutput file  : -o <output file name>"
"\n";