i := 1;

print i;

i := "Hello World";

print i;

i := Derived2 (1, "Hello Word");

print i;

C++ is of course stronger typed as C - it won'd implicidly convert a void* to andy other pointer type any more. And with dynamic_cast it got a lot safer. But saddly C++ improved there type system only for pointer and classes but not for primitive types. The fact that you can't do:

void f (unsigned i)
  {
  auto signed j = dynamic_cast <signed> (i); // raise range_error when i > MAX_INT.
  }

or

typedef explicit int Apple_Count;
typedef explicit int Pear_Count;

auto Apple_Count Apples;
auto Pear_Count Pears;

Apples = Apples + Pears; // Compile error: you can't add apples to pears.

is a missed oportunity. The first would have improved C++ in the arena of "save" and the 2nd in the arena if "strong". I know that if Apple_Count and Pear_Count where classes then C++ would be "strong" and not add apples to pears. It is just that for the building block, the foundation of all classes: primitive types C++ still is weakly-typed.

Of corse non of the attribute static/dynamic, strong/weak, safety is a one or the other. The question is: which direction does a language lean to.

--Krischik ^T 06:38, 29 September 2006 (UTC)[reply]

You raise some interesting points. Using dynamic_cast<> on primitives would indeed be a novel approach to safe integer casting, though I think I'd rename it for primitive conversions. dynamic_cast<> would be expected to raise bad_cast, not range_error. I'd prefer a different casting operator for primitives, i.e. primitive_cast<>.

One of the benefits of C++, of course, is we can often add something that is not provided. For example, to implement primitive_cast<>:

 template <class TO_, class FROM_> TO_ primitive_cast(FROM_ from)
 {
     //use numeric_limits<TO_> to detect detect valid range for TO_ type
     //throw range_type() if invalid range
 }

And to use it (for example):

 void f (unsigned i)
 {
     auto signed j = primitive_cast <signed> (i);
 }

The weakness here, of course, is the lack of enforcement. The primitive_cast can be eliminated, or, in fact, you could even specify the wrong type in the TO_ parameter, and the compiler would not raise an error. In this sense, I agree, C++ can be considered somewhat weakly typed for primitives.

Your second point, about typedef'd names being interchangeable, is due to the fact that typedef is type aliasing - no new type is defined by typedef. The apple/pear example could be made fully type safe by making them classes:

 class Apple_Count
 { 
 private: 
   int count;
 public:
   explicit Apple_Count (int c) { count = c; }
   Apple_Count operator+(const Apple_Count& rhs)
   {
       return Apple_Count(count + rhs.count);
   }
 };
 
 class Pear_Count
 { 
 private: 
   int count;
 public:
   explicit Pear_Count (int c) { count = c; }
   Pear_Count operator+(const Pear_Count& rhs)
   {
       return Pear_Count(count + rhs.count);
   }
 };
 
 auto Apple_Count Apples;
 auto Pear_Count Pears;
 Apples = Apples + Pears; // This will raise a compile error.

This will raise a compile error. This same kind of class encapsulation technique can be used in the first example as well, to prevent implicit primitive conversion.

So, perhaps the answer here is what you have implied above: that C++ classes, pointers, and references are more strongly typed than primitives, with the further caveat that things like reinterpret_cast basically allow the programmer to ignore the type system completely. In essence, this goes to the design goals of C++ - you can be as strongly typed as you want to be; C++ written using primitives everywhere will not be as strongly typed as one that uses purely classes, so the choice is really left to the programmer. The point is, C++ gives you the option of writing strongly typed code, but also allows you to get around it if you choose, by using primitives and/or reinterpret_cast<>. ATren 11:22, 29 September 2006 (UTC)[reply]

C++ allows for implicit type conversion. According to the Strongly-typed programming language article, this is not allowed in a strongly-typed language. Implicit type conversion is not allowed in strongly typed languages because it limits the ability of the compiler to determine type errors at compile time.

Here is an example that adds a character to an integer and prints 109 without complaining.

#include <iostream>
using namespace std;

int main()
{
        char a = 'a';
        int b = 12;
        int c = a + b;
        cout << c << "\n";

        return 0;
}

Since this is a controversial point in this discussion, I am not going to change it myself. I want people to read what I wrote, comment on it, and come to a consensus. However, I can promise you that any programming language semantics expert would say that C++ is not strongly typed in the sense that Haskell or Java is strongly typed.

24.124.75.129 03:33, 8 October 2006 (UTC)[reply]

It's a valid question. Personally I believe that C++ has strong typing features, but is not as strong as other languages in terms of implicit conversions (especially for primitive types). On the other hand, templates arguably make C++ more strongly typed than other languages, by (for example) allowing the use of generic collections that are type safe and don't require any casting. So on one hand C++ gives you the ability to write generic code that is very type safe, but then it also provides several different mechanisms to subvert the type system. So I might categorize it as basically strongly typed, but with exceptions. I think it would be incorrect to call it weakly typed, because weakly typed implies there is no type checking facility at all. ATren 21:03, 7 October 2006 (UTC)[reply]

Regardless of the "stronger than other languages" issue, the fact that one can subvert the typing system places C++ in a different category than the truly strongly typed languages such as Haskell or Ada. Also, it is important to note that on the Weak typing article, C++ is called weakly typed, so this issue needs to be resolve between the two articles for consistency.

A common definition of weak typing is the allowance of type coercion with the language's primitive types. Therefore, I feel that it is perfectly fair to call the language weakly typed. Weakly typed does not mean no type system, it just means that the language is not strongly typed.

24.124.75.129 03:42, 8 October 2006 (UTC)[reply]

Maybe "neither" is an appropriate answer? While "strong" may not be appropriate, "weak" seems equally inappropriate, since that lumps it with scripting languages that have almost no typing facility. ATren 15:20, 8 October 2006 (UTC)[reply]

The controversy here is clearly the definition of "strong typing" and it appears that even the experts don't have a solid definition. My copy of "Types and Programming Languages" by Benjamin C. Pierce (a top textbook in the field) does not even have an index entry for "strong typing". Therefore, I am voting for removal of the strong/weak typing label altogether. 24.124.75.129 03:45, 15 October 2006 (UTC)[reply]

I agree. It's clear that C++ is not one or the other, so best to remove it entirely. ATren 04:34, 15 October 2006 (UTC)[reply]

I went ahead and made that change. If anyone objects, please discuss further. 24.124.75.129 21:01, 15 October 2006 (UTC)[reply]

I fear that Java with it's new box-in box-out feature is not strongly typed either any more. But I guess that is another story... --Krischik ^T 13:06, 8 October 2006 (UTC)[reply]

I am not sure that PHP was influenced by C++, although PHP5 is now leaning towards that direction. PHP until version 5 had no method of overloading operators, overloading functions, strongly typed variables, and remains completely interpreted.

PHP has no sensible OOP-style programming model before PHP5, and has no try..catch methods.

I conclude that if PHP is, in fact, based on C++, since it rejects so many of these major advances by the C++ foundation, that it is, in fact based on C, and not C++. {{subst:unsigned|129.31.85.158 }

Well, PHP4 had a C++ style class declaration (I don't know if it has similar semantics, though). But yes, I agree that the influence is rather tentative. Keeping in mind WP:OR, soes anybody have references for or against? Something from the PHP web site maybe?--Stephan Schulz 07:34, 10 October 2006 (UTC)[reply]