New C++ Project in Xcode 10.2 is not building - c++

Have a macOS Mojave 10.14.6 with Xcode 10.2 (10E125)
I simply created new c++ project in this way:
Xcode -> New Project -> Command Line Tool -> [C++ Language] ->
Next/Done
And it's not building at all. I even not touched code.
Here is errors
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:74:64: Use of undeclared identifier 'strchr'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:81:75: Use of undeclared identifier 'strpbrk'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:88:65: Use of undeclared identifier 'strrchr'; did you mean 'strchr'?
etc...
NOTE 1: I tried to create same project but with C Language. And C Project working well until I'm adding #include <vector>. With vector I have same errors as in case with new C++ project.
NOTE 2: I don’t think, that something is not been installed on my system. Since the same code works well with Objective-C project. (and I do not want to use h+mm I want to use hpp+cpp, if that is the problem)

I have your same setup, and it doesn't occur to me. Was you XCode installation like this from the start, or did it happen after you've done a couple of projects?
If it happened later on, my reasoning is this; once I used the fix button inside of XCode, but, instead of fixing my own code, it went and modified a system header. Perhaps this is what happened to you as well?
If that's the case, you need to reinstall the whole party.

Related

Erroneous "Unable to resolve identifier" in Netbeans

My program compiles fine, but Netbeans tells me "Unable to resolve identifier to_string."
I tried everything in "Netbeans 7.2 shows "Unable to resolve identifier" , although build is successful" and I set the "C++ standard" to "C++11" in the code assistance options.
This is the only function giving this problem so far. It is however also the first C++11 feature I am using, which leads me to believe it has something to do with Netbeans not understanding that I am using C++11, although I specify it explicitly in the code assistance menu.
Minimal example:
#include <string>
int main() {
std::to_string(1);
}
EDIT: the same problem arises where using nullptr
EDIT2: I suddenly realized it might be important to mention that I do not use a generated Makefile, but SCons.
I know this question is seven months old but since it came up as the second result to a google search I'll tell the answer I came up with. For Netbeans at least. Go to your project properties and make sure you have you "C Compiler"->"C Standard" set to C11, and your "C++ compiler"->"C++ Standard" set to C++11. You have to set BOTH or it will still give false errors!
This will solve the problem:
Right click on "Project".
Select "Code Assistance".
Clean C/C++ cache.
Restart IDE.
Autocomplete and sometimes even syntax highlighting are always faulty with C++. The more you go in depth with C++ and C++11, the more Eclipse and Netbeans will start underlining everything with a red wavy line. Some of my (correct and perfectly compiling) programs are a huge red wavy line. I suggest you disable error markers altogether and you keep autocomplete, but in many cases it just won't work and you have to make the best of it.
I had the same situation. This was occurred because I used .c file instead of .cpp
for Netbeans 8.2 (on Linux) only the following worked for me: Tools -> Options -> Code Assistance -> Macro Definitions:
change:__cplusplus=199711L
to:__cplusplus=201402L
for C++14
or to __cplusplus=201103L
for C++11
I did all the above but what did the trick for me was recognizing that the Makefile had g++ rather than g++ -std=c++11.
To resolve c++17 related 'Unable to resolve identifier' in latest netbeans 8.2 or 9 version, one may need to set the macro definition __cplusplus=201703L as the default C++14 standard macro definition unable to resolve those unexpected error messages appeared in the editor.

C++ Error RC2104 trying to compile PuTTY-PSCP (for Windows) on Visual Studio 6.0

I was about to use PuTTY Development source code for Windows to create my own client application (found here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) but as I tried to compile the PSCP project (SCP Client), I got the following error :
C:\work\2015\Putty\windows\version.rc2 (18): error RC2104 : undefined
keyword or key name: BINARY_VERSION
I've been going through the various posts involving this error but didn't find anything working :
error RC2104: undefined keyword or key name: DS_SETFONT :
On this post I noticed that the version of MSVC was brought up so I figured maybe something has to be done to get PuTTY to work on VC 6.0 ?
Also I tried to add #include <windows.h> in both version.rc2 (version.rc2 is used for inclusion in all .rc files) and pscp.rc, none worked.
I'll be quick to answer if you need any information (project properties, source code...)
USING Visual Studio 6.0 with SP6 on Windows 8.1
Probably, wrong version.h is seen.
Correctly, the file version.h in the project folder should be seen.
Please try to modify version.rc2:
#include "version.h"
to
#include "..\\..\\..\\version.h"
At least, resource compiler will end successfully.
If you search through the PuTTY source files, you'll notice that BINARY_VERSION is defined in version.h and used in windows/version.rc2, which #includes version.h.
Since your version.rc2 isn't seeing version.h, try to figure out why: Is version.h still present and does it still contain BINARY_VERSION? Are your include paths correct? Is there another version.h somewhere else in your include path that's getting picked up by mistake?
Which source code are you using ?
I tested latest(0.64) "Release source code for Windows".
direct link is
http://the.earth.li/~sgtatham/putty/latest/putty-src.zip
I had tried to compile using VC++ 6.0 Professional with SP6, on my PC,
running Windows XP SP3.
After extracting putty-src.zip to somewhere with keeping folder
structures, did you correctly opened 'putty.dsw' in "putty-src\windows\MSVC" folder?
You should be find in 7 projects in 'FileView' tab of the workspace
in Visual Studio 6.0.
You can switch active project to 'pscp' with context menu via
right button click on 'pscp' project.
With modified version.rc2, resource compiler finished successful.
But two (sshshare.c, winsftp.c) C source files failed compiling
with 20 errors. in 'pscp' project.
Errors while compiling 'winsftp.c' is caused 'TIME_POSIX_TO_WIN'
and 'TIME_WIN_TO_POSIX' macros.
'ull(unsigned long long)' is a 64-bit integer-suffix, newly defined in C99. Since C99 standard is not support on VC6, then caused errors.
I had temporally modified
11644473600ull ------> ((ULONGLONG)11644473600)
10000000ull ---------> ((ULONGLONG)10000000)
and confirmed errors are cleared. (Sorry, no validation the code is correctly generated)
3 errors while compiling 'sshshare.c' is also caused another macro.
I cannot understand why you got 116 errors.

