Would native support for modules, manual dynamic linking, run-time concepts, reflection, etc., in the C++ language allow a programmer to faithfully recreate the coding paradigm set up by Objective-C in pure C++? I'm asking this because of how Swift has made the fate of Objective-C uncertain.
Why use Objective-C at all? It's chained down to apple, if you want to write anything cross platform just do it in C/C++/C#/Java (yes, i'd use java before i use Objective-C/Swift).
@spectral/@kbw: Why wouldn't I be interested in how things work in Objective-C? The language adds full support for dynamic dispatch; dynamic linking and loading of arbitrary software libraries at run-time; dynamic, but still type-safe, Smalltalk-style messaging — the run-time doesn't freak out even if you send a message to nil! —; dynamic typing; and run-time extension of classes. It actually isn't chained down to Apple like the Cocoa libraries are and could be ported from C (yes, it was originally implemented as a preprocessor to plain C!) to C++ so as to increase its type safety. There is already such a thing as Objective-C++[1]; I just want to know if it could be re-implemented in such a way that the problems that using it currently creates could be erased. I know that Objective-C uses a different object model than the one used by C++, but it seems to me that one might be able to resolve this difficulty by writing the code for the dynamic parts of a C++-based implementation of something that functions like Objective-C at least partly in terms of run-time concepts[2]. I could use Clang's provisional support for modules to get dynamic linking to work, and Boost already offers rudimentary support for reflection in C++. So, I'll ask this again: would it theoretically be possible for someone to re-implement Objective-C in terms of pure C++ using either the tools that are available today and/or those which will soon be available, and how much work would you expect a programmer to do in creating such an 'Objective-C++ 2.0' in pure C++? If you think that something very much like this could be done, then I'll put it on my to-do list of things to do after I've finished learning C++ from Bjarne Stroustrup's Programming: Principles and Practices Using C++, Second Edition and The C++ Programming Language, Fourth Edition.
Of course it could be done. The easiest and fastest method would be to write a stub file\shared library in one language and link it to the other.
... so as to increase its type safety.
I'm curious, why do you think that type safety should be up to the language? If I want to perform a narrowing cast for instance then why should the language I am using try to hinder me in anyway?
@Computergeek01: Erm, that's…not exactly what I meant by '…so as to increase its type safety.' What I meant[/I] was that I would like the results of creating an Objective-C–style run-time written purely in C++ to be bug-free — i. e.: 'type-safe.' There would, of course, be ways in which a programmer could [i]circumvent such protective measures in their own code. And the idea behind this possible future project of mine isn't just to fix the problems that exist within Objective-C++; what I really want to do is to see if there is any way in which a C++ programmer might be able to use the features of Objective-C in a program written purely in C++ — that is, I would like to port Objective-C from its current mixture of assembly language, C, C++, and Objective-C to as much pure C++ and as little assembler as possible. It's a mite ambitious, I know, but I really am curious to see if it could be done. Maybe I won't be the one to do it, but could one replace Objective-C++ with pure C++ while retaining all of its features by unifying the object models that underly C++ and Objective-C?
type-safe doesn't magically make your code bug free. In any case, i wouldn't, whenever i see someone attempt to implement a feature to try and simplify something by reproducing a feature that another language has, it usually just ends up being more complex. Just use C++ if you want to, otherwise stick with Objective-C.