C++ - Many parse Issues in NSObjCRuntime and NSZone - c++

I'm using the AppGameKit 2 C++ libraries with Xcode.
I'm using a template project that's given for development on Mac OSX and my code is identical to the default template save for changing a initWithCString to initWithUTF8String, but it compiled after that anyway, so it's not a problem.
The problem started when I tried to rename one of the classes that comes with the template, called template.h/.cpp. The option to rename in the refactor menu was greyed out, so I duplicated the class and changed all of the #includes to point to the new class, then removed the old one from the project.
When I hit run, I got about 20 errors all saying stuff like Unknown type name 'NSString' and Unknown type name 'Protocol'.
I looked around and found answers like this one: ios - Parse Issues in NSObjCRuntime, NSZone, and NSObject but it didn't solve the issue, because according to those, my code should work.
The includes of the main class (Core.mm) is here:
// includes
#import <Cocoa/Cocoa.h>
#include "agk.h"
#include "template.h"
The code in template.h is here:
#ifndef _H_APP
#define _H_APP
// Include AGK libraries
#include "agk.h"
// used in Core.mm to set the window properties
#define DEVICE_WIDTH 1280
#define DEVICE_HEIGHT 720
#define WINDOW_TITLE "Title"
#define FULLSCREEN 0
// Global values for the app
class app
{
public:
// global game vars
public:
// constructor
app() {}
~app() {}
void Begin( void );
void Loop( void );
void End( void );
};
extern app App;
#endif
The code in template.cpp is here:
// Includes
#include "template.h"
// Namespace
using namespace AGK;
app App;
void app::Begin (void){
agk::SetVirtualResolution (1280, 720);
agk::SetClearColor(0,0,0); // light blue
agk::SetSyncRate(60,0);
agk::SetScissor(0,0,0,0);
}
void app::Loop (void){
agk::Print( agk::ScreenFPS() );
agk::Sync();
}
void app::End (void){}
I can't make any sense of this because it shouldn't make sense.

Well, I found the problem. In the template project, the template.cpp file was marked as an Objective-C++ source file, but it obviously wasn't being reimported as one. Changing the file type fixed the problem.

Xcode 11.7
( in 2020 )
change the type, to do it more intuitively

This is cause you imports C or C++ file in your project.For this you add all your header file that imported in .pch file or any common file should declare like this:
#ifdef __OBJ C__
//Import header file
#endif

Related

Incomplete type error while using class from my own dll

