Why doesn't PRIu64 work in this code? - c++

As per this answer, I tried printing a uint64_t, but it gives me an error:
error: expected ``)' before 'PRIu64'
Following is the minimal code showing what I am trying to do:
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <cstdio>
class X {
X() {
uint64_t foo = 0;
printf("%07" PRIu64 ": ", foo);
}
};
int main() {}
This minimal code compiles, but my actual code does not. However, I have tried with the 2 lines inside X::X() exactly the same in my actual code, and that does not work.
What should I look for to debug this further? My actual code also #includes other headers. Could that be causing the problem? Does order of including the headers matter?
Edit
PRIu64 is defined as follows on my machine:
# if __WORDSIZE == 64
# define __PRI64_PREFIX "l"
# define __PRIPTR_PREFIX "l"
# else
# define __PRI64_PREFIX "ll"
# define __PRIPTR_PREFIX
# endif
# define PRIu64 __PRI64_PREFIX "u"

In C++ the macros are not automatically defined just by including the file.
You need to add the following:
#define __STDC_FORMAT_MACROS 1
before
#include <inttypes.h>
How to printf uint64_t? Fails with: "spurious trailing ‘%’ in format"

One other possibility for this issue I just found in my own code is if another header already pulls in <inttypes.h> before you define __STDC_FORMAT_MACROS. For example:
Utils.h (Perhaps originally written for C, as it was in our case):
#include <inttypes.h>
// ... Function declarations
MyFile.cpp:
#include "Utils.h"
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
Since inttypes.h has already been included by Util.h, the compiler doesn't include it again, and doesn't see the declaration of __STDC_FORMAT_MACROS.
The solution is either to edit Utils.h to include #define __STDC_FORMAT_MACROS, or to make sure to define it before doing any includes in MyFile.cpp.
#define __STDC_FORMAT_MACROS
#include "Utils.h"
#include <inttypes.h>
The original setup actually compiled just fine on GCC 4.8 on Ubuntu, but failed with an old ltib GCC 4.3 toolchain for PowerPC, which made it all the more perplexing at first.

PRIu64 is not defined where you use it.
Replace it with the string "llu" and your code will compile (but that is not a fix, it just demonstrates the problem)
Maybe the include is missing. Maybe over zealos include guards and it being included without the magic token block the define. Maybe your pch is busted.

If you are on android JNI platform. Put this in your Android.mk:
LOCAL_CPPFLAGS := -D__STDC_FORMAT_MACROS

Related

Preprocessor division by zero while evaluating `QT_CONFIG(printer)`

Compiling with g++ (from Makefile generated with qmake) using the line
#if !QT_CONFIG(printer)
// do something
#endif
gives a preprocessor error on both g++ (7.3.0)
test.cpp:25:6: error: division by zero in #if
#if !QT_CONFIG(printer)
and clang (6.00)
test.cpp:25:6: error: division by zero in preprocessor expression
#if !QT_CONFIG(printer)
^~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:84:30: note: expanded from macro 'QT_CONFIG'
#define QT_CONFIG(feature) (1/QT_FEATURE_##feature == 1)
~^~~~~~~~~~~~~~~~~~~~~
1 error generated.
where clang++ gives the more detailed output. printer is not enabled, thus the macro as recommended to do conditional compilation. The QT version is 5.9.5. Any suggestions (wrong usage?) appreciated.
I don't think you should focus on that macro. The point of that macro is to simply crash your compilation code when QT_FEATURE_printer is zero. The code was not designed to work otherwise.
Instead of using the macro conditionally try to find out why QT_FEATURE_printer is zero and include / configure dependencies to change that (it seems to be definend in printsupport/qtprintsupport-config.h).
This is what happens if you have updated your qt sources to something using a new feature without running configure again. When you run configure the new features are set.
This is fixed in Qt 5.12.3. The newer version of notepad.cpp begins:
#include <QFile>
#include <QFileDialog>
#include <QTextStream>
#include <QMessageBox>
#if defined(QT_PRINTSUPPORT_LIB)
#include <QtPrintSupport/qtprintsupportglobal.h>
#if QT_CONFIG(printer)
#if QT_CONFIG(printdialog)
#include <QPrintDialog>
#endif // QT_CONFIG(printdialog)
#include <QPrinter>
#endif // QT_CONFIG(printer)
#endif // QT_PRINTSUPPORT_LIB
#include <QFont>
#include <QFontDialog>

