Can you compile this in XCode? (const class initialization)

To familiarize myself with the C++ compiler in XCode, I've been running through a number of code examples from Scott Meyer's "Effective C++". However, the following code snippet based on Item 25 gives me a 'const class initialization' error or something to this effect. I don't have access to XCode at the moment, but the same snippet on Microsoft Visual C++ .NET compiles and runs with no warnings and, of course, no errors.

Try this:

#include <iostream>

using namespace std;

// Declare an anonymous const class with template
// type-conversion functions. The first one converts
// NULLPTR to any type of null non-member pointer.
// The second achieves the same result for any type
// of null *class member* pointer.
const class
{
public:
template<class T>
operator T*() const { return 0; }

template<typename C, typename T>
operator T C::*() const { return 0; }

private:
// suppress address-of operator because it
// is meaningless to take the address of this
// null pointer
void operator&() const;

} NULLPTR;

// Create a set of overloaded functions to try this out.
// First takes an int, second takes a char*.

void f(int x)
{
cout << "f(int x) has been called\n";
return;
}

void f(char* str)
{
cout << "f(char* str) has been called\n";
return;
}


// main
int main(int argc, char* argv[])
{
f(NULLPTR);
return 0;
}


The expected outcome is, of course, "f(char* str) has been called". Can you get this to compile and run on XCode?

P.S. If keyword "typename" does not work, replace with "class".

 

Yup, that's the problem.

According to the C++ Standard, uninitialized const pointers are automatically initialized to 0 and will compile. The following are all legal, though I haven't checked this yet on XCode:

const char* str; // okay, but will probably error in XCode
const string* str; // ditto
const MyClass* mcp; // ditto

However, const values must be initialized explicitly:

const int x; // error, x must be given a value
const int x = 0; // okay

In the NULLPTR example, try to find a way to initialize the const. For example:

const class
{
public:
...
private:
...
} NULLPTR = 0; // this won't work because there
// is no conversion from int to "const class"

However, the following should be okay, but now we no longer have an anonymous class and a class constructor has been added. (The class is intentionally anonymous because it is not meant to be instantiated by clients.)

Reworked NULLPTR to please XCode:

const class _nullptr // no longer anonymous
{
public:
template<class T>
operator T*() const { return 0; }

template<typename C, typename T>
operator T C::*() const { return 0; }

// this constructor will allow conversion from int to _nullptr
// and allow the const class initialization below.
_nullptr( int ) { }

private:
void operator&() const;

} NULLPTR = 0;


A couple of other issues with XCode:

1. One nice feature is the ability to selectively enable different categories of warnings. For example, your code can be checked against several "Effective C++" coding guidelines. However, turn this option on and try to compile. Error.

2. A minor issue: after dragging and dropping text from one place in your code to another, the cursor remains an arrow until the window is repainted. On the cool side, your selected text comes along for the drag-ride, rather than just the cursor point.


XCode looks like a very good start, but its "1.0"-ness shows every now and then. The "Intelli-Sense" implementation is very promising but less refined than Microsoft's -- too many function alternatives are sometimes displayed, some of which are simply inscrutable.

 

XCode provides the following "C Language Standards" in the GNU C/OBJ C compiler settings pane:

ANSI-C
C89
GNU89
C99
GNU99

However, with the exception of ANSI-C, these are all C, not C++ standards. Attempts to use them will result in a warning such as the following if C99 is selected:

"-std=c99" is valid for C/ObjC but not for C++

However, the C++ standard is evolving and, as you've pointed out, not all compilers implement the same version of the standard or even implement the standard fully. The standards document is, unfortunately, dense and extensive - but precise and thorough.

As a follow-up to the issue of const initialization, XCode does in fact allow uninitialized const pointers:

const int* intp; // okay
const char* charp; // okay

However, NULLPTR is of type "const class" which is not a pointer. XCode is therefore consistent in allowing uninitialized const pointers, but rejecting uninitialized const scalars. It simply does not differentiate between simple scalars such as int, double, float, etc., and complex scalars such as classes and structs.

All of this brings up another thought: C++ is just too complicated. It can be a challenge to learn-- and of course rewarding once you've learned it. But the promise of OO -- reduced cost of maintenance, reduced learning curve for new developers, extensibility, reusability, testability, etc. -- are sometimes lost amid the difficulty of getting a team to use it properly and to be mindful of the many pitfalls (i.e. design errors, omissions, oversights).

