C++ error: invalid use of ‘::’ for `std::cout` - c++

This is probably the weirdest thing I have seen in the last few years.
I have a project that builds perfectly well in two completely different machines (openSUSE Tumbleweed and ubuntu 14.04).
I started with a new machine using kubuntu 16.04 and this error started happening:
$ g++ -std=c++14 cout_qualif.cpp -lpng -o cout_qualif
In file included from cout_qualif.cpp:1:0:
debug_utils.h:19:19: error: invalid use of ‘::’
# define msg std::cout
Clang also points an error, but with a quite different message:
$ clang -std=c++14 cout_qualif.cpp -lpng -o cout_qualif
In file included from cout_qualif.cpp:3:
In file included from /usr/include/png++/png.hpp:34:
In file included from /usr/include/png.h:317:
/usr/include/zlib.h:94:19: error: non-friend class member 'cout' cannot have a qualified name
z_const char *msg; /* last error message, NULL if no error */
^~~
./debug_utils.h:19:19: note: expanded from macro 'msg'
# define msg std::cout
~~~~~^
1 error generated.
The simplest test code I've came across is:
#include <iostream>
#include "debug_utils.h"
#include <png++/png.hpp>
int main()
{
msg << "Start" << std::endl;
png::image< png::rgb_pixel > image("input.png");
image.write("output.png");
msg << "Finish" << std::endl;
return 0;
}
And "debug_utils.h":
#ifndef DEBUG_UTILS_H
#define DEBUG_UTILS_H
#include <iostream>
# define msg std::cout
#endif // DEBUG_UTILS_H
It turns out that "png.h" includes "zlib.h" and there is defined a struct:
typedef struct z_stream_s {
// ...
z_const char *msg; /* last error message, NULL if no error */
This msg member is what is triggering the error. If I move my #include "debug_utils.h" one line below, after #include <png++/png.hpp>, everything seems to work fine.
Now finally the question:
Why this machine cannot compile my code while two other can?
Additional info:
Kubuntu 16.04:
$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
$ clang --version
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
openSUSE Tumbleweed:
g++ is 7.1.1
Ubuntu 14.04:
Exact version not available at hand but I believe it is 4.9.x

To recap the cause of the problem
# define msg std::cout
in debug_utils.h substitutes std::cout for any instances of msg throughout the code after debug_utils.h is included. As msg is a common short identifier, particularly for a message buffer, an unintended substitution has always been a risk lurking in the code. The solution to this is obvious: Don't do that. Use a longer, less likely to be duplicated substitution or don't do it at all and replace the macro. Without seeing your usecase I'd probably replace the macro with a function that returns the correct stream and the compiler can easily inline.
The confusion and the question stems from why an error from the macro substitution only arises from a simple piece of test code when compiled on only one of three candidate PCs.
The answer is differences in the toolchain and support libraries. For one reason or another, on only one of these PCs a third-party header that uses the msg identifier is included by a third-party header included by the test program. The other two follow different inclusion paths to build the same program and avoid tripping over the unwanted substitution.

Related

Code compiles in CLion but not in Command Prompt

I am trying to a C++ library and need (want) to use nested namespaces in order to increase readability of the code. However, I am running into a problem when trying to compile my code in the Windows Command Prompt with g++ main.c.
The code below is an example of what I will have -- a nested namespace and then some functions or classes:
namespace gpc::warning {
void raiseError() {
std::cout << "Error...\n";
exit(1);
}
}
The code below is an example for my main.c file:
#include <iostream>
#include "Warning/raise.hpp"
int main() {
std::cout << "Hello, World!" << std::endl;
gpc::warning::raiseError();
return 0;
}
When I run this simple probram in CLion, it compiles and runs perfectly, however when I run the code in the Windows 10 Command Prompt, I get the following error telling me something about the namespaces:
In file included from main.cpp:2:0:
Warning/raise.hpp:10:14: error: expected '{' before '::' token
namespace gpc::warning {
^
Warning/raise.hpp:10:16: error: 'warning' in namespace '::' does not name a type
namespace gpc::warning {
^
main.cpp: In function 'int gpc::main()':
main.cpp:9:10: error: 'gpc::warning' has not been declared
gpc::warning::raiseError();
^
main.cpp: At global scope:
main.cpp:12:1: error: expected '}' at end of input
}
^
I was wondering what I am doing wrong and how I can fix this problem.
Thanks!
Try updating your g++ version to 6.1.0 or higher.
The code doesn't compiles on g++ v5.5.0 even with -std=gnu++17 flag. You can check that here. (Reason: Nested namespaces weren't supported by the compiler then.)
The code shall compile with compiler defaults (without any flags) on g++ v6.1.0 or higher. You can check this here.
You can check your compiler version by running: g++ --version on cmd.
Pro Tip: Locate your CLion's compiler and if it is g++ then add that one to path. (No need of wasting internet data on updating the old g++ compiler!)

boost accumulators example doesn't compile

I installed boost (1.60.0) on Linux Mint 17.3 Rosa and tried to compile the boost accumulator example (http://www.boost.org/doc/libs/1_60_0/doc/html/accumulators/user_s_guide.html) with the gcc compiler (v 4.8.4 64 bit) using this command:
>g++ -o exaccu exaccumulator.cpp -I/usr/local/lib/boost_1_60_0/
Compilation failed with a long list of error messages starting with:
>exaccumulator.cpp: In function ‘int main()’:
>exaccumulator.cpp:22:32: error: ‘accumulators’ has not been declared
>std::cout << "Moment: " << accumulators::moment<2>(acc) << std::endl;
After looking up accumulators.hpp I changed accumulators::moment<2> to moment<2>. This did the trick and the compilation (with the same flags) succeeded. Alternatively, prefixing "accumulators" with "boost::accumulators::moment<2>" worked too. So my question is: Is there something wrong with my installation of boost or is there a typo in the example from the tutorial ?
This seems to be a typo indeed.
You can use the whole boost namespace (bad idea) to make the example compile:
using namespace boost;
accumulators::moment<2>(acc);
Or, like you already did, just remove the accumulators:: specificier and only use namespace boost::accumulators;.
Or just specify it's fully qualified name : boost::accumulators::moment<2>(acc).

GCC C++11 Fails to See #if windows And #if linux (Re-ask)

When using the #if windows/#if linux compilers features in Debian GCC version 4.7.2, I have been unable to get them work when using std11.
Independently, I can get the compiler to accept the if-defines without complaint. I can also get the compiler to use the same code with c++ 11, without any if-defines (and thus not conditionally). But when I run the conditional defines through the same compiler, with the tag for c++ 11, the code is rejected.
Below I have included a simple example, with two alternate mains, and the error I get. The only difference between the two mains are the commented out lines.
Runs:
g++ main.cpp -std=c++11 -o test
The above uses the c++ 11 standard. When running commented main it works perfectly. But when running uncommented main, it fails entirely, giving the error at the far end of this post.
g++ main.cpp -o test
The above does not use the c++ 11 standard. When running either commented main or uncommented main it works perfectly.
Below are the code examples.
Commented main.cpp:
#include <iostream>
//#if windows
//#include "WindowsSolution.hpp"
//#endif
//#if linux
#include "LinuxSolution.hpp"
//#endif
int main()
{
std::cout << myGlobalSolution.out() << std::endl;
return 0;
}
LinuxSolution.hpp:
class LinSolution{
public:
LinSolution(){
}
std::string out(){
std::string ret("Linux solution");
return ret;
}
};
LinSolution myGlobalSolution;
WindowsSolution.hpp:
class WinSolution{
private:
WinSolution(){
}
std::string out(){
std::string ret("Windows solution");
return ret;
}
};
WinSolution myGlobalSolution;
Uncommented main.cpp:
#include <iostream>
#if windows
#include "WindowsSolution.hpp"
#endif
#if linux
#include "LinuxSolution.hpp"
#endif
int main()
{
std::cout << myGlobalSolution.out() << std::endl;
return 0;
}
Below is the error I get when compiling with the uncommented main.cpp, using the c++ 11 flag.
main.cpp: In function ‘int main()’:
main.cpp:13:15: error: ‘myGlobalSolution’ was not declared in this scope
The simple constant linux is a GCC extension and not an official OS constant. The proper constant for Debian is probably __gnu_linux__; you can find a list of them for various systems here. Usually official predefined constants follow the convention of using __ at the start.
Your code works without the standard flag because by default GCC compiles in a GNU language mode (GNU C++) rather than a standard language mode (ISO C++); the GNU language includes extensions (extra language features, and in this case, legacy OS constants). When you pass the -std=c++11 flag you are requesting ISO language mode, which means GNU extensions are disabled, including GNU-only constants. To get both GNU extensions and a specific set of ISO features, try requesting a GNU language standard version instead (e.g. -std=gnu++11 works fine).

Decimal GCC library

I wrote this simple code just to check whether the #include <decimal/decimal> worked:
#include <iostream>
#include <decimal/decimal>
using namespace std;
int main ()
{
cout << "Hello, world!" << endl;
return 0;
}
I compiled it with:
$ g++ main.cpp -o exe
But I get this error message:
In file included from main.cpp:2:0:
/opt/local/include/gcc47/c++/decimal/decimal:39:2: error: #error This file requires compiler and library support for ISO/IEC TR 24733 that is currently not available.
/opt/local/include/gcc47/c++/decimal/decimal:230:56: error: unable to emulate 'SD'
/opt/local/include/gcc47/c++/decimal/decimal:251:5: error: 'std::decimal::decimal32::decimal32(std::decimal::decimal32::__decfloat32)' cannot be overloaded
... lots more similar errors ... (removed by Mats Petersson)
What does this mean? How can I fix it?
When building gcc you can enable support for C's decimal support of TR24732. The C TR creates built-in types like _Decimal64which are given nicer names by including <decimal.h>, e.g., decimal64. These built-in types are also available in C++ when gcc is configured when building to include decimal support.
The decimal support forC++ is defined by TR27433 and would be made available by including <decimal/decimal>. With gcc decimal support in C++ seems to be only available if gcc is compiled with decimal support enabled, i.e., it seems it uses the same built-in types as the C code does.
In either case it seems the decimal support in gcc doesn't cover everything specified by the respective TRs. In particular, last time I checked I/O support was missing.

C++ Hello World trouble on OSX10.8

My profile is updated to point to what i think is the right location:
PATH=${PATH}:/Applications/Xcode.app/Contents/Developer/usr/bin:${PATH}
Compilers are found
[11:39:32] ~: $ which g++
/Applications/Xcode.app/Contents/Developer/usr/bin//g++
[11:39:35] ~: $ which gcc
/Applications/Xcode.app/Contents/Developer/usr/bin//gcc
Hello world looks as follows
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
Fails to execute both from command line and TextMate with
[11:40:15] Desktop: $ g++ untitled.cpp
untitled.cpp:1:20: error: iostream: No such file or directory
untitled.cpp: In function ‘int main()’:
untitled.cpp:6: error: ‘cout’ was not declared in this scope
What else should i have in my path and am missing please?
The answer is, as always, obvious
Install Xcode Command Line Tools
Check your /usr/bin and find there:
Try again .. Everything works automagically
On a side note, it is odd that upgrade from OSX10.7 to OSX10.8 removed these links
This answer is for GCC, but other non-vcc compilers may be the same. When I used GCC iostream was non existent, however iostream.h was, I suggest you try iostream.h and if you run into this problem again with STL headers add the .h.