Debugging SFML Project in Xcode - Install to Blame?

I followed the instructions to set up SFML here. When I check my /Library/Frameworks folder, all the SFML stuff seems to be there. However, when I check out a project my group is working on using SFML, and when I build, I get a ton of errors. These errors do not exist for my other group members. I think (some of) my errors are caused by SFML not recognizing sf::Input as a type.
Here is my code for one of the header classes in my project:
#pragma once
#include "Mover.h"
class InputMover : public Mover
{
public:
InputMover(const sf::Input* pInput);
//error here - expected unqualified-id before * token
protected:
const sf::Input* m_pInput;
//error here - ISO C++ forbids declaration of Input with no type
};
The parts without errors have been taken out. What do you think the problem is?
EDIT, SOLVED:
The problem was that I installed SFML with makefiles before I just did a copy-install. Some files were conflicting. I tracked down the installed files and deleted them. This seemed to fix the problem.
To use the SFML classes you need to include their definitions.
Add #include <SFML/Window/Input.hpp> to the top of your file.
Also note that to use SFML you must also link to the CoreFoundation, Cocoa and OpenGL frameworks, as well as to libfreetype.

XCode 4, Armadillo and the XCode standard library

I'm attempting to compile my (very basic) program that uses armadillo in XCode 4, but it is having problems with compiling armadillo.
When I do just a simple makefile and clang++, it compiles without problems, but using XCode it seems to be having serious issues, popping up with all kinds of errors and warnings, (when I build it without XCode, even using -Werrors, I get nothing, it builds clean).
Here are some of there errors:
const int __ret = std::vsnprintf(__out, __size, __fmt, __args); <-- no member named vsnprintf in namespace std (in file c++locale.h)
return (std::isfinite(x) != 0); <-- Expected unqualified-id (in file cmath_wrap.hpp)
etc. I think most of them are related to some function not in the standard library... does XCode use a different or incomplete standard library? And how do I change that.
I really just want to use the XCode debugger, it makes things easier when my code isn't running, and it is nice to have a graphical profiler as well.
Try uncheck option "recursive" in your "Build Setting/Header Search Path"

C++ Compiler Error C2371 - Redefinition of WCHAR

I am getting C++ Compiler error C2371 when I include a header file that itself includes odbcss.h. My project is set to MBCS.
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\odbcss.h(430) :
error C2371: 'WCHAR' : redefinition; different basic types 1>
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(289) :
see declaration of 'WCHAR'
I don't see any defines in odbcss.h that I could set to avoid this. Has anyone else seen this?
This is a known bug - see the Microsoft Connect website:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98699
The error doesn't occur if you compile your app as Unicode instead of MBCS.
There are a half-dozen posts on various forums around the web about this - it seems to potentially be an issue when odbcss.h is used in the presence of MFC. Most of the answers involve changing the order of included headers (voodoo debugging). The header that includes odbcss.h compiles fine in it's native project, but when it is included in a different project, it gives this error. We even put it in the latter project's stdafx.h, right after the base include for MFC, and still no joy. We finally worked around it by moving it into a cpp file in the original project, which does not use MFC (which should have been done anyway - but it wasn't our code). So we've got a work-around, but no real solution.
This error happens when you redeclare a variable of the same name as a variable that has already been declared. Have you looked to see if odbcss.h has declared a variable you already have?
does this help?
http://bytes.com/forum/thread602063.html
Content from the thread:
Bruno van Dooren [MVP VC++] but i know the solution of this problem.
it solves by changing project setting of "Treat wchar_t as Built-in
Type" value "No (/Zc:wchar_t-)". But I am using "Xtreme Toolkit
Professional Edition" for making good look & Feel of an application,
when i fix the above problem by changing project settings a new
linking errors come from Xtreme Toolkit Library. So what i do to fix
this problem, in project setting "Treat wchar_t as Built-in Type"
value "yes" and i wrote following statements where i included wab.h
header file. You can change that setting on a per-codefile basis so
that only specific files are compiled with that particular setting. If
you can solve your problems that way it would be the cleanest
solution.
#define WIN16
#include "wab.h"
#undef WIN16
and after that my project is working fine and all the things related to WAB is also working fine. any one guide me, is that the right way
to solve this problem??? and, will this have any effect on the rest of
project?? I wouldn't worry about it. whatever the definition, it is a
16 bit variable in both cases. I agree that it isn't the best looking
solution, but it should work IF WIN16 has no other impact inside the
wab.h file.
--
Kind regards, Bruno van Dooren bruno_nos_pam_van_dooren#hotmail.com
Remove only "_nos_pam"