Why use preprocessor #if statements instead of if() else?

I see this being done all the time for example in the Linux Kernel. What is the purpose of using the preprocessor commands vs just normal C++ if else block? Is there a speed advantage or something?
A preprocessor changes the C/C++ code before it gets compiled (hence pre processor).
Preprocessor ifs are evaluated at compile-time.
C/C++ ifs are evaluated at run-time.
You can do things that can't be done at run-time.
Adjust code for different platforms or different compilers:
#ifdef __unix__ /* __unix__ is usually defined by compilers targeting Unix systems */
#include <unistd.h>
#elif defined _WIN32 /* _Win32 is usually defined by compilers targeting 32 or 64 bit Windows systems */
#include <windows.h>
#endif
Ensure header file definitions are included only once (equivalent of #pragma once, but more portable):
#ifndef EXAMPLE_H
#define EXAMPLE_H
class Example { ... };
#endif
You can make things faster than at run-time.
void some_debug_function() {
#ifdef DEBUG
printf("Debug!\n");
#endif
}
Now, when compiling with DEBUG not defined (likely a command line parameter to your compiler), any calls to some_debug_function can be optimized away by the compiler.
Preprocessor is run before the compilation pass, so the compiler won't even see anything that was in the not-taken #if branch.
#if DEBUG
int a;
#else
double b;
#endif
gcc -c -DDEBUG=1 file.c will see "int a"
gcc -c file.c will see "double b"
Preprocessor allows you to actually cut out or paste in to your source file, code to be compiled. If its cut out, its gone, its like a comment, does nothing, is not compiled, produces no code in the binary. Devs will often use this technique to add code only in debug build for debugging purposes or for adding or excluding code for specific operating systems.

vim clang complete doesn't see some functions of opengl

I have vim and clang_complete installed but for some reason when I try to auto complete it doesn't see some of OpenGL's functions, such as glBindBuffer, or glEnableVertexAttribArray. I press CTRL + X and CTRL + U to force the auto complete and it shows the function names and parameters, but it's just missing some of the functions.
Even with glfw, I try auto completing GLFW_KEY_ESC but it's not there, I don't know why, it just says User defined completion (^U^N^P) Pattern not found
Does anyone have a solution to this problem? It's very annoying because I use these functions a lot and need the auto complete.
Thanks.
EDIT: Also my include header files are this:
#include <iostream>
#include <string>
#include <GL/glew.h>
#include <GL/glfw.h>
#include <glm/glm.hpp>
I'm on Arch Linux x64 by the way.
All right I found the answer. Because of clang_complete not being able to complete the arguments created by GLEW (because the functions are defined as #define FOO somefunction, and not defined as: #define FOO(arg1, arg2, arg3) someFunction(arg1, arg2, arg3))
To fix this, you have to add this option to your ~/.vimrc file.
let g:clang_complete_macros = 1
Now, you'll get function completion, but still no argument completion. So, you'll have to replace GLEW (sadly) with
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
This will finally complete the arguments, although, if there's an alternative to doing fixing this problem, I'd like to hear.
To expand on zero57's answer.
You could add a clang_complete specific compile flag to define a macro for clang_complete
let g:clang_user_options = ' -DCLANG_COMPLETE_ONLY'
Then in your code you could use
#ifdef CLANG_COMPLETE_ONLY
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
#else
#include <GL/glew.h>
#endif
This isn't a perfect solution but clang_complete should now complete your parameters and when compiling you will be using glew. This worked for me with the YouCompleteMe (YCM) plugin so I assume it works with clang_complete.

GCC cross-compiler for VxWorks can't compile C++

I'm trying to port a Linux library to run on VxWorks. I have successfully built binutils and gcc to target i486-wrs-vxworks and I can successfully build a simple C program. However, when I try to compile C++, things break.
I have a simple Hello World program:
#include <string>
#include <iostream>
int main()
{
std::string s = "Hello World";
std::cout << s << std::endl;
return 0;
}
To build it, I call:
i486-wrs-vxworks-gcc -I/home/kyle/vxworks-6.9/target/usr/h -I/home/kyle/vxworks-6.9/target/usr/h/c++ hello.cpp
This always fails with the message:
In file included from /home/kyle/vxworks-6.9/target/usr/h/c++/cerrno:4:0,
from /home/kyle/vxworks-6.9/target/usr/h/c++/xlocnum:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/ios:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/ostream:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/istream:4,
from /home/kyle/vxworks-6.9/target/usr/h/c++/string:4,
from hello.cpp:1:
/usr/local/lib/gcc/i486-wrs-vxworks/4.6.4/../../../../i486-wrs-vxworks/include/yvals.h:4:24: fatal error: yvals.h: No such file or directory
If I go look inside /usr/local/i486-wrs-vxworks/include/yvals.h, this is what I see:
/* yvals.h values header for conforming compilers on various systems */
#if (defined(__cplusplus) && defined(__GNUC__))
/* GCC C++ has it's own yvals.h */
#include_next <yvals.h>
#else /* __cplusplus && __GNUC__ */
#ifndef _YVALS
#define _YVALS
#ifdef _NO_WINDRIVER_MODIFICATIONS
#include <stdarg.h>
#endif
...
It appears that there is another yvals.h that needs to be included, but I can't find it anywhere. Did I just fail at building gcc correctly, or is there a way to fix this?
Which version of VxWorks are you using for this?
I have a fuzzy recollection that when upgrading VxWorks versions in the past there was a syntax error in yvals.h that was I needed to work around and it was fixed in a subsequent version.
Also, you can get the gcc cross compiler pre-built from WindRiver. Just login to windriver.com/support with your licence number and head to "Downloads" for your product version.
I went through a recent cross compiling nightmare myself (not VxWorks related) except that instead of yvals.h, I was having grief with stddef.h. The problem turned out to be that I needed to specify the include paths for the system header files.
Here are the steps it took me to solve my error messages. Feel free to modify as appropriate.
Create a file foo.c
#include <stddef.h> /* The problem header file (yvals.h for you?) */
int main (void) {
return 0;
}
Compile it with your compiler of choice
$(CC) foo.c -E
Note the include paths it uses and set them as your system header file list using the
-isystem <include path>
option.
Hope this helps.

Use of #include <iostream.h>

I am working on an older project that still has the deprecated "#include iostream.h" inclusions. I understand that iostream.h is deprecated and should not be used, but some of the systems that this code has to run/compile on are old solaris machines running CC and do not have iostream available. My question is: how can I make my more modern g++ compiler accept the iostream.h inclusions.
EDIT: The compilier cannot find the iostream.h file so I am assuming that none of the .h versions of the library are available to g++.
The easiest solution is probably to create a local header file called iostream.h which just includes <iostream> and imports the namespace std. Then, in order for the compiler to allow #include <iostream.h> you add the local path to your include file search path. For g++, this works:
g++ -I local_folder [other flags] …
Incidentally, your remark about
… the deprecated "#include iostream.h"
isn’t quite correct: this isn’t deprecated because it has never been legal C++.
I'd take a step back and write another intermediate header you use everywhere instead that does something like:
#if defined(sun) || defined(__sun)
# if defined(__SVR4) || defined(__svr4__)
/* Solaris */
#include <iostream>
# else
/* SunOS */
#include "iostream.h"
# endif
#else
/* Sane, modern system */
#include <iostream>
#endif