I've been learning Objective-C and Cocoa by working my way through the Hillegass book and it occurs to me that I might be better off using Objective-C++. Objective-C seems like the clear choice for developing UIs but I have a very strong C++ background and would love to develop application back-ends in C++ and use Objective-C++ to do the UI integration.
But I wonder if Apple will keep developing Objective-C++ or will it become a dead end.
Is anyone out there using Objective-C++?
Disclaimer: I don't work or speak for Apple, so this is my opinion:
I can't speak for the major dev shops, but in my small group, we've used Objective-C++ both for integrating C++ libraries, and as you propose for writing backends in C++. As #alxp mentions, things like exception handling across the language boundary are painful, but with a little planning, most of these pains can be avoided. For experienced C++ devs, the gains can be well worth the pain.
In terms of support, I think you can assume that support in its current state won't go away any time soon. It's part of the GCC code base and the Clang toolchain (Apple's next compiler toolchain) fully supports Objective-C++. On the other hand, there isn't any official guarantee that Apple will continue to develop the integration—fixing some of the warts, for example.
For current projects, I would say that if using Objective-C++ provides benefit, it is safe to rely on the existing support and you should use it.
The only times I've used ObjC++ was to port libraries to make them accessible from my ObjC code. The clashes between how ObjC++ and ObjC handle things like exceptions and class creation and destruction just made it too much of a headache to juggle the two languages in one project.
I don't think support will go away soon as happened with Cocoa / Java since it is pretty solidly part of GCC, and the fact that Objective-C++ compiles down to straight C++ in the same way that Objective-C can compile down to straight C, but I still don't find it a very pleasant environment to build software in compared with Objective-C and being able to comfortably fully use the OS X-provided frameworks.
Objective-C++ is likely to remain supported as long as Objective-C is. Obj-C++ is a basic goal for clang, which is expected to eventually replace gcc as Apple’s preferred compiler. Usage is likely to rise as Carbon applications are moved to Cocoa front ends.
Of course, the word “likely” appears twice above because Apple is so excitingly unpredictable. :-)
I suspect Apple will continue to support Objective C++ for a while, as I don't see any significant recurring effort required by Apple to maintain Objective C++ as Apple updates Cocoa and Objective C++.
The other day I was surprised when I attempted to refactor some Objective-C code that was within an Objective-C++ file using Xcode's refactoring support. Even though the menu items are enabled I got the "Can’t refactor Objective-C++ code. Xcode can only refactor C and Objective-C code." error message. So while compilation of Objective-C++ will continue to function indefinitely I suspect Objective-C++ will be a second class citizen within Xcode.
I took it out of all my code. No .mm files.
But you need .cpp files to talk to .m files. The solution is a .c/.h file that keeps the blood brain barrier intact.
C++ with objective-C is usually just too much baggage.
Objective-C is really just a bunch of C code that emulates objects in the C language, and it still uses the C compiler including the Objective-C header files. Using Objective-C++ uses the C++ compiler and include the Objective-C headers as C code, since C++ will run C code. Objective-C++ is essentially just C, C++, and Objective-C (which is really just C)
Related
Unfortunately, my C app for PIC32 needs OO too much and I can't continue doing it in C.
Do you know any MIPS32 C++ compiler for PIC32?
Thanks
Microchip's XC32 tool chain now supports C++ since version 1.10
You might contact Comeau Computing; thier C++ compiler generates C code as an intermediate language so that it can then utilise a platform's existing native C compiler where only a C compiler is available, and therefore porting to new platforms is relatively quick and simple.
For various reasons the intermediate generation and compiler adaptation is not accessible to end users so you will still need Comeau to generate a PIC32/C32 port, but it probably won't take long and hopefully they would amortise the cost over sales to other users.
However if you use Commeau or any other C++ to C translator, you will suffer from the inability to use source-level debugging, and that is likley to be the killer to any attempt to use C++ sucessfully without native debugger support.
Although it is not always pretty, your best bet is probably to learn how to implement OO designs in C. Here's a whole book on the subject: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf
According to this fairly recent thread on the microchip forums it looks like C++ support for PIC32 isn't available anywhere yet and isn't a high priority with Microchip. The wisdom of the respondents in that thread appears to be: don't hold your breath.
I'm a MPLAB user myself building small programs so I just take what Microchip gives me. I've never gotten to the point where I thought I needed C++, longed for yes, but never needed. As a next step you can either consider moving to another platform with C++ support or take another look at your design and ask why you need C++ that badly. Some features can be simulated in C with varying amounts of pain and suffering.
You might keep an eye on the proper GCC MIPS port. They have all the pieces, but I don't know if anyone's made C++ work with PIC32 in particular. I know it did work on sgimips.
I'm developing a c++ application with Xcode 3.1.4
while debugging, if i step into a constructor, i see only the membervariables, but no locals used in the constructor.
does anyone know that problem and how to solve it?
I saw somewhere else that -gstabs+ solves a similar problem specific to locals in constructors. I didn't try it but the solution that worked for me was to move the body of the code into a private function with the same arguments, and call that function from the constructor. Same behavior, but now you can debug the code...
It may be a bug in the compiler such as this one. You could try upgrading your g++ or using a different compiler.
Obvious question: you're running with no optimizations (-O0), correct? With optimizations, it is very common for local variables to be optimized out. Even without optimizations, I have found that a lot of simple C++ seems to get hidden. For instance, you can't always call get() on a shared_ptr because it gets inlined.
I recommend upgrading to Xcode 3.2. I feel that C++ support improved somewhat between 3.1 and 3.2. That said, C++ support within Xcode is still very weak. Unless you need the portability of C++ (as I do), I do not recommend developing Mac or iPhone apps in C++. You will fight the system all day. It is far better to just learn ObjC and use it (besides, ObjC really is a very powerful language and works extremely well with Cocoa). Even when you need the portability of C++, I recommend isolating the C++ code into a core and wrapping it up in Objective-C.
In no case should you use much ObjC++. gdb gets extremely confused in my experience with ObjC++. If you're going to write in C++, wrap your ObjC. If you're going to write in ObjC, wrap your C++. But don't try to write in both at the same time if you ever plan to use the debugger.
I'm pretty sure this is possible but I'm not sure how to go about it. I'm very new to building with GCC in general and I have never used FreeRTOS, but I'd like to try getting the OS up and running on a TI ARM Cortex MCU but with a slight twist: I'd like to get it up and running with Pascal. I'm curious:
Is this even possible to get work? If not, the next issues are kind of moot points.
From my Delphi days, I vaguely recall the ability to access functions in C libraries. I'm wondering if I would have access to the C routines in FreeRTOS.
If I use the GCC version (preferable) would I be able to debug using OpenOCD on the target? I'm not quite sure how debug symbols work and if it's more or less language agnostic (hopefully, in this case).
As kind of a bonus question a bit outside the scope of the original query, can I simulate FreeRTOS on an x86 processor (e.g. my development PC) for easier debugging during development? (With a Pascal program, of course..)
I haven't found any documentation on achieving this, so hopefully someone here can shed some light! Any resources would be most helpful. Like I said, I'm very new to this kind of development. I'm also open to suggestions if you think there is a better alternative.
FYI, my preferred host configuration would be something similar to:
Linux (Ubuntu/Debian)
Eclipse IDE for development, unit testing, and hopefully simulation / debugging
OpenOCD for target debugging
GNU Pascal + FreeRTOS on target
FreeRTOS is C source code, so like you say you would have to have some mechanism for linking C with your Pascal programs. Also, FreeRTOS relies on certain registers to be used for things like passing a parameter into a task (as a hypothetical example, the task might always expect the parameter to be in register R0) so you would have to ensure the ABI for the C compiler and the Pascal compiler was the same - or have your task entry in C then have it call a Pascal function (very nasty). Then there is the issue of interrupts, calling inline macros, etc. I would say this would be extremely difficult to achieve.
Both GNU Pascal and Free Pascal support linking to C (gcc) and ARM, as well as calling pascal code from C etc. Writing a header and declaring the prototypes with cdecl is all there is to it.
Macros are a bit bigger problem. Usually I just rewrite them to inline functions (what they should have been anyway). Except for the macro/header issue, the problems are more compiler specific functionality (which you also would have a problem with when porting from one C compiler to the next)
If you prefer TP/Delphi dialect, Free Pascal is the better choice.
I run my old Delphi code fine on my sheevaplug.
There is already an example for FreeRTOS/GCC/OpenOCD on a TI Cortex-M3 (was Luminary Micro Cortex-M3). Be aware though that this is a really old example and both the Eclipse and OpenOCD versions used are out of date.
Although there is an Eclipse project provided, the project is configured as a standard make (as opposed to a managed make) project, so there is a standard makefile that can be just as easily executed from the command line as from within Eclipse.
http://www.freertos.org/portLM3Sxxxx_Eclipse.html
It may sound like a lot, but I am looking for a language that is cross platform that I can compile into a single stand alone exe. The source code needs to be secure (Not just hidden) and have some sort of gui toolkit. Do any exist?
In C++, I know 2 cross-platform UI toolkits: Qt and WxWidgets.
You won't find a language with more GUI toolkits or that is more cross-platform than the C programming language.
In python here is the list cross platform gui
For Java you can use Swings and AWT
Well, your source secure is a problem - how do you define secure and why do you think you need it like this?
Cross plattform with only one compilation - hits only on .NET/mono and Java, both not interpreted, but work with a intermediate compilation of some sort of VM. Code can be relatively easy decompiled, though it can be obfuscated.
Cross plattform with compilation for every plattform is far easier, with C, C++ and many many more your have a great choice. You could then watch out for your GUI-Toolkit of choice and check the languages that have bindings for it.
I use REAL Studio (formally REALbasic) for creating standalone cross-platform applications. The apps are also compiled and fully native, so it sounds like they would meet your definition of secure.
And REAL Studio is a lot easier to start with Qt (unless you already happen to be a C++ expert).
Are you choosing not to use managed code for any new applications for Win32? Why? Are there resources you need that aren't available from the CLR?
(Note "New" - not enhancements to existing codebases.)
One significant reason is ease of deployment. I can build a Win32 application (using MFC or WTL libraries), and with static linking there are no dependencies on external libraries (yes, I know that static linking is not the recommended approach).
Users can install and run this application without having to install anything else first: no framework library required, and no DLL hell. For comparison, read these posts from the author of Paint.Net to see how painful it can be for a user to install a .Net application.
I guess my last reason to write Win32 is portability. C++ compiles on all platforms, simply and without crazy dependencies. So for portable code, I still end up needing to access Win32 for the GUI.
I'm not bypassing .NET to do Win32 programming. I am bypassing both of them to do Java programming since I want my applications to run on as many platforms as possible. Windows may control a majority of the market but I don't see any reason to cut out even small possibilities for profit, especially since I can write Java code much faster than C++ or C# (that's based on my ability, not a reflection of the languages themselves).
Neither .NET not Win32 give me that cross-platform ability at the moment. They may eventually, with Mono, but I still consider that less-than-production-ready and there's still a question over its future in my mind.
At my workplace there are some old-timers who prefer using MFC because that's what they are familiar with. A few days ago we were to create a simple app and, naturally, they wanted to whip it out in MFC. Only that "whipping out" would have taken about a week and we needed the app in a day. I can't really blame them - old habits die hard. Eventually we went with C# and let the MFC-ers fiddle with the GUI design (which they much appreciated).
Yes and no. I use C++/CLI if I need to do any Win32/COM stuff. C++/CLI is wonderful. Our UIs are entirely .NET, but occasionally we do have need to use straight C++.