I have tried looking for tutorials and reading the docs but there's almost no information on how to use SDL to read and write to text files, etc. So, would it be a better idea to just use regular C++?
While SDL have RWops, its API is exactly the same as stdlib fread/fwrite/fseek. It serves different purpose though. There may be (and, as SDL is game oriented, very often are) cases when data processing code don't really care where data coming from (regular file, byte array in memory, zip or any other form of archive, network source, or even procedural generator). If this code uses RWops-like abstraction you can just write a new implementation for it and it and it will work without any modification or recompilation. SDL itself and all SDL-based libraries like SDL_image, SDL_ttf, etc. support loading data from RWops, as well as a few 'standard' RWops implementations like SDL_RWFromFile or SDL_RWFromMem.
If question is "what you should use", then there is really no answer, as there is no 'better' here. If you're writing a library though, it is very reasonable to provide a way for calling side to redefine what 'file' is (or at least load data from memory array).
Related
This is kind of a beginner question, so please let me know if this is appropriate for this website and if not, where else I should be asking this.
I've just gotten into the basics of C++ (pretty much what's being taught in this video from FreeCodeCamp: https://www.youtube.com/watch?v=vLnPwxZdW4Y). Obviously, not everything there is to know is discussed in this tutorial and I've been running into a couple of things in other demonstration vids that I don't quite get yet.
For example, this quick demonstration of how Tetris can be coded: https://www.youtube.com/watch?v=zH_omFPqMO4&t=0m25s) you can see him use the command 'RenderWindow', which apparently creates a new window the size of his choice (320*480 pixels in this case). This doesn't seem to be a standard function in C++, so I assume he somehow imported it. How can I do this myself? Does it have to with the file inclusions written at the top of the file (#include <SFML/Graphics.hpp>)? If so, how can I learn more about such files, where can I find them (is it anything like the Python Package Index, or interfaces in Java) and can I create them myself? Any general explanatory words on this?
Thanks in advance.
This doesn't seem to be a standard function in C++
That is correct. There are no functions for graphics nor window handling in C++.
so I assume he somehow imported it. How can I do this myself?
Usually, you would pick a library of your choice (there are many), or do it yourself by using whatever API your operating system provides.
Does it have to with the file inclusions written at the top of the file (#include <SFML/Graphics.hpp>)?
Yes, SFML is one of those libraries.
If so, how can I learn more about such files
You would go to the library's homepage and read the documentation.
where can I find them
Try searching the web for lists of libraries, articles, projects, etc.
is it anything like the Python Package Index
No, there is no standard one for C++. There are several package managers, build systems, etc. Popular libraries are in most of them and support one or more build systems.
This question has been bothering me so much for the past couple of days. I was wondering how the standard library works, in terms of functionality. I couldn't find an answer anywhere, even by checking the source code provided by the LLVM compiler which is, for a beginner like me, a really complicated piece of code.
What I'm basically trying to understand here is how does the C++ standard library work. For example let's take the fstream header file which consist of a bunch of functions that help to write to and read from files.
How does it work? Does it use the OS specific API (since the library is cross platform), or what? And, if the standard library can do it, aren't I supposed to be able to mess with some files as well without calling the standard fstream file (which to my experience I can't do)?
I apologize if my questions are unclear since I'm not a native English speaker: feel free to modify this text so as to make it clearer.
Does it use the OS specific API (since the library is cross platform), or what?
At some point, the OS specific API is used. The fstream implementation does not necessarily call an OS function directly. It might use other classes, which call functions inherited from C, etc., but eventually the call chain will lead to an OS call. (Yes, the details are often too complicated for an intermediate programmer to follow. So, as a self-described beginner, your findings are not surprising.)
The library is cross-platform in the sense that on your end (the C++ programmer), the interface is the same regardless of platform. It is not, however, the same library on every platform. Each platform has its own library, exposing the same interface on the C++ side, but making use of different OS calls. (In fact, the same platform might have multiple standard libraries, as the library implementation is provided by your toolchain, not by the standards committee.)
And, if the standard library can do it, aren't I supposed to be able to mess with some files as well without calling the standard fstream file (which to my experience I can't do)?
Yes, you are allowed to. Apparently, you have not been able to yet, but with some practice and guidance you should be able to. Everything in the standard library can be recreated in your own code. The point of the standard library (and most libraries, for that matter) is to save you time, not to enable something that was otherwise unavailable. For example, you don't have to implement a file stream for every program you write; it's in the standard library so you can focus on more interesting aspects of your project.
A compiler is just a program which create executable file or library. You can use the compiler default libraries to gain time or write your own. The default libraries communicate with the os for file operation or memory allocation and provide a simple standard classes to allow the developper to write only one code which work on all target platforms supported by the compiler and the libraries. If you want to write your own you have to write each function for all your target os.
The standard library is cross-platform in a sense that its interface does not change between platforms but its implementation does - or in practical terms - if you only use C++ and its standard library, you can write your code the same way for Linux / Windows / MacOS / Android / Whatever and if you find a C++ compiler for one of those platforms that supports the language features you used, you will be able to compile your code for that platform without rewriting anything.
So while you can use std::vector or std::fstream or any other feature in the library independently of the platform you're writing for and expect the function definitions, type names, etc. to look the same, you cannot expect the executable which you compiled for PC with Windows 10 to run on a phone with Android. You cannot even expect the same executable to run on the same PC but with different system - that is what I mean by "the implementation is different"
There are two main reasons for this difference:
Processors with different architectures (x86-64 and ARM for example) use different instruction sets and as such the C++ source would need to be compiled to a completely different machine code to run properly
Computers with processors of the same architecture which have a different operating system have different ways of dynamically allocating memory, creating files, creating streams, writing to console, creating and scheduling threads etc. - which is part of the system functionality that you use via the standard library
If you really wanted to you could use HeapAlloc() instead of operator new() or CreateThread() instead of stdlib's std::thread but that would force you to both rewrite your program every time you wanted to compile it for something else than Windows and recompile it with the target platform's compiler (and by proxy learn its API). Standard library saves you from that trouble by abstracting away those system calls.
As for the fstream in particular, here is what it uses internally on most PCs nowadays.
Basically, fstream, iostream and printf works based on a kernel function write(). When your code call printf (we use printf as an example), it will finally call write() to let the kernel work on the IO stuff. After that, write() returns and printf returns and your code continues.
So if you really want to know how the printf works internally, you have to read the source code of the Kernel.
But you shouldn't do that for now.
For a beginner, do not try to go deeper when you haven't got a basic cognition about computer. A computer is a project, just like a building. So the right way to learn it is to learn it level by level. First, learning how to use brick and cement to build a building, this is what you should do for now. What you shouldn't do is that you are learning how to build a building and this is your first time to try to use brick, then you are interested in how to produce a brick and start to focus on brick, this is a wrong way to learn IT.
If you are learning C/C++, just learn it. Remember, learn it level by level. For now, knowing how to use printf is enough.
I've got a DSP audio aglo in C# that I'd like to incorporate into iOS. A friend suggested that I convert to C++ instead of Objective-C, as it would be platform agnostic. Is this a good practice, any pitfalls to be aware of? My instinct is to keep it native with Obj-C. How would I access C++ functions within iOS?
Thank you
You can freely mix C++ with Objective-C, it's known as "Objective-C++". To let the compiler know that is your intent, you need to rename you .m file as .mm.
Mixing code like that is not necessarily a good idea, and fairly pointless if you aim is portability. Better is to keep you C++ in separate .cpp files, and create a bare-bones wrapper class (obj-c++) to pass data between your objective-C and C++ objects (effectively the wrapper is mediating obj-C methods and C++ functions to send and return data).
I have recently posted a couple of simple image processing examples of this on github - openCVSquares and openCVStitch. It's worth you taking a look, just to see how the C++ code is separated out from obj-C.
The openCV libraries have a C++ interface, so using C++ in the project is unavoidable. It would be possible to mash all of the code into .mm files, but that's an easy way to make a mess.
As regards portability, you get this by separating your UI code from your data-manipulation code. You should be doing this anyway for MVC, so it will be little additional work to write your model in C++ as per these examples. The model is portable, the UI is - and should be - platform specific.
Whether you should do this will depend on other factors such as your fluency with each language, the choice of frameworks and libraries, and the likelihood of porting. Audio processing would be a natural candidate for such an approach though.
Some detail about the samples
Don't worry if you can't get the code to run (the openCV framework can be troublesome...) the main thing is to see how the code is pieced together. I've tried to keep the examples very simple.
The C++ code was ported from C++ samples included with the openCV distro: squares.cpp and stitching.cpp. I tried to alter these as little as possible in order to assess this idea of portability.
Roughly, I had to address two issues...
1/ removed any UI code (so we are just sending data back to the obj-C side).
2/ modify the main() function so it becomes a callable function from the obj-C side. In the .cpp header file I declare a simple class with a single static function to facilitate this. Obviously there is scope to get much more elaborate but this should be enough for you to get the idea.
I'm trying to read MXF files (from Avid) into an Objective-C project and analyze some frames from video. Preferably getting them into a CGImage or NSImage.
I've been exploring the mxflib, but find myself at a bit of a standstill. I'm used to the mechanics of the standard video methods within Obj-c, but this package is C++ and not exactly something I'm familiar with.
Does anyone have experience working with this library or another similar one? There's not much information available on the subject (at least not that I can understand). And I'm not quite sure where to begin.
Actually, I'd say you're looking at it from a not so good way, as the mxflib is prepared to handle standard MXF files, not really Avid ones.
In short, for this to work, you need to extend the library as per Avid specs (it can be done!) or go with AMT, for which I understand you need to engage Avid to have it.
Finally, I think you're stuck with C++! ;-)
I'm writing a graphical application using Objective-C for the front end and C++ for the graphics processing and network communication. I read around on Apple's site looking for a way to link either a .dylib or .so with my C++ code in it to my Xcode project, but nothing seemed to work. I was able to get the project to reference it and link against it, but when I tried to call functions from that .dylib, it was saying that it didn't know what I was trying to do. Does anyone know what is going on here?
I know that Objective-C has all the libraries I would need to do graphics and networking, but I just feel like doing it like this. I haven't done much C++ in a while and I want to learn more Objective-C, so what better way than to use them together?
Thanks,
Robbie
Most of the projects I work on have an ObjC frontend and C++ backend. If you're dealing exclusively with functions, then Dave Gamble's name mangle fix is correct, but if you're dealing with more complex situations, where you need to deal with both ObjC and C++ objects, your best bet is to wrap the C++ objects in ObjC objects. Using opaque references (which is a very fancy way of saying void*), you can actually hand around C++ objects in ObjC and vice versa. I have some sample code that may be helpful.
That said, for graphics you're probably going to take a serious performance hit doing custom C++ rather than using Core Image and the related frameworks. Core Image and the other graphics frameworks are highly optimized for the Mac, and you're very unlikely to do better with hand-rolled C++ (or even very well-written C++ that isn't specifically for the Mac). As you move to 10.6 and grand central dispatch, the performance difference is going to be even more notable because you'll lose all the parallelization advances that you would get for free otherwise. This has nothing to do with ObjC; Core Image is C. You can call it from C++ all you like. I just recommend against custom graphics processing on Mac in any language unless you need portability or you have the expertise necessary to beat Core Image.
You're going to hit one obstacle in the form of what's called "name mangling". C++ stores function names in a way not compatible with Obj-C.
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
One way around this is to implement a set of simple C functions which call the C++ functions. It'll be a good challenge to keep the number of C functions as low as possible! You'll end up with a nice compact interface! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
extern "C" int function_name(char *blob,int number, double foo) {...}
This disables the standard name-mangling.
Build a header file with the prototypes for all these functions that you can share with your objective C code.
You won't be able to pass classes around in the same way (because your ObjC code can't use them), but you'll be able to pass pointers (although you might have to lie about the types a little).