MSVS C++, how to compile already-preprocessed file with *.i extension? - c++

Related question here: How can I run the MSVC preprocessor and compiler in two separate steps?
I explicitly pre-process a MyFile.cpp (not compile) to a MyFile.i. I want to later "compile" that file (explicitly skipping preprocessing would be nice, but as the related question suggests, it sounds like that is not possible with MSVS.)
PROBLEM: The MyFile.i is an "unrecognized extension", and cl.exe assumes it is an "object file" resulting in a "no-operation". (See Microsoft warning: http://msdn.microsoft.com/en-us/library/zfsbakc5(v=VS.90).aspx, this warning is active for MSVS 2005, 2008, 2010).
I can't find a switch to state that it is a "source file" (not an object file). The related question explicitly used the "MyFile_preprocessed.cpp" convention, but I'd really rather stay with the (more-universal) MyFile.i convention.
QUESTION: Is there a flag where I can compile a MyFile.i with MSVS?

cl.exe has these two flags
/Tc<source file> compile file as .c
/Tp<source file> compile file as .cpp
that lets you compile files with arbitrary extension as c or c++ files
I tried compiling a main.i with the following contents
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world \n";
return 0;
}
with cl /Tp main.i and it works as advertised

Related

C++20 compiling modules with Visual Studio: doesn't compile or import ixx files

