diff --git a/doc/optional.html b/doc/optional.html index 8ed169f..9c76a8b 100644 --- a/doc/optional.html +++ b/doc/optional.html @@ -4,7 +4,7 @@ - + Header @@ -92,7 +92,7 @@ if ( p.second )

The model

In C++, we can declare an object (a variable) of type T, and we can give this variable an initial value (through an initializer. (c.f. 8.5)).
- When a declaration includes a non-empty inilializer (an initial value is given), it is said that + When a declaration includes a non-empty initializer (an initial value is given), it is said that the object has been initialized.
If the declaration uses an empty initializer (no initial value is given), and neither default nor value initialization applies, it is said that the object is @@ -103,7 +103,7 @@ if ( p.second ) the value of an uninitialized object is undefined behaviour. That is, when a variable is declared as optional<T> and no initial value is given, the variable is formally uninitialized. A formally uninitialized optional object has conceptually - no value at all and this situation can be tested at runtime. It is formally undefined behvaiour + no value at all and this situation can be tested at runtime. It is formally undefined behaviour to try to access the value of an uninitialized optional. An uninitialized optional can be assigned a value, in which case its initialization state changes to initialized. And given the formal treatment of initialization states in optional objects, it is even possible to @@ -114,7 +114,7 @@ if ( p.second ) information to tell if an object has been effectively initialized.
One of the typical ways in which this has been historically dealt with is via a special value: EOF,npos,-1, etc... This is equivalent to adding - the special value to the set of possibles values of a given type. + the special value to the set of possible values of a given type. On modern languages, this can be modeled with a discriminated union of T and something else such as a trivial POD or enum. Discriminated unions are often called variants. @@ -126,7 +126,7 @@ if ( p.second )

A discriminated union, which can be seen as a container which has an object of either type T or something else, has exactly the semantics required for a wrapper of optional values:

  • deep-copy semantics: copies of the variant implies copies of the contained value.
    • -
  • deep-relational semantics: comparions between variants matches both current types and values
    • +
  • deep-relational semantics: comparisons between variants matches both current types and values
  • If the variant's current type is T, it is modeling an initialized optional.
  • If the variant's current type is not T, it is modeling an uninitialized optional.
  • Testing if the variant's current type is T models testing if the optional is initialized
    • @@ -180,24 +180,24 @@ bool operator != ( optional<T> const& lhs, optional<T> const& copies of pointers do not involve copies of pointees. This effect results in aliasing: different pointers can refer to the same object. The particular semantic that a copy of a pointer does not involve - a copy of the pointee is called shallow-copy, which is opossed to deep-copy were + a copy of the pointee is called shallow-copy, which is oppossed to deep-copy were a copy of a wrapper involves a copy of the wrapped object (as with optional<>)
    Since this is the semantic followed by pointers (and references), shallow-copy (and therefore aliasing) is implied in pointer semantics.

    The other relevant feature of a pointer is that a pointer can have a null pointer value. This is a special value which is used to indicate that the pointer is not referring to any object at all. In other words, null pointer - values convey the notion of inexisting objects.

    + values convey the notion of inexistent objects.

    This meaning of the null pointer value allowed pointers to became a defacto standard for handling optional objects because all you have to do to refer to a value which you don't really have is to use a null pointer value of the appropriate type. Pointers have been used for decades -from the days of C APIs to modern C++ libraries- - to refer to optional (that is, possibly inexisting) objects; particularly + to refer to optional (that is, possibly inexistent) objects; particularly as optional arguments to a function, but also quite often as optional data members.

    The possible presence of a null pointer value makes the operations that access the pointee's value possibly undefined, therefore, expressions which use dereference and access operators, such as: ( *p = 2 ) and ( p->foo()), - implicitely convey the notion of optionality, and this information is tied to + implicitly convey the notion of optionality, and this information is tied to the syntax of the expressions. That is, the presence of operators * and -> tell by themselves -without any additional context-, that the expression will be undefined unless the implied pointee actually exist.
    @@ -206,7 +206,7 @@ bool operator != ( optional<T> const& lhs, optional<T> const& the form: if ( p != 0 ), or if ( p ) to be used to test for the existence of the pointee.

    Such a defacto idiom for referring to optional objects can be formalized in the form of a concept: the OptionalPointee concept.
    -This concept captures the syntatic usage of operatos *, -> and conversion to bool to convey +This concept captures the syntactic usage of operatos *, -> and conversion to bool to convey the notion of optionality.

    However, pointers are good to refer to optional objects, but not particularly good to handle the optional objects in all other respects, such as initializing or moving/copying @@ -223,7 +223,7 @@ them. The problem resides in the shallow-copy of pointer semantics: if you need a builtin or small POD, this technique is very poor in terms of required resources. Optional objects are essentially values so it is very convenient to be able to use automatic storage and deep-copy semantics to manipulate optional values just as we do with ordinary - values. Pointers do not have this semantics so are unapprorpiate for the initialization and + values. Pointers do not have this semantics, so are unapprorpiate for the initialization and transport of optional values, yet are quite convenient for handling the access to the possible undefined value because of the idiomatic aid present in the OptionalPointee concept incarnated by pointers.
    @@ -807,7 +807,8 @@ class Fred

    A note about optional<bool>

    optional<bool> should be used with special caution and consideration.

    First, it is functionally similar to a tristate boolean (false,maybe,true) --such as boost::tribool-, except that in a tristate boolean, the maybe state +-such as boost::tribool (not yet formally in boost)-, +except that in a tristate boolean, the maybe state represents a valid value, unlike the corresponding state of an uninitialized optional<bool>.
    It should be carefully considered if an optional bool instead of a tribool is really needed

    @@ -907,9 +908,9 @@ T is not required to be type_with_alignment (both from Type Traits). It uses a separate boolean flag to indicate the initialization state.
    Placement new with T's copy constructor and T's destructor - are explicitely used to initialize,copy and destroy optional values.
    + are explicitly used to initialize,copy and destroy optional values.
    As a result, T's default constructor is effectively by-passed, but the exception - guarantess are basic.
    + guarantees are basic.
    It is planned to replace the current implementation with another with stronger exception safety, such as a future boost::variant.

    @@ -918,8 +919,8 @@ T is not required to be

    Dependencies and Portability

    -

    The implementation uses type_traits/alignement_of.hpp -and type_traits/type_with_alignement.hpp

    +

    The implementation uses type_traits/alignment_of.hpp +and type_traits/type_with_alignment.hpp

    It has been tested on bcc5.5.1, vc6.0 and gcc2.95.2

    @@ -945,7 +946,7 @@ and type_traits/type_with_alignement.hpp

    Post-formal review:

    -

    William Kempf carrefully considered the originally proposed interface +

    William Kempf carefully considered the originally proposed interface and suggested the new interface which is currently used. He also started and fueled the discussion about the analogy optional<>/smart pointer and about relational operators.
    diff --git a/index.html b/index.html new file mode 100644 index 0000000..cac816c --- /dev/null +++ b/index.html @@ -0,0 +1,9 @@ + + + + + +Automatic redirection failed, please go to +doc/optional.html. + + \ No newline at end of file