Java and C# (or more properly, .NET) are promoting a different view: component centric development rather than object centric. The promise of OO might finally be realized. Object-centric development gave us COM/DCOM/ATL/CORBA along with DLL Hell and obscure resource leaks. Managed environments such as the .NET CLR or the Java Runtime appear to be a more holistic solution to the fundamental problem of developing quality software efficiently and deploying it with equal success.

Apple's preference for Objective C over C++ stems from decisions made long ago by NeXT, but given a choice today they might still opt for Objective C.

 

Apple's engineers provide feedback and suggestions to GNU. It is not unrealistic to think they might also be contributing both code and bug fixes a la Safari. Taking from the Open Source community and contributing back to it is not a bad business model. However, it does not really provide a competitive differentiation of your product. This might be okay because Apple does not market the Macintosh on the basis of its compiler. However, software is becoming more sophisticated (particularly vertical market s/w) and it is getting more expensive to develop, debug, and deploy.

Whatever one thinks of Microsoft personally, the .NET Framework is a small revolution in software development. The basic ideas (listed below) are not new, but they have been assembled into a cohesive framework that is very practical and addresses many of the core problems in client-server or multi-tier programming. The basic ideas are:

1. Language independence leading to binary reuse of components.
2. Runtime management including runtime security, JIT compiling, and garbage collection (memory management).
3. Location transparency or remoting.
4. Versioned assemblies; secure and strongly-named assemblies.
5. Concurrency management.
6. Simplified OO development language -- C# -- a streamlined version of C++.

Microsoft wants to standardize various component technologies in .NET such as the common language runtime and C#. These have been taken up by the ISO:

ISO C# documentation:
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=36768&ICS1=35&ICS2=60&ICS3=

ISO CLI (common language infrastructure) documentation:
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=36769&ICS1=35&ICS2=60&ICS3=

Apple is promoting the use of standards-based development tools and technologies. Perhaps this is something they ought to consider.

As a recent switcher I am not familiar with Mac programming or ObjC. The string concatenation example in ObjC does look horrible, while the same thing in C++ looks beautiful... However, this is a simple use of C++. It can get worse. A lot worse.

C++ has an abundance of features and other features to allow the primary features to be applied consistently. And there is code the compiler generates for you. Forget to write a copy constructor? No problem, the compiler will do it for you. Forget to write a type conversion operator. The compiler will try to find an indirect conversion that works. None of this is really a bad thing, but it requires the programmer to go through the learning curve well. It is harder to become a C++ expert than to become a C expert.

However, the programming language we use is only one piece of the software development and deployment process. Rapid application development hinges on being able to reuse binary components; i.e., to develop applications from Lego blocks. This is where XCode and the GNU compiler tools stop short (referring to the 6 item list above).

 

OpenDoc, OCX/COM, CORBA all facilitate the development of components. The basic premise for a component is simply the separation of interface from implementation. Provide clients a well-defined and hopefully immutable interface and let the implementation appear to your clients to be a black box.

However, there is more involved in making component use and reuse practical and productive. The first 5 of the 6 items in the previous list need to be addressed.

I don't know how much of this ancillary infrastructure was provided by OpenDoc, but if much of it was then Apple was really on to something. However, it seems to me that OpenDoc was not really targeted for N-tier application development; it was designed primarily for rich interaction between applications running on the same machine -- object linking and embedding. In this model, applications remain separate entities, but sections of their open documents (hence the name) can be imported into other cooperating applications and treated "natively".

The UNIX foundation of OS X makes it more compelling now to develop something akin to .NET that facilitates component development and deployment on one or more tiers. With XServe, Apple is targeting N-tier software markets but relying primarily on web servers to provide the requisite plumbing. However, not all N-tier systems can be developed around a web server, and in fact many are not. In summary, there are 3 problems here:

1. Provide a means to build applications rapidly by making component development and reuse practical (preferably even across language barriers).

2. Provide a means to deploy components and applications built from them in a safe and version-tight manner.

3. Provide a means for scalability to N-tiers.

 

On second thought OpenDoc was about creating a document-centric model and getting away from application-centrism. A document was a tabula rasa into which any application could contribute something of value - a chart from A, a table from B, a spreadsheet from C, a video clip from D, overall page formatting provided by E, spell checking courtesy of F, fancy typesetting from G, etc.