Skip to content

[docs] Doc and typo fixes #2098

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 9, 2016
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions docs/ErrorHandlingRationale.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1072,10 +1072,10 @@ from out-of-memory conditions. For this reason, many C++ projects
explicitly disable exceptions and rely on other error propagation
mechanisms, on which there is no widespread consensus.

Objective C
Objective-C
-----------

Objective C has a first-class exceptions mechanism which is similar in
Objective-C has a first-class exceptions mechanism which is similar in
feature set to Java's: ``@throw`` / ``@try`` / ``@catch`` / ``@finally``.
Exception values must be instances of an Objective-C class. The
language does a small amount of implicit frame cleanup during
Expand All @@ -1084,18 +1084,18 @@ stack copies of ``__block`` variables are torn down, and ARC ``__weak``
variables are destroyed. However, the language does not release
object pointers held in local variables, even (by default) under ARC.

Objective C exceptions used to be implemented with ``setjmp``,
Objective-C exceptions used to be implemented with ``setjmp``,
``longjmp``, and thread-local state managed by a runtime, but the only
surviving platform we support which does that is i386, and all others
now use a "zero-cost" implementation that interoperates with C++
exceptions.

Objective C exceptions are *mostly* only used for unrecoverable
Objective-C exceptions are *mostly* only used for unrecoverable
conditions, akin to what I called "failures" above. There are a few
major exceptions to this rule, where APIs that do use exceptions to
report errors.

Instead, Objective C mostly relies on manual propagation,
Instead, Objective-C mostly relies on manual propagation,
predominantly using out-parameters of type ``NSError**``. Whether the
call failed is usually *not* indicated by whether a non-``nil`` error
was written into this parameter; calls are permitted both to succeed
Expand All @@ -1110,7 +1110,7 @@ null object result is valid.
CF APIs, meanwhile, have their own magnificent set of somewhat
inconsistent conventions.

Therefore, we can expect that incrementally improving CF / Objective C
Therefore, we can expect that incrementally improving CF / Objective-C
interoperation is going to be a long and remarkably painful process.


Expand Down
6 changes: 3 additions & 3 deletions docs/OptimizationTips.rst
Original file line number Diff line number Diff line change
Expand Up @@ -59,9 +59,9 @@ This mode can be enabled using the Xcode build setting 'Whole Module Optimizatio
Reducing Dynamic Dispatch
=========================

Swift by default is a very dynamic language like Objective-C. Unlike Objective
C, Swift gives the programmer the ability to improve runtime performance when
necessary by removing or reducing this dynamicism. This section goes through
Swift by default is a very dynamic language like Objective-C. Unlike Objective-C,
Swift gives the programmer the ability to improve runtime performance when
necessary by removing or reducing this dynamism. This section goes through
several examples of language constructs that can be used to perform such an
operation.

Expand Down