Skip to content

Commit 2bd04c3

Browse files
committed
More tweaks to the compatibility page.
llvm-svn: 124792
1 parent 93adb03 commit 2bd04c3

File tree

1 file changed

+24
-22
lines changed

1 file changed

+24
-22
lines changed

clang/www/compatibility.html

Lines changed: 24 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,7 @@ <h1>Language Compatibility</h1>
6565
<li><a href="#implicit-downcasts">Implicit downcasts</a></li>
6666
</ul>
6767
<ul>
68-
<li><a href="#Use of class as method name">Use of class as method name</a></li>
68+
<li><a href="#class-as-property-name">Using <code>class</code> as a property name</a></li>
6969
</ul>
7070
</li>
7171
</ul>
@@ -418,8 +418,8 @@ <h3 id="vla">Variable-length arrays</h3>
418418
<ul>
419419
<li>The element type of a variable length array must be a POD
420420
("plain old data") type, which means that it cannot have any
421-
user-declared constructors or destructors, base classes, or any
422-
members if non-POD type. All C types are POD types.</li>
421+
user-declared constructors or destructors, any base classes, or any
422+
members of non-POD type. All C types are POD types.</li>
423423

424424
<li>Variable length arrays cannot be used as the type of a non-type
425425
template parameter.</li> </ul>
@@ -428,12 +428,9 @@ <h3 id="vla">Variable-length arrays</h3>
428428

429429
<ol>
430430
<li>replace the variable length array with a fixed-size array if you can
431-
determine a
432-
reasonable upper bound at compile time; sometimes this is as
431+
determine a reasonable upper bound at compile time; sometimes this is as
433432
simple as changing <tt>int size = ...;</tt> to <tt>const int size
434-
= ...;</tt> (if the definition of <tt>size</tt> is a compile-time
435-
integral constant);</li>
436-
<li>use <tt>std::string</tt> instead of a <tt>char []</tt>;</li>
433+
= ...;</tt> (if the initializer is a compile-time constant);</li>
437434
<li>use <tt>std::vector</tt> or some other suitable container type;
438435
or</li>
439436
<li>allocate the array on the heap instead using <tt>new Type[]</tt> -
@@ -762,30 +759,30 @@ <h3 id="implicit-downcasts">Implicit downcasts</h3>
762759
<!-- ======================================================================= -->
763760

764761
<p>Due to a bug in its implementation, GCC allows implicit downcasts
765-
(from base class to a derived class) when calling functions. Such code is
766-
inherently unsafe, since the object might not actually be an instance
767-
of the derived class, and is rejected by Clang. For example, given
768-
this code:</p>
762+
of Objective-C pointers (from a base class to a derived class) when
763+
calling functions. Such code is inherently unsafe, since the object
764+
might not actually be an instance of the derived class, and is
765+
rejected by Clang. For example, given this code:</p>
769766

770767
<pre>
771768
@interface Base @end
772769
@interface Derived : Base @end
773770

774-
void f(Derived *);
775-
void g(Base *base) {
776-
f(base);
771+
void f(Derived *p);
772+
void g(Base *p) {
773+
f(p);
777774
}
778775
</pre>
779776

780777
<p>Clang produces the following error:</p>
781778

782779
<pre>
783780
downcast.mm:6:3: error: no matching function for call to 'f'
784-
f(base);
781+
f(p);
785782
^
786783
downcast.mm:4:6: note: candidate function not viable: cannot convert from
787784
superclass 'Base *' to subclass 'Derived *' for 1st argument
788-
void f(Derived *);
785+
void f(Derived *p);
789786
^
790787
</pre>
791788

@@ -798,13 +795,17 @@ <h3 id="implicit-downcasts">Implicit downcasts</h3>
798795
</pre>
799796

800797
<!-- ======================================================================= -->
801-
<h3 id="Use of class as method name">Use of class as method name</h3>
798+
<h3 id="class-as-property-name">Using <code>class</code> as a property name</h3>
802799
<!-- ======================================================================= -->
803800

804-
<p>Use of 'class' name to declare a method is allowed in objective-c++ mode to
805-
be compatible with GCC. However, use of property dot syntax notation to call
806-
this method is not allowed in clang++, as [I class] is a suitable syntax that
807-
will work. So, this test will fail in clang++.
801+
<p>In C and Objective-C, <code>class</code> is a normal identifier and
802+
can be used to name fields, ivars, methods, and so on. In
803+
C++, <code>class</code> is a keyword. For compatibility with existing
804+
code, Clang permits <code>class</code> to be used as part of a method
805+
selector in Objective-C++, but this does not extend to any other part
806+
of the language. In particular, it is impossible to use property dot
807+
syntax in Objective-C++ with the property name <code>class</code>, so
808+
the following code will fail to parse:</p>
808809

809810
<pre>
810811
@interface I {
@@ -818,6 +819,7 @@ <h3 id="Use of class as method name">Use of class as method name</h3>
818819
@end
819820
<pre>
820821

822+
<p>Use explicit message-send syntax instead, i.e. <code>[I class]</code>.</p>
821823

822824
</div>
823825
</body>

0 commit comments

Comments
 (0)