C++ and Objc Build Errors - c++

I have been trying to add MobileSynth to my application for some time now and I am only running into errors.
I have followed the steps here which explain how to add a project into another one.
When I compile, both projects are compiled correctly without errors, but the moment I try import the code into my objective C source code I get a large number of errors.
This is a screenshot of the errors.
Im sure there are more errors than these as there seems to be something wrong with the dependencies.
I also approved Xcodes recommendation to convert the project 2 (containing the objective C viewcontrollers with .mm extensions and the .cpp files) from an old 3.something version to the version 4 project type, and made the snapshot. Didnt seem to change anything.
I am not sure how to solve these issues. I would really appreciate any help.

Use using namespace instead of namespace.

You're aware that files that use C++ need the .mm extension. You also need to consider import dependencies. Since this header contains C++, any other file that imports it will also need to have the .mm extension. I'm almost positive that's what's happening to you.
I generally try to keep C++ quarantined to the implementation files for this very reason.
Also, for clarification on previous advice:
// Correct
namespace synth { class something; }
// Incorrect
using namespace synth { class something; }
// Optional
namespace synth { class something; }
using namespace synth;

Related

VS2015 with sdl2 error : "#using needs c++/cli mode enabled"

I've been trying to follow lazy foo's productions tutorial on sdl2 and I keep on running into the same issue. I made a template that links to the correct files and all and it worked for a while. But now when I create a project and include iostream for example, it tells me #using need c++/cli mode enabled.
So I then tried enabling it in the project settings but then it gave another error : "Cannot open metadata file iostream"
I tried :
Rebuilding the project and solution
Cleaning the project and solution
I read this question and its answers : Visual studio - getting error "Metadata file 'XYZ' could not be found" after edit continue
Tried this too : IntelliSense: "#using" requires C++/CLI to be enabled
All of the above did not work
Don't confuse #include, using and #using.
#using is used to import class libraries in C++/CLI, which is something you won't ever need unless you work with .NET libraries (but then usually you are better off just using C#, unless you are writing interop code).
#include is for including header files, which is what you normally do in "regular" C++. <iostream> is a regular standard library header, so you need #include (as in #include <iostream>).
using instead is used to bring names in the current scope (either the whole content of a namespace - as in the dreaded using namespace std;) or single names (as in using std::cout;). From C++11 it's also used to enable constructors inheritance and to create type aliases, but for the moment I don't think you need to worry about these uses.
But most importantly: please take the time to first learn the basics of the language from reputable sources before trying random stuff. All this #using mess wouldn't have arisen if you even just looked first at the classic hello would example you can find everywhere on the Internet.

Codeblocks can't find header files

