• 0

[C++/Xcode] Any good online guides?


Question

Are there any good online guides that deal with learning C++ with Xcode? or does the GUI really not matter with C++?

Link to comment
Share on other sites

18 answers to this question

Recommended Posts

  • 0

The IDE does not mather with C++, but Apple you can probably use the interface builder if you use it with Xcode. Take a look at WikiBook for free C++ books.

Link to comment
Share on other sites

  • 0
Are there any good online guides that deal with learning C++ with Xcode? or does the GUI really not matter with C++?
All the IDEs are similar, once you learn one of them you learned them all, basically. The hard part is learning C++.
Link to comment
Share on other sites

  • 0
Last IDE I used was VB6
You're going to find C++ IDEs more focused on code than GUI, but otherwise it's the same process; write code, build, run, debug, repeat. Good luck with C++ btw, it's a monster.
Link to comment
Share on other sites

  • 0

Thanks. Yeah I'm trying to get away from VB, not because I find it weak or lacking in anyway, I just feel C++ is a language that can travel better to different OS's and platforms.

Link to comment
Share on other sites

  • 0

I don't know what are your needs, but there are several cross-platform languages that are way more productive and less painful than C++, which really isn't necessary unless you really need the benefits of both pure native code and modern language features (generic programming, OO). In general, you're much better served by Java, C#, Python, Ruby, etc. And yes, C# is largely cross-platform today.

Link to comment
Share on other sites

  • 0

C# using mono is far from perfect, and as he use a Mac, the worst plateform for C# (no support for cocoa nor carbon, right?) he is better in higher level C++ with tools like QtCreator, a crossplateform C++ fast application IDE. Application are going to be antive on all OS without any code modification (if you don't include unistd or stuff like that).

Link to comment
Share on other sites

  • 0

C# on Mac is probably not the best choice, but I also mentioned three other alternatives. There are tons of GUI toolkits for Python, same for Java. Also, these languages support cross-platform programming much better than C++. In Python you write networking code once and it's valid for all supported OSes. In C++, welcome to "#ifdef _WIN32 #else #endif" land. Not to mention the need to recompile for each target platform, since in C++ only the source code may be cross-platform, not the actual program.

Link to comment
Share on other sites

  • 0

I think it depends on what he meant by "travel better". If he's writing something that needs to be run on both Mac and Windows, then that's an icky proposition for which there isn't a single good solution, as there are pros and (significant) cons to every approach, whether it's compiled or interpreted, using native APIs or wrapper toolkits. Instead of "in general", I would have said "it depends on exactly what you are trying to do."

OTOH, if he meant "my skills with C++ can be used regardless of whether I'm developing for Macs, Linux, Windows, embedded systems, etc.", then yes, I would say that C++ has a breadth surpassed only by C.

(PS: I don't quite get why you seem to hate the preprocessor so much; as long as it's not abused IOCCC-style, there is nothing inherently wrong with it.)

Link to comment
Share on other sites

  • 0
(PS: I don't quite get why you seem to hate the preprocessor so much; as long as it's not abused IOCCC-style, there is nothing inherently wrong with it.)
I was talking about portability. #ifdef MY_OS blabla #else #ifdef THAT_OS blabla #else #ifdef THAT_OTHER_OS #else blabla #endif is not what I call support for cross-platform development, it's just an ugly way of throwing lots of non-portable and mutually incompatible code in the same source file. Contrast that with having access to an extensive standard cross-platform library like the ones that come with Java or Python.

C++ isn't portable, it merely allows you to make cross-platform source files.

I wasn't really making a general point about the preprocessor, even though I do think it is evil (probably a necessary one in C, less so in C++). For some reason, there's little use for a preprocessor in most programming languages and they do all the better without it.

Edited by Dr_Asik
Link to comment
Share on other sites

  • 0
For some reason, there's little use for a preprocessor in most programming languages and they do all the better without it.

