Changeset b52d900


Ignore:
Timestamp:
Apr 12, 2016, 6:28:37 PM (8 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, string, with_gc
Children:
3849857
Parents:
4b8f918
Message:

extend user manual, update latex macros, and update reference manual

Location:
doc
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/LaTeXmacros/common.tex

    r4b8f918 rb52d900  
     1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
     2%%
     3%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
     4%%
     5%% The contents of this file are covered under the licence agreement in the
     6%% file "LICENCE" distributed with Cforall.
     7%%
     8%% common.tex --
     9%%
     10%% Author           : Peter A. Buhr
     11%% Created On       : Sat Apr  9 10:06:17 2016
     12%% Last Modified By : Peter A. Buhr
     13%% Last Modified On : Sat Apr  9 10:06:39 2016
     14%% Update Count     : 1
     15%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     16
    117%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    218

  • doc/refrat/refrat.tex

    r4b8f918 rb52d900  
    1111%% Created On       : Wed Apr  6 14:52:25 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Apr  8 18:32:07 2016
    14 %% Update Count     : 6
     13%% Last Modified On : Sat Apr  9 10:19:12 2016
     14%% Update Count     : 8
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    2626\usepackage{listings}
    2727\usepackage{comment}
    28 \usepackage{latexsym}                                   % \Box
    29 \usepackage{mathptmx}                                   % better math font with "times"
     28\usepackage{latexsym}                                   % \Box
     29\usepackage{mathptmx}                                   % better math font with "times"
    3030\usepackage[pagewise]{lineno}
    3131\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    … …  
    3939\input{common}
    4040
    41 \setcounter{secnumdepth}{3}     % number subsubsections
    42 \setcounter{tocdepth}{3}                % subsubsections in table of contents
     41%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     42
     43\setcounter{secnumdepth}{3}                             % number subsubsections
     44\setcounter{tocdepth}{3}                                % subsubsections in table of contents
    4345\makeindex
    4446
    … …  
    4749\begin{document}
    4850\pagestyle{headings}
    49 \linenumbers                                    % comment out to turn off line numbering
     51\linenumbers                                            % comment out to turn off line numbering
    5052
    5153\title{\Huge
     54\vspace*{1in}
    5255\CFA (\CFL) Reference Manual and Rationale
    5356}% title

  • doc/user/user.tex

    r4b8f918 rb52d900  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Apr  8 11:40:53 2016
    14 %% Update Count     : 42
     13%% Last Modified On : Sun Apr 10 22:50:15 2016
     14%% Update Count     : 72
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    2121
    2222% Latex packages used in the document.
    23 \usepackage[T1]{fontenc}
     23\usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
    2424\usepackage{textcomp}
    2525\usepackage[latin1]{inputenc}
    … …  
    3131\usepackage{footmisc}
    3232\usepackage{comment}
    33 \usepackage{latexsym}                                   % \Box
    34 \usepackage{mathptmx}                                   % better math font with "times"
     33\usepackage{latexsym}                                   % \Box
     34\usepackage{mathptmx}                                   % better math font with "times"
    3535\usepackage[pagewise]{lineno}
    3636\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    … …  
    4141%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    4242
    43 % Names used in the document.
    44 
    45 \newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
    46 
    47 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    48 
    4943% Bespoke macros used in the document.
    5044\input{common}
    5145
    52 \setcounter{secnumdepth}{3}     % number subsubsections
    53 \setcounter{tocdepth}{3}                % subsubsections in table of contents
     46%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     47
     48% Names used in the document.
     49
     50\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
     51
     52%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     53
     54\setcounter{secnumdepth}{3}                             % number subsubsections
     55\setcounter{tocdepth}{3}                                % subsubsections in table of contents
    5456\makeindex
    5557
    … …  
    5860\begin{document}
    5961\pagestyle{headings}
    60 \linenumbers                                    % comment out to turn off line numbering
     62\linenumbers                                            % comment out to turn off line numbering
    6163
    6264\title{\Huge
    … …  
    7274}% author
    7375\date{
    74 DRAFT\\\today
     76DRAFT \\
     77\today
    7578}% date
    7679
    … …  
    100103
    101104\CFA\footnote{Pronounced ``C-for-all'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed an as evolutionary step forward from the C programming language.
    102 The syntax of the \CFA language builds from that of C, and should look immediately familiar to C programmers.
     105The syntax of the \CFA language builds from C, and should look immediately familiar to C programmers.
    103106% Any language feature that is not described here can be assumed to be using the standard C11 syntax.
    104 \CFA has added many modern programming-language features, which directly leads to increased safety and productivity, while maintaining interoperability with existing C programs, and maintaining C-like performance.
     107\CFA adds many modern programming-language features, which directly leads to increased safety and productivity, while maintaining interoperability with existing C programs and maintaining C-like performance.
    105108Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global garbage-collection.
    106109The primary new features include parametric-polymorphism routines and types, exceptions, concurrency, and modules.
    … …  
    113116New programs can be written in \CFA using a combination of C and \CFA features.
    114117\CC had a similar goal 30 years ago, but has struggled over the intervening time to incorporate modern programming-language features because of early design choices.
    115 \CFA has 30 years of hindsight and a much cleaner starting point than \CC.
     118\CFA has 30 years of hindsight and clean starting point.
    116119
    117120Like \CC, there may be both an old and new ways to achieve the same effect.
    … …  
    138141\end{quote2}
    139142Both programs output the same result.
    140 While the \CFA I/O looks similar to the \CC style of output, there are several important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
     143While the \CFA I/O looks similar to the \CC output style, there are several important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
    141144
    142145This document is a reference manual for the \CFA programming language, targeted at \CFA programmers.
    143 Implementers may also refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
     146Implementers may refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
    144147In its current state, this document covers the intended core features of the language.
    145148Changes to the syntax and additional features are expected to be included in later revisions.
    … …  
    153156The original \CFA project~\cite{Ditchfield92} extended the C type system with parametric polymorphism and overloading, as opposed to the \CC approach of object-oriented extensions to the C type-system.
    154157A first implementation of the core Cforall language was created~\cite{Bilson03,Esteves04}, but at the time there was little interesting in extending C, so work did not continue.
    155 As the saying goes, ``What goes around, comes around'', and there is now renewed interest in the C programming language, so the \CFA project has been restarted.
    156 
    157 
    158 \section{Motivation: Why fix C?}
     158As the saying goes, ``What goes around, comes around'', and there is now renewed interest in the C programming language because of legacy code-bases, so the \CFA project has been restarted.
     159
     160
     161\section{Why fix C?}
    159162
    160163Even with all its problems, C is a very popular programming language because it allows writing software at virtually any level in a computer system without restriction.
    … …  
    173176Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
    174177These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
    175 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be complete rewritten.
     178As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
    176179These costs can be prohibitive for many companies with a large software base in C/\CC, and many programmers that require retraining to a new programming language.
    177180
    … …  
    190193This feature allows users of \CFA to take advantage of the existing panoply of C libraries from inside their \CFA code.
    191194In fact, one of the biggest issues for any new programming language is establishing a minimum level of library code to support a large body of activities.
    192 Programming-language developers often state that adequate library support costs many times more than designing and implementing the language itself.
     195Programming-language developers often state that adequate library support takes more work than designing and implementing the language itself.
    193196Like \CC, \CFA starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at very low cost.
    194197
    … …  
    197200Whereas, \CFA wraps each of these routines into one with the common name \lstinline@abs@.
    198201\begin{lstlisting}
     202char abs( char );
    199203extern "C" {
    200 #include <stdlib.h>                     // provide C prototype for integer "abs" routine
     204int abs( int );                         // use default C routine for int
    201205} // extern "C"
    202 
    203 char abs( char );
    204 long int abs( long int );       // @{\CFA}@ overload name "abs" for other types
     206long int abs( long int );
    205207long long int abs( long long int );
    206208float abs( float );
    … …  
    219221The name ``\lstinline@abs@'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
    220222Hence, knowing the name \lstinline@abs@ should be sufficient to apply it to any type where it is applicable.
    221 The time savings and safety of using one name uniformly versus @N@ unique names should not be underestimated.
     223The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
    222224
    223225
    … …  
    273275the type suffixes \lstinline@U@, \lstinline@L@, etc. may start with an underscore \lstinline@1_U@, \lstinline@1_ll@ or \lstinline@1.0E10_f@.
    274276\end{enumerate}
    275 It is significantly easier to read and type long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
     277It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
    276278This extension is backwards compatible, matches with the use of underscore in variable names, and appears in Ada and Java.
    277279
    … …  
    290292\begin{lstlisting}
    291293int (*f())[ 10 ] {...};
    292 ... (*f())[ 3 ] += 1;           // definition mimics usage
     294... (*f())[  3 ] += 1;  // definition mimics usage
    293295\end{lstlisting}
    294296Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
    … …  
    299301The only exception is bit field specification, which always appear to the right of the base type.
    300302C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
    301 Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
    302 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
    303 e.g.:
    304 \begin{lstlisting}
    305 x;                                      // int x
    306 *y;                                     // int *y
    307 f( p1, p2 );            // int f( int p1, int p2 );
    308 f( p1, p2 ) {}          // int f( int p1, int p2 ) {}
    309 \end{lstlisting}
    310303
    311304In \CFA declarations, the same tokens are used as in C: the character \lstinline@*@ is used to indicate a pointer, square brackets \lstinline@[@\,\lstinline@]@ are used to represent an array, and parentheses \lstinline@()@ are used to indicate a routine parameter.
    … …  
    333326* [ 10 ] double v;
    334327struct s {
    335 int f0:3;
     328        int f0:3;
    336329        * int f1;
    337330        [ 10 ] * int f2;
    … …  
    363356\end{quote2}
    364357
    365 As stated above, the two styles of declaration may appear together in the same block.
    366 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
    367 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
    368 In general, mixing declaration styles in a routine or even a translation unit is not recommended, as it makes a program more difficult to read.
    369 Therefore, it is suggested that an entire translation unit be written in one declaration style or the other.
    370 
    371358All type qualifiers, i.e., \lstinline@const@ and \lstinline@volatile@, are used in the normal way with the new declarations but appear left to right, e.g.:
    372359\begin{quote2}
    … …  
    411398\end{quote2}
    412399
     400Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
     401At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
     402e.g.:
     403\begin{lstlisting}
     404x;                                              // int x
     405*y;                                             // int *y
     406f( p1, p2 );                    // int f( int p1, int p2 );
     407f( p1, p2 ) {}                  // int f( int p1, int p2 ) {}
     408\end{lstlisting}
     409
     410As stated above, the two styles of declaration may appear together in the same block.
     411Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
     412Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
     413
    413414
    414415\section{Type Operators}
    … …  
    448449Declaration qualifiers can only appear at the start of a routine definition, e.g.:
    449450\begin{lstlisting}
    450 extern [ int x ] g( int y ) {}
     451extern [ int x ] g( int y ) {@\,@}
    451452\end{lstlisting}
    452453Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
    453454in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    454455\begin{lstlisting}
    455 [ ] g();                                        // no input or output parameters
     456[@\,@] g(@\,@);                         // no input or output parameters
    456457[ void ] g( void );                     // no input or output parameters
    457458\end{lstlisting}
    … …  
    568569\section{Named and Default Arguments}
    569570
    570 Named and default arguments~\cite{Hardgrave76}.\footnote{
     571Named and default arguments~\cite{Hardgrave76}\footnote{
    571572Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
    572573are two mechanisms to simplify routine call.
    … …  
    836837
    837838Currently, there are no \Index{lambda} expressions, i.e., unnamed routines because routine names are very important to properly select the correct routine.
    838 
    839 
    840 \section{Incompatible}
    841 
    842 The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
    843 
    844 \begin{enumerate}
    845 \item
    846 Change type of character literal \lstinline@int@ to \lstinline@char@.
    847 This change allows overloading differentiation argument type matching, e.g.:
    848 \begin{lstlisting}
    849 int function( int i );
    850 int function( char c );
    851 function( 'x' );
    852 \end{lstlisting}
    853 It is preferable that this call match the second version of function rather than the first. \\
    854 Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on
    855 \begin{lstlisting}
    856 sizeof('x') == sizeof(int)
    857 \end{lstlisting}
    858 will not work the same as C++ programs. \\
    859 Difficulty of converting: Simple. \\
    860 How widely used: Programs which depend upon sizeof('x') are probably rare.
    861 
    862 \item
    863 Change: String literals made \lstinline@const@ \\
    864 The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
    865 The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
    866 Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
    867 Effect on original feature: Change to semantics of well-defined feature. \\
    868 Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
    869 The most common cases are handled by a new but deprecated standard conversion:
    870 \begin{lstlisting}
    871 char* p = "abc"; // valid in C, deprecated in C++
    872 char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
    873 \end{lstlisting}
    874 How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.
    875 
    876 \item
    877 Change: C++ does not have \emph{tentative definitions} as in C.
    878 E.g., at file scope,
    879 \begin{lstlisting}
    880 int i;
    881 int i;
    882 \end{lstlisting}
    883 is valid in C, invalid in C++.
    884 This makes it impossible to define mutually referential file-local static
    885 objects, if initializers are restricted to the syntactic forms of C. For example,
    886 \begin{lstlisting}
    887 struct X { int i; struct X *next; };
    888 static struct X a;
    889 static struct X b = { 0, &a };
    890 static struct X a = { 1, &b };
    891 \end{lstlisting}
    892 Rationale: This avoids having different initialization rules for builtin types and userdefined types.
    893 Effect on original feature: Deletion of semantically welldefined feature. \\
    894 Difficulty of converting: Semantic transformation.
    895 In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization.
    896 How widely used: Seldom.
    897 
    898 \item
    899 Change: A struct is a scope in C++, not in C \\
    900 Rationale: Class scope is crucial to C++, and a struct is a class. \\
    901 Effect on original feature: Change to semantics of well-defined feature. \\
    902 Difficulty of converting: Semantic transformation. \\
    903 How widely used: C programs use struct extremely frequently, but the change is only noticeable when struct, enumeration, or enumerator names are referred to outside the struct.
    904 The latter is probably rare.
    905 
    906 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
    907 Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
    908 Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
    909 
    910 
    911 \item
    912 Change: In C++, the name of a nested class is local to its enclosing class.
    913 In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class
    914 Example:
    915 \begin{lstlisting}
    916 struct X {
    917 struct Y { /* ... */ } y;
    918 };
    919 struct Y yy; // valid C, invalid C++
    920 \end{lstlisting}
    921 Rationale: C++ classes have member functions which require that classes establish scopes. The C rule
    922 would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining
    923 locality within a class. A coherent set of scope rules for C++ based on the C rule would be very
    924 complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples
    925 involving nested or local functions.
    926 Effect on original feature: Change of semantics of welldefined
    927 feature.
    928 Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of
    929 the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing
    930 struct is defined. Example:
    931 \begin{lstlisting}
    932 struct Y; // struct Y and struct X are at the same scope
    933 struct X {
    934 struct Y { /* ... */ } y;
    935 };
    936 \end{lstlisting}
    937 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of
    938 the enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of
    939 the difference in scope rules, which is documented in 3.3.
    940 How widely used: Seldom.
    941 \end{enumerate}
    942839
    943840
    … …  
    40613958
    40623959
     3960\section{Incompatible}
     3961
     3962The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
     3963
     3964\begin{enumerate}
     3965\item
     3966Change type of character literal \lstinline@int@ to \lstinline@char@.
     3967This change allows overloading differentiation argument type matching, e.g.:
     3968\begin{lstlisting}
     3969int function( int i );
     3970int function( char c );
     3971function( 'x' );
     3972\end{lstlisting}
     3973It is preferable that this call match the second version of function rather than the first. \\
     3974Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on
     3975\begin{lstlisting}
     3976sizeof('x') == sizeof(int)
     3977\end{lstlisting}
     3978will not work the same as C++ programs. \\
     3979Difficulty of converting: Simple. \\
     3980How widely used: Programs which depend upon sizeof('x') are probably rare.
     3981
     3982\item
     3983Change: String literals made \lstinline@const@ \\
     3984The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
     3985The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
     3986Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
     3987Effect on original feature: Change to semantics of well-defined feature. \\
     3988Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
     3989The most common cases are handled by a new but deprecated standard conversion:
     3990\begin{lstlisting}
     3991char* p = "abc"; // valid in C, deprecated in C++
     3992char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
     3993\end{lstlisting}
     3994How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.
     3995
     3996\item
     3997Change: C++ does not have \emph{tentative definitions} as in C.
     3998E.g., at file scope,
     3999\begin{lstlisting}
     4000int i;
     4001int i;
     4002\end{lstlisting}
     4003is valid in C, invalid in C++.
     4004This makes it impossible to define mutually referential file-local static
     4005objects, if initializers are restricted to the syntactic forms of C. For example,
     4006\begin{lstlisting}
     4007struct X { int i; struct X *next; };
     4008static struct X a;
     4009static struct X b = { 0, &a };
     4010static struct X a = { 1, &b };
     4011\end{lstlisting}
     4012Rationale: This avoids having different initialization rules for builtin types and userdefined types.
     4013Effect on original feature: Deletion of semantically welldefined feature. \\
     4014Difficulty of converting: Semantic transformation.
     4015In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization.
     4016How widely used: Seldom.
     4017
     4018\item
     4019Change: A struct is a scope in C++, not in C \\
     4020Rationale: Class scope is crucial to C++, and a struct is a class. \\
     4021Effect on original feature: Change to semantics of well-defined feature. \\
     4022Difficulty of converting: Semantic transformation. \\
     4023How widely used: C programs use struct extremely frequently, but the change is only noticeable when struct, enumeration, or enumerator names are referred to outside the struct.
     4024The latter is probably rare.
     4025
     4026\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
     4027Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
     4028Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
     4029
     4030
     4031\item
     4032Change: In C++, the name of a nested class is local to its enclosing class.
     4033In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class
     4034Example:
     4035\begin{lstlisting}
     4036struct X {
     4037struct Y { /* ... */ } y;
     4038};
     4039struct Y yy; // valid C, invalid C++
     4040\end{lstlisting}
     4041Rationale: C++ classes have member functions which require that classes establish scopes. The C rule
     4042would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining
     4043locality within a class. A coherent set of scope rules for C++ based on the C rule would be very
     4044complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples
     4045involving nested or local functions.
     4046Effect on original feature: Change of semantics of welldefined
     4047feature.
     4048Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of
     4049the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing
     4050struct is defined. Example:
     4051\begin{lstlisting}
     4052struct Y; // struct Y and struct X are at the same scope
     4053struct X {
     4054struct Y { /* ... */ } y;
     4055};
     4056\end{lstlisting}
     4057All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of
     4058the enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of
     4059the difference in scope rules, which is documented in 3.3.
     4060How widely used: Seldom.
     4061\end{enumerate}
     4062
     4063
    40634064\section{I/O Library}
    40644065\label{s:IOLibrary}
Note: See TracChangeset for help on using the changeset viewer.