One more day, one more dumb question on stackoverflow, please excuse me.
The idea was to make dll and then import it to another project to use it there, but after including dll header file in second project and writing paths to the .lib and header files I still have these errors:
E0070 incomplete type is not allowed prjct-1 D:\projects-vs\firstTryWT\prjct-1\prjct-1.cpp 33
C2027 use of undefined type 'stmr::MathProblem' prjct-1 D:\projects-vs\firstTryWT\prjct-1\prjct-1.cpp 33
C2079 'problem' uses undefined class 'stmr::MathProblem' prjct-1 D:\projects-vs\firstTryWT\prjct-1\prjct-1.cpp 33
C3493 'problem' cannot be implicitly captured because no default capture mode has been specified prjct-1 D:\projects-vs\firstTryWT\prjct-1\prjct-1.cpp 35
I've tried to rebuild, change some code till I understand that I either already did what is needed or I don't know what is needed. Anyway, here is the code:
Dll header file:
#pragma once
#ifdef STMR_EXPORTS
#define STMR_API __declspec(dllexport)
#else
#define STMR_API __declspec(dllimport)
#endif
#include <vector>
#include <string>
namespace stmr
{
class STMR_API MathProblem;
class STMR_API Operation;
}
Definitions of both classes have STMR_API keyword. I have 'STMR_EXPORTS' in C/C++ -> Preprocessor and '$(OutDir)$(TargetName).lib' in Linker -> Advanced -> Import Library so that I have the import lib generated.
main cpp of the project which is supposed to use the dll:
#include <Wt/WApplication.h>
#include <Wt/WBreak.h>
#include <Wt/WContainerWidget.h>
#include <Wt/WLineEdit.h>
#include <Wt/WPushButton.h>
#include <Wt/WText.h>
#include "stmrLib.h"
class HelloApplication : public Wt::WApplication
{
public:
HelloApplication(const Wt::WEnvironment& env);
private:
Wt::WPushButton* button_m;
Wt::WText* summary_m;
};
HelloApplication::HelloApplication(const Wt::WEnvironment& env)
: Wt::WApplication(env)
{
button_m = root()->addWidget(std::make_unique<Wt::WPushButton>());
summary_m = root()->addWidget(std::make_unique<Wt::WText>());
stmr::MathProblem problem = stmr::MathProblem(problemText_m->text().narrow());
auto solving = [this] {
summary_m->setText("This equals " + std::to_string(problem.solve()));
};
button_m->clicked().connect(solving);
}
int main(int argc, char** argv)
{
return Wt::WRun(argc, argv, [](const Wt::WEnvironment& env) {
return std::make_unique<HelloApplication>(env);
});
}
I have correct path to the .lib file for dll in Linker -> General -> Additional Library Dependencies and stmr.lib/stmrd.lib in Linker -> Input -> Additional Dependencies for Release/Debug
Not sure if the problem in exporting or importing of the dll.
Feedback about question quality is appreciated.
In C++ (prior to modules) the header file needs to expose enough information about a class for another cpp file to create the object or use the type.
You have just forward declared it, which is enough to make pointers or references to the type and nothing else.
These errors have nothing to do with linking or DLLs or exports.
All compilation units that need to make instances or otherwise call methods of your types need to see the class definition. Put it in the headerfile. Method definitions can be in cpp files and exported.
The pImpl pattern may help you hide details, if you do not want to expose them.

How to make CPP files visible to linker in ESP8266 Eclipse project

There is a "hello world" project in Eclipse IDE that is supposed to compile against ESP8266 RTOS SDK.
File structure is as follows
I added one C++ class to it and put it into its own folder. Here is the class header
#ifndef MAIN_BLINKER_BLINKER_H_
#define MAIN_BLINKER_BLINKER_H_
class Blinker {
public:
Blinker( int period );
int Period() const;
private:
int period_;
};
#endif /* MAIN_BLINKER_BLINKER_H_ */
and the definitions
#include "Blinker.h"
Blinker::Blinker( int period ) :
period_( period )
{}
int Blinker::Period() const {
return this->period_;
}
Main.cpp file is like this
#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "blinker/Blinker.h"
extern "C" {
void app_main()
{
auto blnk = Blinker( 3000 );
int i = 0;
while ( 1 ) {
printf( "[%d] Hello beautiful world!\n", i );
i++;
vTaskDelay( blnk.Period() / portTICK_PERIOD_MS );
}
}
}
It compiles but fails at final stage because the linker (or what is supposed to be a linker in xtensa toolchain) does not see definitions of Blinker methods. This is what I get in the build log
If I put class files next to main.cpp file, the build succeeds. However with time there will be hundreds of files, and without any grouping it will quickly turn into an unmanageable mess.
Alternatively I could put this class into top-level components folder and equip it with empty component.mk file. This would also make the build system happy, however it would force me to use ugly header includes like ../components/blinker/Blinker.h, which I would like to avoid.
So the question is how to make build system aware of .c and .cpp files residing in subfolders of main folder?
you can set COMPONENT_SRCDIRS in "main" component.mk file
see:
https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/api-guides/build-system.html#example-component-makefiles
Try to add blinker/Blinker.cpp to your CMakeLists.txt.
Take a look at
How to add new source file in CMakeLists.txt?