That's because "most programming languages" are interpreted (or are compiled down to an intermediate code) and/or do not use the native platform APIs and instead resort to some sort of wrapper toolkit like swing, tk, wx, etc. And that's all nice and good if you are okay with the inherent limitations. But if you are not, and you want to write a cross-platform app that compiles down natively and takes advantage of the full extent of the platform's own APIs, then you must "[throw] lots of non-portable and mutually incompatible code in the same source file", and to that end, the preprocessor does its job beautifully.

C++ isn't portable, it merely allows you to make cross-platform source files.

Depends on what you mean by "portable". A couple of decades ago, there was no question that "portable" meant "source-portable". The current generation may think that "portable" applies only to binary portability, but the old-timers will strongly disagree with that. And there's nothing wrong with only being source-portable, either: as I noted above, it's the price you pay if you want to exploit the platform to the fullest; if you don't want to pay that price and are okay with the limitations, that's fine. But that approach is not always appropriate.

Edited by code.kliu.org
Link to comment
Share on other sites

  • 0

All the preprocessor does is brainless cut/copy/pasting raw text, there's nothing quite beautiful about it, especially not what your code looks like and the fact that what you read and what the compiler gets to read after the preprocessor did its job can be dramatically different. Otherwise, I agree with your points. Maybe we differ on the extent to which one should avoid C/C++ but that would require a discussion of different scenarios.

Link to comment
Share on other sites

  • 0
All the preprocessor does is brainless cut/copy/pasting raw text

Now that's a bit harsh. :p Okay, at a certain level, yes, that's what it does, but the way in which it does it takes something that is (necessarily) crude and makes it not-so-crude. It can be abused, yes, but when used right, it's invaluable. How would you have handled the following without preprocessors?

#ifdef BIG_ENDIAN_SYSTEM
foo = 0x1234;
#else
foo = 0x3412;
#endif

Link to comment
Share on other sites

  • 0
Now that's a bit harsh. :p Okay, at a certain level, yes, that's what it does, but the way in which it does it takes something that is (necessarily) crude and makes it not-so-crude. It can be abused, yes, but when used right, it's invaluable. How would you have handled the following without preprocessors?

#ifdef BIG_ENDIAN_SYSTEM
foo = 0x1234;
#else
foo = 0x3412;
#endif

With a configuration file that's read at start-up. Instead of recompiling your application, compile it once and ship it with the OS and architecture-specific details in a config file. Small overhead in executable size, but it's arguably more readable, and there's no real need for a preprocessor there. But I'm not really trying to prove the preprocessor is never needed, just that by nature it's a very dangerous beast and is best avoided as much as possible. Consider that you can write #define private public and your whole encapsulation blows without so much as a compiler warning, because the compiler is completely oblivious to what the preprocessor does. Yes, technically it's illegal in C++, but there's nothing the C++ compiler can do about it.

When a language feature is able to silently destroy all guarantees made by that same language, there's a BIG problem with that feature.

Link to comment
Share on other sites

  • 0
When a language feature is able to silently destroy all guarantees made by that same language, there's a BIG problem with that feature.

I don't deny that the preprocessor can be abused (sometimes grossly so; look at the IOCCC :)), but as long as the programmer is judicious in his use, it's not a problem...

Link to comment
Share on other sites

  • 0
look at the IOCCC :))
Holy. :blink:
but as long as the programmer is judicious in his use, it's not a problem...
Sure, but that can be said of any language feature whether good or bad. Judicious use of a dangerous, error-prone language feature consists in avoiding the feature as much as possible, and that's my opinion on the C/C++ preprocessor.
Link to comment
Share on other sites

  • 0
Are there any good online guides that deal with learning C++ with Xcode? or does the GUI really not matter with C++?

Since you never really got a straight answer from anyone, here is a cocoa tutorial that I used. It's mainly for Objective-C, but the interface builder should work the same across all languages.

I have never used Xcode for a C++ project, however I do know it uses the gcc compiler. So code should be virtually identical between Linux projects.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.