Visual Studio 2019 doesn't attempt to compile my .cxx or .ixx files. Here is my .cxx file:
export module greetings;
import std.core;
export std::string get_greeting_text()
{
return "Hello, World!";
}
and here is main:
import std.core;
import greetings;
int main()
{
std::cout << get_greeting_text() << '\n';
}
I do have these flags set: /std:c++latest, /experimental:module. Error messages are
C:\...\main.cpp(2,17):error C2230: could not find module 'greetings'
C:\...\main.cpp(6,2): error C3861: 'get_greeting_text': identifier not found
...but I don't see any line about trying to compile greetings.cxx, so that's got to be the problem. Changing it to .ixx has no effect. What's the fix?
Solution:
Add greeting.ixx to Header Files. (It won't work to add it to Source Files.)
Right-click properties on greeting.ixx, and
Set Item Type to C/C++ Compiler
Set Excluded from Build to No.
Save
Build
It seems a little flaky. Rebuild failed unless I did a Clean first.
Module declaration export module greetings; is not yet working on Visual studio 2019.
You may try to add the following compiler opinions for your greetings.cxx file:
/module:export /module:name greetings /module:wrapper greetings.h /module:output greetings.ifc -c greetings.cxx
Another solution, rename greetings.cxx to greetings.ixx. The .ixx extension is required for module interface files in Visual Studio.
In order to use a different file extension with MSVC so you can use intellisense in Visual Studio Code, there is actually a work-around.
With the cl.exe command, there is an '/interface' option. You can do like so:
In My cl.exe CommandFile:
/interface /Tp UI/ApplicationHost.cpp
/reference ApplicationHost=Build\Debug\ApplicationHost.ifc
UI/WorldEngine.cpp
/link /SUBSYSTEM:WINDOWS
Build/Debug/pch.obj
/Interface - Let's the compiler know there is an ifc module/header coming up.
/Tp - Forces the compiler to recognize it as a C++ file, useful if renaming to .cppm.
/reference - Tells the compiler where to get the dependency information for the following source code.

(MSVC 2017 /WALL & /WX) Including Iostream Produces 800 Warnings

Reviewing material for an optimized C++ course next quarter. The professor for this course is enforcing /WALL and /WX for our project properties. The problem I'm having is that including the Iostream library produces over 800 warnings. Here's the code I'm attempting to run:
#include "pch.h"
#include <iostream>
int main() {
std::cout << "Hello World";
return(0);
}
A few of the warnings that I'm receiving includes:
C4514 'abs': unreferenced inline function has been removed
C4774 'sprintf_s': format string in argument 3 is not a string literal
C4820 'std::basic_ios ...': '7' bytes of padding added after...
Before asking Stack I emailed the Prof to ask about the warnings and was told:
You should be including iostream
If you get 100 warnings you included a header that's not needed
Is there something I'm missing? I know I wouldn't be able to edit source files for iostream as that's not portable coding. I looked around to see if I could explicitly include functions such as cout, cin, etc. Yet, I don't feel like this is the correct solution.
Edit:
A user requested an example of a more explicit warning message in case there was something missing in there. Here are a few:
C415 'abs': referenced inline function has been removed (Project: Hello World) (File: stdlib.h)
C4710 'int sprintf_s(char *const....: function not inlined. (Project: Hello World) (File: stdio.h)
The professor is using GCC through Visual Studio and our settings are pulled from a repository as premade projects.
Your professor is, quite simply, wrong.
This has nothing to do with "including a header that's not needed" (why would that generate warnings?), but with using /WALL, which reveals some flaws in the stdlib implementation there!
This switch is not recommended; quoting James McNellis who gets it bang-on under the above referenced question:
/Wall enables many warnings that, while potentially useful sometimes, are not useful most of the time. /Wall in Visual C++ does not mean the same thing as -Wall on g++ (really, g++ "has /Wall wrong," since it doesn't actually enable all warnings). In any case, in Visual C++, all of the commonly important and useful warnings are enabled by /W4.
I would use /W4 in Visual Studio (and -Wall -Wextra in GCC).
Obviously I can't help you to persuade your professor of this, other than to suggest saying something along the lines of "I asked on Stack Overflow and found out that this is due to /Wall being too strict and generating warnings on Visual Studio's own headers. They suggest we use /W4 instead. . What do you think?"
It is true that you need to #include <iostream>, and it is true that you should never modify the provided standard headers. Also, don't forget to stream a '\n' to end your output line!

Can't compile any c++ file

I have this simple file, called lol.c
#include <iostream>
using namespace std;
int main() {
return(0);
}
From terminal, i type g++ lol.c
This is the output:
In file included from /usr/include/wchar.h:36:0,
from /usr/include/c++/4.9/cwchar:44,
from /usr/include/c++/4.9/bits/postypes.h:40,
from /usr/include/c++/4.9/iosfwd:40,
from /usr/include/c++/4.9/ios:38,
from /usr/include/c++/4.9/ostream:38,
from /usr/include/c++/4.9/iostream:39,
from lol.c:1:
/usr/include/stdio.h:30:22: fatal error: SDL_main.h: File o directory non esistente
#include "SDL_main.h"
^
compilation terminated.
I don't know if the problem is something with SDL, but when i try to run ../configure to install it, i have this:
configure: error: cannot run C compiled programs.
See `config.log' for more details
If is this needed, i can put config.log file too.
There are multiple problems:
you gave a .c extension to a C++ source file; that is wrong, C++ files should have a .cpp (or .cxx, .C, .c++, the last two are a bit frowned upon) extension, or the compiler may try to compile it as C code;
you are invoking gcc instead of g++; this is wrong too, calling gcc on C++ files misses several options required to compile and link correctly (including, but not limited to, linking against the C++ standard library); that was in an older revision of the question, now it says g++;
but most importantly, your build environment is completely broken (some would say "FUBAR"); it is not normal that /usr/include/stdio.h includes stuff from SDL (the fact that it cannot be found is just a minor incident compared to this); you should really purge and reinstall anything related to gcc and to the headers of the C library; look for some libc6-dev package (or similar) to reinstall (be careful not to mess with the C library proper, or your system may be rendered essentially unbootable).
You can't give .c (c extension) to a c++ file.
1 - Change it to .cpp (c++ extension, lol.cpp)
2 - You have to give options to g++ (in your case use -o to create executable file) g++ lol.cpp -o nameofyourprogram
3 - Execute through your terminal ./nameofyourprogram

Compilation error: "stddef.h: No such file or directory"

Whenever I try to compile this code it always ends up with this error:
In file included from /usr/include/wchar.h:6:0,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cwchar:44,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iosfwd:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ios:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iostream:39,
from test.cpp:1:
/usr/include/sys/reent.h:14:20: fatal error: stddef.h: No such file or directory
#include <stddef.h>
^
compilation terminated.
The code I was trying to compile is:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World! :D";
return 0;
}
The error is because your gcc-core package and gcc-g++ are not of the same version. Either downgrade one of them to solve the problem or update both the libraries. Updating both the libraries is the recommended way.
I had this error on a fresh MinGW install, it had nothing to do with the installed packages mentioned in the current accepted answer by "Prasanth Karri". In my case the issue was caused by -nostdinc in my Makefile. I actually only needed that compiler flag when building for a different target platform (not when using MinGW) so I fixed the issue by removing that flag from MinGW builds.
When I was incorporating a software library written in C into an existing demo project(used a C++ mbed library) I encountered this problem. The demo project would compile just fine, but after I replaced the existing main file by my own, this error occurred.
At this point I hadn't yet thought about the fact that the mbed library that I needed was written in C++. My own main file was a .c file that #include the mbed header file. As a result I used my normal C source as if it was a C++ source. Therefore the compiler that was used to compile my main file was the C compiler.
This C compiler then encountered a #include of a module that actually does not exist (within its scope), as it's not a C++ compiler.
Only after I inspected the output of the build log I realised the various source C and C++ files were compiled by more that 1 compiler(the c++ compiler). The project used used compilers arm-none-eabi-c++ and arm-none-eabi-gcc (for embedded systems) as seen below.
Compile log:
Building file: ../anyfile.cpp
Invoking: MCU C++ Compiler
arm-none-eabi-c++ <A lot of arguments> "../anyfile.cpp"
Finished building: ../anyfile.cpp
Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc <A lot of arguments> "../main.c"
In file included from <Project directory>\mbed/mbed.h:21:0,
from ../main.c:16:
<Project directory>\mbed/platform.h:25:19: fatal error: cstddef: No such file or directory
compilation terminated.
Of course in a C++ environment cstddef exists, but in a C environment cstddef doesn't exist, in stead it's just C's implementation of stddef.
In other words, cstddef does not exist in the C compiler.
I resolved this problem by renaming my main.c file to main.cpp and the rest of the code compiled smoothly too.
TLDR/Conclusion: When building a C++ project, avoid mixing C files with C++ files(sources and headers). If possible rename .c files to .cpp files to use the C++ compiler in stead of the C compiler where required.
In order to update it, follow below.
If you are on Windows, just run these on command prompt or powershell
Update the package list: mingw-get update
After updating the package list, run: mingw-get upgrade
Source: How to update GCC in MinGW on Windows?
This problem was solved for me as I installed codeblocks with mingw compiler then I copied the mingw folder from codeblocks to C drive and added
C\mingw\bin to the environment variables.
If you try to compile and see a message like, "fatal error: stddef.h: No such file or directory", the error is because your gcc-core and gcc-g++ packages are not of the same version. Rerun the Cygwin install and make sure that you select the highest numbered versions of gcc-core and gcc-g++.
After installing the C++ compiler with MinGW I encountered this problem as well. Apparently, you have to also install mingw32-base. Go to C:/MinGW/bin/mingw-get.exe (my path) and check it for installation at the Basic Setup tab.

CUDA syntax error '<'

in my test.cu file (cu file item type is CUDA C/C++)
__global__ void foo()
{
}
void CudaMain()
{
foo<<<1,1>>>();
}
and in my test.cpp file
#include "mycuda.cu"
int main()
{
CudaMain();
return 0;
}
and compilator send me error "error c2059 syntax error ' <' " in test.cu file
Inclusion of CUDA source files in a C++ file doesn't work because this simply makes the CUDA source part of the C++ program code and regular C++ compilers do not understand CUDA syntax extensions. If you still want to keep your CUDA code separate from the non-CUDA C++ code, then you might want to look into separate compilation. CUDA source code can be compiled to regular object files, that can then be linked with other object files to produce an executable.
Modify the C++ code to read:
extern void CudaMain(void);
int main()
{
CudaMain();
return 0;
}
Compile the CUDA file with nvcc, the C++ code with your C++ compiler and then link the resulting object files with nvcc (you may also need to specify the standard C++ library in the link command):
$ nvcc -c -o test_cuda.o test.cu
$ g++ -c -o test_cpp.o test.cpp
$ nvcc -o test.exe test_cuda.o test_cpp.o -lstdc++
Edit: your question is about VS2010. May be you have to create custom build steps there.
Based on the thread here: https://forums.developer.nvidia.com/t/cuda-build-error/52615/4
Your test file extension should be .cu as well, but if you're using MSCV rename does not enough you should create a new CUDA C/C++ source module in your VS project.
Also you should put spaces between the <> operators like.
foo< < <1,1> > >();
Because C++ cannot parse the <<<>>>.
I know this is an old question but I was searching around and it jogged my memory for a solution that hasn't been mentioned.
The nvcc help offers:
--x {c|c++|cu} (-x)
Explicitly specify the language for the input files, rather than letting
the compiler choose a default based on the file name suffix.
Allowed values for this option: 'c','c++','cu'.
So although it's a bit of a blunt tool, you can do:
nvcc my_source.cpp -x cu ...
and it'll compile the .cpp as if it was named .cu (ie as CUDA).