I struggled to find a clear answer on the first Google page.
I have troubles understanding the term "Language standard". I mean, the new standard should be implemented on a software level, right? It's not just a list of things discovered that users can now do, right?
I use delegating constructors, get a warning:
[Warning] delegating constructors only available with -std=c++11 or -std=gnu++11
Though things seem to work the way I want them to. Is such warning critical? If so, how do I get rid of it?
Dev-Cpp is just IDE (frontend) for coder and behind it sits MinGW with GCC 4.9.2 as compiler*. So every time you click "Run" or "Build" it is GCC to do the dirty job. GCC by default uses C++03 standard and to use newer one you have to tell it explicitly via compiler flag -std=c++11. You can change it in Tools->Compiler Options->Settings->Code generation->Language standard (-std).
I am not sure why delegating constructors could work without C++11 (probably some GCC feature), but for sure you will not be able to use C++11 libraries without -std=c++11. It will also get rid of the warning.
(* Assuming you used default Dev-C++ installer.)
Related
I am working on a project that uses a GCC library (SFML), which is not available for clang, as far as I know. I am using COC with vim for code completions, but for C++ it needs clangd. Is there a way to use GCC as my compiler, but still use the clangd language server?
I have also heard that there may be a way to make clang recognize GCC libraries/headers, but I've never been able to make it work right. If somebody could point me in the right direction there that would be helpfull too. But I'm used to GCC (I've been using it since I started programming C++), so being able to use clangd and GCC would be preferable.
Yes it is. I do it with ccls (which is clang based as well).
Given my installation of clang is not the standard one (I compile it, tune it to use libc++ by default, and I install it somewhere in my personal space) I have to inject paths to header files known by clang but unknown by other clang based tools.
I obtain them with
clang++ -E -xc++ - -Wp,-v < /dev/null
Regarding the other options related to the current project, I make sure to have a compile_commands.json compilation database (generated by CMake, or bear if I have no other choice), and ccls can work from there. I expect clangd to be quite similar in these aspects.
Ops, answered the wrong question.
But for those who use ccls:
create a .ccls file in your project directory and append --gcc-toolchain=/usr to it.
use this tool to generate a compile_commands.json file
see https://github.com/MaskRay/ccls/wiki/FAQ#compiling-with-gcc
I'm attempting to port a large set of modules from AIX to Linux. Unfortunately, the AIX xlc compiler allowed you to define a static function and use it prior to the definition with no prototype. Not good, but at least you get the proper static scope. In any case, the code is there, and I can't get it to compile on Linux without explicitly adding a static prototype.
So, is there any way to inhibit the "static declaration follows non-static declaration" error in gcc (or make it a warning instead of a hard error), or do I have to edit each of these modules to add prototypes wherever they're missing? As I understand it, this is a case where the standard behavior is undefined - so it's kind of nasty if gcc wouldn't allow you a way to relax its internal standard to allow for code that compiles elsewhere, no...?
This has been a hard error in GCC since 2004. The only option to get this to compile is to downgrade to a really old version of GCC. I verified that GCC 3.4.6 still compiles this, but GCC 4.0.3 does not.
Of course, depending on your target, getting GCC 3.4 to work might be close to impossible.
From some Googling around it seems that clang's support for windows has been improving recently and boost's support for clang may also have improved. But I'm fairly new to all this heavy-lifting compiler configuration stuff and new to boost, so I'm not sure what the current status really is.
I'm trying to run the command:
b2 --build-dir=build toolset=clang --build-type=complete stage
as suggested in section 5.2.4 in www.boost.org/.../getting_started/windows.
This does work to some extent, but watching the logs being printed to screen I see a few worrying things:
statements starting clang-linux.compile.c++.... even though I am on windows.
12 warnings generated. (or similar) perhaps always these are -Wunused-local-typedef, but I'm not sure.
2 warnings and 8 errors generated (or similar) surely if there are errors the build has failed? How am I supposed to know which component of boost has not built properly and what can I do to fix this?
I'm not clear whether I need MSVC the compiler, Visual Stufio the IDE, and/or MinGW and whether I need to manually set flags to pass to the compiler? Perhaps clang+boost is not ready for windows yet?
Ultimately I want to use boost.python, and at a later date maybe boost.coroutine.
Presumably if I want to use clang for my own projects I need to compile boost with clang too?
bootstrap --with-toolset=clang-win
b2 toolset=clang-win
Make sure that clang.exe is on your PATH.
With GCC and clang, I've been able to use SCons 'TryCompile' feature to build a simple configure check to determine if the currently configured compiler supports a given compile flag. Basically, clone the env, add the flag in question to CFLAGS, CCFLAGS, or CXXFLAGS, as appropriate, execute TryCompile, and if the TryCompile succeeds, then the flag is supported and we can add it to the real env.
This works perfectly with gcc, because unknown flags are errors and the compiler exits with a non-zero status.
With clang, it works reasonably well too: clang by default treats unknown errors as warnings, but if you pass it -Werror it will turn unknown flags into errors. So my wrapper around TryCompile just always passes -Werror along with the flag to be tested if it knows we are using clang.
However, this all falls over with the Microsoft toolchain because as far as I can discover, there is no way to convince the compiler to treat unknown flags as errors: they are always warnings, even if you pass the flag to make warnings errors. Since the compile exits cleanly wither or not the flag is accepted, TryCompile always succeeds. See this question for details on the various attempts I have made to get MSVC to exit with a non-zero status.
Any ideas on how I can make this work? Is there another SCons facility that I'm overlooking that can do this job for me? Should I interpose on TryCompile on MS platforms and parse the compiler output rather than examining the exit status. I'm really happy with using TryCompile for configure time flag detection with clang and gcc, but if I can't get MSVC to cooperate I'm going to need to abandon this whole approach, and I'm pretty loathe to do that since it is working so well so far.
Leave it to Windows to rain on the parade once again :) Obviously the Windows compiler always returns success, irregardless of what happens.
I can think of several options that you could try.
First of all, SCons provides a Multi-Platform Configuration (Autoconf Functionality) which may help you achieve the same result. It doesnt include anything for compiler options, but does at least includes the following:
Checking for the Existence of Header Files
Checking for the Availability of a Function
Checking for the Availability of a Library
Checking for the Availability of a typedef
Adding Your Own Custom Checks
Another option would be to build some sort of a dictionary with the Microsoft compilation options. You would probably need one dictionary per compiler version. This particular option would probably take a long time to prepare, and probably wouldnt be worth it.
Another option would be to use the Object() or Program() builder instead of the TryCompile() builder, and try to catch the failure and react accordingly. Im not sure if SCons allows you to catch compilation failures as an exception and carry on if it fails, but its worth checking into.
We have Oracle 11 running on HP-UX 11.31 and gcc 4.4.3. It seems that there is no way to link to occi, because it was built with aCC. Is there any workaround for this?
I had the silly idea that I could somehow build a library that basically proxied the connection - build the library with aCC in some way that could be linked to by gcc. Is this possible?
No, there isn't a way around that.
Different C compilers have interchangeable code using a standard ABI. You can mix and match their object code more or less with impunity.
However, different C++ compilers have a variety of different conventions that mean that their object code is not compatible. These relate to class layout (especially in multiple inheritance hierarchies and the dreaded 'diamond-of-death'), but also in name mangling conventions and exception handling. The name mangling schemes are deliberately made different so that you cannot accidentally link objects from one compiler with another.
Generally, if libraries are built using a C++ compiler, you have to link your code using the same - or at least a compatible - C++ compiler. And that almost invariably means a compiler from the same family. For example, you might be able to use G++ 4.5.0 even if the code was built with G++ 4.4.2. However, you won't be able to mix aCC with G++.