C++ Thor library - problem with using resource loader class ( ' ' does not name a type)

I have been recently practicing managing multiple objects and drawing them in C++ using SFML library. I wanted my textures and future resources to be more reusable so I decided to make use of Thor library which suits my needs really well.
So I've written first few lines of code based on what you can find in this tutorial and the compiler always says:
main.cpp|12|error: 'textures_holder' does not name a type
This line gives an error :
textures_holder.acquire("Dirt", thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png"));
I'm using Code::Blocks IDE with MinGW compiler and SFML 2.5.0.
Here's my main.cpp and the header file which contains extern object :
//...
#include <Thor/Resources.hpp>
#include "Dirt_Block.h"
using namespace std;
//Adding textures to the texture library
//THIS LINE GIVES AN ERROR
textures_holder.acquire("Dirt", thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png"));
//Rest of code...
Dirt_Block.h (only the upper part) :
#ifndef DIRT_BLOCK_H
#define DIRT_BLOCK_H
#include <SFML\Graphics.hpp>
#include <vector>
#include <Thor/Resources.hpp>
#include <Thor/Resources/SfmlLoaders.hpp>
extern sf::Vector2u screenRes;
extern thor::ResourceHolder<sf::Texture, std::string> textures_holder;
//Rest of the code
I'd like to know what is causing this error and maybe help others who may experience similiar frustrating problems. Thanks for help.
EDIT :
As suggested in the comment I've declared a few extern int variables in the Dirt_Block.h so now it looks like this :
//...
extern int test_int_up;
extern sf::Vector2u screenRes;
extern thor::ResourceHolder<sf::Texture, std::string> textures_holder;
extern int test_int_d;
//...
And then assinged to them some value in main.cpp :
//...
test_int_up = 55;
test_int_d = 55;
//Adding textures to the texture library
textures_holder.acquire("Dirt", thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png"));
//...
But the compiler gives error :
main.cpp|9|error: 'test_int_up' does not name a type
main.cpp|10|error: 'test_int_d' does not name a type
main.cpp|12|error: 'textures_holder' does not name a type
Much less distracting to see what your problem is without all the extraneous code!
C++ programs don't start from the top of the file and run code down to the bottom. They start at the main(), and control flow proceeds from there, with one thing triggering another.
(Note: That doesn't take into account global constructor ordering, which does go in order of declaration--but you have no guarantee of the order declarations from "different files" might run in.)
Point being, you can't just make random function or method calls in the middle of a file. That's where you put declarations. You have to be inside of a function or method to make calls, e.g.
int main() {
textures_holder.acquire(
"Dirt",
thor::Resources::fromFile<sf::Texture>("Textures\\dirt_block.png")
);
...
}

Creating a cross platform c++ touch manager. Passing Objective-c objects in c++ involved code

So I am trying to create a multitouch class that can be used cross platform (iOS, Android, etc). The goal is that the engine does not need to know the platform in order to get updated touch data.
Right now I am doing the general design and am specifically implementing the iOS side. The Android etc side will come much later.
In order to do this I am trying to use the delegation pattern. There are really only two interface items.
There is a method update(float dt) to be called on each new frame with the dt. This method then will return a c++ struct of information about all the touches or perhaps set a property that can be accessed. I am not sure.
On the iOS side the only other function that needs to be called from outside is touchesDown which passes in a NSSet* of the UITouches and the UIView that they are in.
Here is the design I am working with thus far
Multitouch\
PlatformTouchManager.h (C++ Abstract Class with Update)
iOS\
iOSMultiTouch.cpp (Objective-c++)
iOSMultiTouch.hpp (Objective-c++ Class inheriting PlatformTouchManager)
MultTouch.cpp (C++)
MultiTouch.h (C++ class)
Here is PlatformTouchManager.h
#define MAX_TOUCHES 5
#define PLATFORM_iOS
//#define PLATFORM_ANDROID
class PlatformTouchManager {
public:
// Update All The Events
virtual void update(float time) = 0;
};
And of course Multitouch.h
class Multitouch {
private:
PlatformTouchManager* manager;
public:
Multitouch() {
#ifdef PLATFORM_iOS
manager = new iOSMultiTouch();
#endif
}
~Multitouch() {
delete manager;
}
Multitouch(const Multitouch&) = delete;
void update(float dt);
void* getManager() {
return manager;
}
};
And finally iOSMultiTouch.hpp
#include <stdio.h>
#include "../PlatformTouchManager.h"
#include <set>
#import <UIKit/UIKit.h>
class iOSMultiTouch: public PlatformTouchManager {
public:
// Initializer
iOSMultiTouch();
// Destructor
~iOSMultiTouch();
// Update All The Events
void update(float time);
// Touch Down Set
void touchesDown(id<NSSet> set, id<UIView> view);
};
It may be worth noting that this code is included by MultiTouch.h (c++) and my native view code which is objective-c++.
The cross platform engine thus creates a Multitouch object, keeps a reference and every frame calls update.
I am imagining that then iOS UIView will get the Multitouch* from the cross platform engine. Cast it into a iOSMultiTouch* object and call touchesDown:(NSSet *)touches withEvent:(IUView *)view on the delegate.
I am having a serious problem doing this.
If I try to import UIKit inside iOSMUltiTouch.hpp it causes build chaos so it would appear I can only import it inside of the source file. Therefore my touch down method needs to be void touchesDown(void* touches, void* view);.
The problem is then implementing this as when I try to cast these void* pointers into their proper types I get the warning Cast of C pointer type void* to objective-c pointer type id requires a bridged cast.
I understand that there are some ARC concerns here as ARC cannot track such things when casted into a primitive pointer but how do I get around this?
iOSTouchManager does indeed need to hold a strong reference to the UITouch objects up until after the frame the touch is released.
How do I implement this cast? Is there a different way I should be designing my classes to make this easier?
For those of you who were wondering these are the errors that pop up should you import uikit from iOSMultiTouch.hpp
Parse Issue
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:512:1: Expected unqualified-id
../Multitouch/MultiTouch.cpp:9:10: In file included from ../Multitouch/MultiTouch.cpp:9:
../Multitouch/MultiTouch.h:15:10: In file included from ../Multitouch/MultiTouch.h:15:
../Multitouch/iOS/iOSMultiTouch.hpp:15:9: In file included from ../Multitouch/iOS/iOSMultiTouch.hpp:15:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:9:1: Expected unqualified-id
../Multitouch/MultiTouch.cpp:9:10: In file included from ../Multitouch/MultiTouch.cpp:9:
../Multitouch/MultiTouch.h:15:10: In file included from ../Multitouch/MultiTouch.h:15:
../Multitouch/iOS/iOSMultiTouch.hpp:15:9: In file included from ../Multitouch/iOS/iOSMultiTouch.hpp:15:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:10:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:10:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:5:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:5:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:8:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:8:
Semantic Issues
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:514:9: Unknown type name 'NSString'
../Multitouch/MultiTouch.cpp:9:10: In file included from ../Multitouch/MultiTouch.cpp:9:
../Multitouch/MultiTouch.h:15:10: In file included from ../Multitouch/MultiTouch.h:15:
../Multitouch/iOS/iOSMultiTouch.hpp:15:9: In file included from ../Multitouch/iOS/iOSMultiTouch.hpp:15:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8:
Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:9: In file included from Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
Problem
You got ton of errors because you imported iOS framework (UIKit) inside a C++ file (iOSMultiTouch.cpp).
Solution
For implementation files which you need to import iOS frameworks to, you have to use .mm instead of .cpp extension. .cpp is C++ extension, not Objective-C++ extension.
In this case, you need to rename iOSMultiTouch.cpp to iOSMultiTouch.mm. Replace void * with Objective-C pointers and it will work as expected.
Utils.h will keep nothing related to Objective-C and can be used anywhere. Utils.mm is used to work with Objective-C parts.
Utils.h
PlatformTouchManager* GetIOSTouchManager();
Utils.mm
#include "Utils.h"
#include "iOSMultiTouch.hpp"
PlatformTouchManager* GetIOSTouchManager() {
return new iOSMultiTouch();
};
Multitouch.h
#include "Utils.h"
// Other include
class Multitouch {
private:
PlatformTouchManager* manager;
public:
Multitouch() {
#ifdef PLATFORM_iOS
manager = GetIOSTouchManager();
#endif
}
~Multitouch() {
delete manager;
}
Multitouch(const Multitouch&) = delete;
void update(float dt);
PlatformTouchManager* getManager() {
return manager;
}
};

"Does not name a type" in header-only library

I'm trying to write a header-only library of helper functions for myself. (I'm using boost and SDL, and boost is much easier to use, so I want to emulate that for my own helper library.)
I'm getting the error "Does not name a type" for one of my classes, and it's confusing me. I know I can get this problem with a misspelling or circular include, but can't find either of those problems in my code. Forward declaration in SdlWindow.cpp doesn't help. Including the header again (so I /do/ have a circular include) doesn't help either (I get "previously defined" errors).
Main.cpp:
#include <WBS/SdlWindow.hpp>
int main(int argc, char **argv) {
WBS::SdlWindow myWindow("Test window", 640, 480);
return 0;
}
SdlWindow.hpp:
#ifndef SDLWINDOW_HPP_
#define SDLWINDOW_HPP_
#include <string>
#include <SDL/SDL.h>
namespace WBS {
class SdlWindow {
public:
//Member Variables
SDL_Surface *screen;
int xSize;
int ySize;
//Constructor and Destructor
SdlWindow(std::string title, int xSize, int ySize);
virtual ~SdlWindow();
//Member Functions
};
}
#include "SdlWindow.cpp"
#endif /* SDLWINDOW_HPP_ */
And SdlWindow.cpp:
#include <string>
namespace WBS {
SdlWindow::SdlWindow(std::string title, int xSize, int ySize) {
this->xSize = xSize;
this->ySize = ySize;
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(xSize, ySize, 32, SDL_ANYFORMAT);
SDL_WM_SetCaption("Simple Window", "Simple Window");
}
SdlWindow::~SdlWindow() {
SDL_FreeSurface(screen);
SDL_Quit();
}
}
The error I get is "SdlWindow' does not name a type", in SdlWindow.cpp, where I declare the two SdlWindow functions. What's causing this and how can I fix it?
I'm compiling with mingw32's gcc in Eclipse on Windows Vista.
I see what you are trying to do: a header-only library implies that .cpp file is included into .h file and not the other way around (this is, of course, confusing for many people). But if you are doing it that way, then you should not attempt to compile your .cpp files as ordinary source files. In fact, it might be a better idea to give your .cpp file a different extension: a .hpp maybe, for one example.
I suspect that you somehow managed to make SdlWindow.cpp a part of your project, i.e. you are trying to compile your SdlWindow.cpp by itself, as an ordinary source file. This will not work for obvious reasons. If your are trying to implement a header-only library, then no files from that library should be compiled as ordinary source files.
Of course, on an additional note, this whole thing will not work the way it looks now. A header-only library cannot contain non-inline non-template functions. It works for Boost because in Boost the functions are templates. Your functions are not templates. You have to declare them inline then, or otherwise you'll end up with multiple-definition errors for each of your functions.
You need to #include <WBS/SdlWindow.hpp> from SdlWindow.cpp.
You need to include WBS/SdlWindow.hpp from SdlWindow.cpp, as Sam said, but also you do not need to include SdlWindow.cpp from its header (that's a Bad Thing waiting to happen).