So a few hours ago I started learning c++ in codelite but I was getting frustated with, so I just got codeblocks and imported the project. But now whenever I try to compile it returns:
fatal error: imports.h: No such file or directory
This is my project hierarchy in codeblocks:
And this is what the project folder looks like:
What am I doing wrong?
I know this is years later, but I've recently seen students following what I deem is frankly bad advice such as what is given above. For those learning c++ this functionality is NOT for you. To add headers you should simply check that you are using double quotes, instead of angled brackets i.e.
#include "myheader.h"
and NOT
#include <myheader.h>
Angled brackets are meant for libraries (informally) and adding a simple header file for you basic classes does not require you to change default search directories. The problem comes when someone else tries to run your code (assuming you're doing this for uni) and their IDE isn't setup to search for a "library" (your header) where it shouldn't be. Double quotes tells the compiler the files exist in your current relative directory. This way you can keep your main, headers and header implementation in one directory. Fiddling with your IDE should only be done when necessary. KISS
You have to tell Codeblocks where to find the header files that you include. Try adding the full path to your '/Headers' in the include directories of codeblocks
Goto 'Codeblocks menu > Settings > Compiler > Search directories > Add'.
EDIT: Since your issue, however, is quite irrelevant to learning the C++ language itself, I suggest that you start with simpler programs, then move on to more complex ones. That, of course, unless you have previous experience with other programming languages
Since I haven't found any Makro for
#define 'hostname of device where compiler is located' // which is unique and not to be copied !
I have now successfully used and included
#include "myCompileEnv.h"
as a workaround with the comments above, which is located more central - above the project directories in CodeBlocks.

can I call an app in OpenFrameworks something other than testApp?

I am working with OpenFrameworks for the first time (I am also rusty at C++).
I am trying to build an app with OFX, and I want to call my app something other than testApp. I am building off the openCVExample code, and I've replaced testApp everywhere with the new name and moved the files from testApp.{h,cpp} to newname.{h,cpp}.
However, when I try to build (using Microsoft Visual C++ 2010 Express, if that makes a difference) I see that the testApp.cpp file is being generated with the contents of newname.cpp and put into my src/ folder. I'm also getting griped at by the build saying that testApp isn't a valid namespace on all lines in newname.cpp where I am trying to call or define member functions (I am using newname::functionName).
I've looked at the build commandline, and it doesn't seem to be looking for testApp.cpp; I've also looked through the linker and other stuff, but don't see it mentioned anywhere in there. Is this some bizarre feature of OpenFrameworks?
In the openframeworks directory there is a project creator app that will do this for you.
D:\workspace\of_v0073_vs2010_release\projectGenerator\projectGenerator.exe
It will also setup addons you've downloaded.
Note:: It creates solutions for VS 2010, i assume this can be opened by Express?
You'll need to change the instances of "testApp" to "newname" in a handful of places:
In testApp.h you'll need to change your app's class name. This is probably the 5th line, which looks like class testApp : public ofBaseApp
In testApp.cpp, you'll need to change all of the function definitions to use the "newname" namespace. These are all of the lines which look like void testApp::setup()
In main.cpp, you'll need to change the argument in ofRunApp() from new testApp() to new newname()
You actually don't have to change the names of the files from testApp.{h,cpp}, though it's still a good idea from an organization standpoint.

Converting a *.c/*.h project (compiled as C++) to *.cpp/*.hpp

Question: what is the best way to convert a .c/.h based project (which is forcefully compiled as C++ via the makefiles) to a .cpp/.hpp based project?
Obviously, this is a triple-step process. The first would be to rename everything with *.c at the end to *.cpp; the second would be to rename everything with *.h at the end to *.hpp. What I'm getting caught up on is the third step- somehow building a list of what the files /were/ named (ie, myfile.c), then iterating through every single affected file and replacing every instance of the old filename with the new (myfile.c -> myfile.cpp). Obviously this would have to be done so the source files can still find everything that they need.
The source code in question consists of around 2700 individual source files.
The reason why I'm doing this is mostly because I'm porting said software package to Mac OS X, and that involves Xcode. Things are getting bloody messy trying to keep track of precisely what is C, C++, and the associated headers for either (then overriding the compiler for C++ compilation). It would be much simpler if everything C++ was *.cpp (with the associated headers being *.hpp), since then I can just leave Xcode at the default compiler setting as per the file extension and everything should work without any fancy intervention on my end.
I should probably also note that I know precisely what files need to be converted, because they already compile properly and in a sane fashion if I'm overriding Xcode to compile as C++. That's not a problem- my issue is trying to figure out how to batch rename everything then run through all the files and update the #includes.
Thank you in advance!
-Keven Tipping
You don't need to mess with the headers. filename.h is a perfectly good name for a C++ header.
If you're not using the old makefile, but creating a new XCode project, then you have only one step:
Rename *.c to *.cpp
If the makefile was written right (using rule patterns and not specific per-file rules), there shouldn't be any changes needed there either.
There's no reason to rename those C language header and source files to C++ and there are many reasons not to. Just three of the many:
Reason #1: C and C++ are diverging, different languages. Force-compiling a C file as if it were C++ risks introducing a bug.
Reason #2: Xcode can handle C, C++, and C and C++ mixed together.
Reason #3: C++ can easily call C routines. All you need to do is wrap the declarations of those C functions inside an extern "C" { /* C declarations here */ } construct.

Vs2008 C++: how can I make recursive include directories?

