I'm not really sure why "cout" and "endl" are not being recognized. Any help would be great!
The error is:
and the code is:
The fact that iostream has a red squiggle underneath it is a near certainty that you have something wrong with your environment (such as compiling with a C compiler rather than a C++ one, for example).
You need to fix that, since cout and endl are defined in that header. I'd start by hovering the mouse over the iostream text and see what the tooltip shows you.
If it cannot find the file iostream then you're either not using a C++ compiler, or your environment is severely damaged.
Either way, it's not a correct C++ environment.
Things to look in to are (to start with):
Examine the file extension. Using *.c instead of *.cpp may use a C compiler rather than a C++ one, for example).
Examine the output of your compilation, if available. You will hopefully be able to tell which compiler is being used.
If you are sure you're using a C++ compiler:
You might have a funny character in your iostream string. You could totally delete that line and retype it (don't edit, it may not get rid of the funny character).
Try a different header (like cstdlib) to see if it has the same problem.
Last-straw solution would be re-installation of your development environment, in case things are so damaged it's unrecoverable.
Related
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
But then, there comes the error: (Make:47 missing endif. Stop).
If I comment out those three lines of code, the error becomes: (<math.h> no such file or directory).
My system is OpenSUSE Leap 15.4; gcc version 7; gnu make version 4.2.1-7.3.2.
I think I have installed all the needed packages. However the errors persist. Any help?
I primarily want to address this part of the question, as the underlying issue has been addressed elsewhere, multiple times:
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
I started to write "Google led you astray", but I think it's more likely that you seriously misunderstood what it led you to. And perhaps you happened to choose poor results.
The error message indicates that you put those lines in your makefile, but they are wholly inappropriate for that. Don't put them there.
The lines are C preprocessor directives that have been stripped of their leading # characters. You would use them by restoring the # characters ...
#ifdef __linux__
#define _finite(v) (__builtin_isfinite(v))
#endif
... and putting the resulting lines into one or more of your C source files. BUT DON'T! Those lines are unnecessary and at best unhelpful.
You do need to #include <math.h> in each C source file that contains a call to isfinite(), because that is the header that provides a declaration of the function. Since C99, functions must be declared before they are called (and it was good practice well before then).
Other than that, with GCC and many other traditional-style Unix C compilers, you need to explicitly include the math library in your link when you need any of the functions it provides. That would involve adding -lm to your makefile, at the end of the gcc command that builds the final executable. This is covered in gcc will not properly include math.h, and many other duplicates on this site.
I have a make project creating binaries using various back-ends…
→ C, C++, csharp, java… on linux using mono csharp compiler, gcc, etc…
if I choose a single back-end (example csharp) by open a XXX.cs file than the make-output-error parser working OK… this mean error-output is parsed proper and I can jump to the error right away…
if I choose the toplevel make… (open vim without file on a toplevel directory) than the make-output-error parser does not work properly.
I discovered that the vim errorformat variable has changed between 1. and 2.
and now my question: how I can tell vim to recognize the error-output from C,C++,CSharp… and Java during run of the toplevel make ?
Whatever filetype plugin you have for C# is probably changing the value of :help 'errorformat' to work with C# compilers while you are left with the default value when running your top level make which, I assume, outputs errors as-is, without any filtering.
In order for Vim to interpret correctly the potentially mixed output of all your compilers you could:
set errorformat to a value that would work with all those formats,
or add a step to your build process that unifies every native output format into a single format that Vim can interpret without effort.
First option, find the errorformat values used by every compiler and prepend them to the default value at startup:
set errorformat^=<efm for c#>
set errorformat^=<efm for cpp>
...
Second option, I've been thinking for many years about writing a program that would do just that but never found the time to even write a README.md. If such a thing doesn't exist you will have to sed and awk your way on your own I'm afraid.
I'm talking about this things:
warning: ds segment base generated, but will be ignored in 64-bit mode
I know that -w option can be used to suppress warnings in NASM, but from the list of warnings showed by the help menu nothing fits this type of warning. And -w-all gets rid of everything, except this.
Any way of doing this?
Since that particular error doesn't seem to be one of the suppressible ones (as you've stated, I'd just use sed as a post-processing step, piping the output through something like:
sed '/^warning: .. segment base generated, but will be ignored in 64-bit mode$/d'
Even if you're using nasm on Windows, you can still get the GNUWin32 port of sed to do the job.
And before you complain about this being a kludge, you should know that some of my greatest achievements were kludges, and many of them have out-lived my more well-designed code.
:-)
In eclipse, if you change a variable name, eclipse will automatically change this variable's name in whole project.
Can vim do that too?
Vim is a text editor, not an IDE. Though it has some notion of a filetype's syntax, it does not fully parse nor understand the language's full syntax. Refactorings, even simple ones like Rename identifier, do require such full understanding (to be 100% correct).
There are attempts at refactoring support in Vim, most language-specific, some also generic. But I'd advise to keep using a real IDE for this (for its comfort, safety, and correctness), and instead use Vim only for simple, text-based replacements, using :bufdo substitute/... or macros, as described here.
Sort of.
Because it is not an IDE and thus doesn't understand anything about your code, Vim only sees text where you see a variable name. It can't infer anything from the scope or whatever. Without the use of some external program, renaming a variable in Vim is usually done with a buffer-wide or project-wide search/replace.
Since you didn't tell us what language you are working with we can't tell you if there is a language-specific solution for your needs.
try this plugin -> Clighter, for c-family rename-refactoring. It's based on clang, but there are limitations. Still in development
I'm working on getting a Visual C++ 2005 solution to compile in unicode. However, In some of my projects (but not all), I get errors in the form:
1>.\CBitFlags.cpp(25) : error C2065: 'L' : undeclared identifier
and the line of code in question is:
LOGERROR(UTILITY, L"Tried to use object to store %d flags, when max is %d",
I am BAFFLED. It seems to be treating L as an identifier when L is part of the language syntax. Does anyone know if there is some flag somewhere that has to be enabled in the project or compile settings that if not toggled would cause this? The really weird part is it isn't all of the occurrences of this, it's only some of them. It does seem to be consistent within a single project, but I have entire projects compiling fine, and others that fail miserably like this.
The problem is almost certainly inside of the LOGERROR macro. Look at how it treats that second paramater. Expand the macro yourself, it is easy to overlook small errors in macros sometimes.
Visual C++ 2005 does support the L syntax for wide strings, and doesn't need any special flags or anything to support it. So most likely, your problem is elsewhere. Perhaps the definition of LOGERROR or UTILITY. Or a missing semicolon previously, or.... It could be anything which causes the compiler to expect something other than a string literal when it gets to the L.
Since this appears to be something used in a macro, I think you should look at the definition of the LOGERROR and UTILITY macros and at what they expands to in the context of your code. Use the /P compiler option to preprocess your files without proceeding to the compilation step, and then look at the result to see what the compiler's really seeing.
I can reproduce the error you see if I have a space after the L:
wchar_t const* foo = L "foo";
Are you sure you've copied and pasted the actual code that's giving you trouble?