I am including a complicated project as a library in C++ using Visual Studio 2008.
I have a set of include files that are scattered throughout a very complicated directory tree structure. The root of the tree has around ten directories, and then each directory could have multiple subdirectories, subsubdirectories, etc.
I know that all the header files in that structure are necessary, and they are hopelessly interlinked; I can't just include one directory, because then dependencies in another directory will feel left out and cause the compiler to crash in their annoyance at not being invited to the party. So, everyone has to be included.
I can do this by adding the directories one at a time to the project (right click->properties->additional include directories), but that can be fraught with pain, especially when one of the dependencies has children and makes a brand new subsubsubdirectory.
Is there a way to specify an include directory in a header file itself, so that I can just include that header whenever I need to use the functions it contains? That way, I get an easier way to edit the include files, and I don't have to make sure that the debug and release versions agree with each other (since the properties right click defaults to the current build, not all builds, a feature that has led to much crashing when switching from debug to release). Even better, is there a way to point to the directory root and force everything to be recursively included?
EDIT for all those replies so far:
I cannot edit the structure of this project. I can only link to it. I don't like the way the code is organized anymore than anyone else seems to, but I have to work within this constraint. Rather than spending potentially hours in the error-prone process of finding all the interdependencies and putting them in a project file, is there a way to do this programmatically?
That's clearly not a good idea, really.
These directories are a way to organize the code in logical groups.
/web
/include
/web
/stackoverflow
/language-agnostic
/algorithm
/database
/meta
/bug
/feature-request
/src
/local/
/include
/local
/my-favorites
/src
Now if I type
#include "exception.h"
What the heck am I trying to include ? Where's that file ? How can I see its content ?
On the other hand if I type
#include "local/my-favorites/exception.h"
Then it's perfectly clear. (and I just have two includes -Iweb/include -Ilocal/include)
And this way, I can have multiple files that have the exact same name and there would be no ambiguity, nifty when you wish to integrate two different 3rd party libraries which both have such a 'exception.h'.
Also note that for clarity, the namespace nesting should reflect the directories organization. So that
file: "web/include/web/meta/bug/exception.h"
namespace web { namespace meta { namespace bug {
struct exception: std::runtime_error {};
} } } // namespace bug, namespace meta, namespace web
This way it's easy to think of what header you have to include when you want a class.
Also note that, for example if you look at boost, they put headers for 'lazy' programmers, in each directory, which include the headers of all subdirectories
file: "web/include/web/meta/bug.h"
#include "web/meta/bug/file1.h"
#include "web/meta/bug/file2.h"
#include "web/meta/bug/file3.h"
#include "web/meta/bug/file4.h"
#include "web/meta/bug/file5.h"
file: "web/include/web/meta.h"
#include "web/meta/bug.h"
#include "web/meta/feature-request.h"
These includes might also 'pull' names into a more generic namespace with a using directive:
namespace web { namespace meta {
using ::web::meta::bug::bug;
} } // namespace meta, namespace web
To make it less painful for developers.
So as you can see, the language already provide you with a very good way of organizing your code cleanly, if you go with the 'all includes' options, you'll just end up with an unmaintainable mess:
#include "exception.h"
#include "bug.h"
#include "myString.h"
#include "database_connect.h"
#include "helper.h" // really love this one...
#include "file.h" // not bad either eh ?
I've had some of these at work... think 20 unqualified includes when you depend on 25+ components... now, do you think that it would be possible to remove a dependency on component X ? ;)
EDIT: How to deal with 3rd party library ?
Sometimes a 3rd party library does not live up to your expectations, whether it is:
not self-sufficient headers (ie you need to include 3 files to use 1 object)
warnings at compilation
header organization problem
you always have the opportunity to wrap them in headers of your own.
For example, say I have:
/include
/file1.h
/file2.h
/detail
/mustInclude.h
/exception.h
And anytime you wish to include a file, you have to include 'exception.h' BEFORE and 'mustInclude.h', and of course you have the problem that it is difficult to spot that the files included come from this 3rd party library and not your own (current) project.
Well, just wrap:
/include
/3rdParty
/file1.h (same name as the one you would like to include, it's easier)
file: "/include/3rdParty/file1.h"
#pragma push
// ignore warnings caused
#include "detail/exception.h" // necessary to include it before anything
#include "file1.h"
#include "detail/mustInclude.h"
#pragma pop
And then in your code:
#include "3rdParty/file1.h"
You have just isolated the problem, and all the difficulty now lies within your wrappers files.
Note: I just realize that you may have the problem that the 3rd party headers reference each others without taking the 'relative path' into account, in this case, you can still avoid the 'multiple include' syndroms (even without edition), but that might be ill-fated.
I suppose you don't have the opportunity not to use such crap :x ?
If in any way possible you really should take the time to rework that mess. It will only get worse.
If you are including it as a library then you probably only need a subset of its functionality anyway - make it slowly accessible and usable again step by step.
edit:
And no, there is no recursive include - for good reason. It would be completely uncontrollable from a certain size on and you'd fall over file-name-collisions all the time.
You could hack around the limitation via scripting and the project files, but you really would regret it in the long run.
edit2:
Ok, emergency procedure then. Put the library in its own project and use a short script to generate a line containing the neccessary paths seperated by ; which to put in the project file into the projects .vcproj (which is just an xml-file) under:
VisualStudioProject -> Configurations -> Configuration -> Tool -> AdditionalIncludeDirectories
(at least in VS2005, might differ a bit in later versions).
If you need all the includes in your calling code, you might want to consider wrapping that part in a static library in a seperate project to avoid polluting the rest.
Q: I cannot edit the structure of this
project. I can only link to it. I
don't like the way the code is
organized anymore than anyone else
seems to, but I have to work within
this constraint. Rather than spending
potentially hours in the error-prone
process of finding all the
interdependencies and putting them in
a project file, is there a way to do
this programmatically?
This should get you started:
write a script (in your favorite "quick" language) to enumerate all the [sub-...]directories in the library directory
filter the directories (for start, remove the ones that don't contain any .h files)
output them either to header file as you described or directly to the vcproj file. The
vs2008 vcproj file is relatively simple XML. It might even be documented, but if you just view it in a text editor, you'll figure out where and how the include paths are defined
try to compile
if errors, try to figure out why, adjust directory filter (blacklist specific directories etc.) and go back to 2.
success
Anyway, don't be afraid to write code generation scripts