5.0 minor polish

Author: ruby0x1

work-in-progress/build/5.0-building-a-dynamic-library-from-hxcpp.md

@@ -4,7 +4,7 @@ The idea that you could tell the haxe compiler and hxcpp backend to create a dll
 
 This concept however is not easily approached, as the issue lies in how c++ works, and the many reasons that c++ is not typically used in the outward facing API of a dynamic library. It is important to understand and reiterate that hxcpp is simply just c++ code in the end. It can't do what c++ can't do without the limitations of c++ being present. 
 
-To make that a more concrete issue, it is worth stepping back and considering what the common issues are for exposing c++ functions in a dynamic library. Take note that there is a stark difference between c functions, and c++ functions. Specifically talking about c++ - it carries with it significant weight that makes using it in a dynamic library often impractical or impossible.
+To make that a more concrete issue, it is worth stepping back and considering what the common issues are for exposing c++ functions and types in a dynamic library. Take note that there is a stark difference between c functions, and c++ functions. Specifically talking about c++ - it carries with it significant weight that makes using it in a dynamic library often impractical or impossible.
 
 Also note that explicitly the term _outward facing API_ is used above. Having c++ code in a dynamic library is not much of an issue - but rather trying to use that code across the dynamic library boundaries, i.e by importing it as the API interface itself. Below we will cover some reasons as to why.
 
@@ -16,15 +16,15 @@ The reasons are many, and if your narrow requirements manage to fit past the num
 
 Since the scope of how c++ and dynamic libraries work in detail is wide, and this guide is about using hxcpp more effectively, we will only cover the broadest of strokes as to the problems involved. There will be many simplifications below to get the point across. There are countless articles and documents on why c++ inside of a dynamic library is not typically the outward facing API, as this problem is not a new one to the language.
 
-Note again, that these issues have everything to do with c++ itself, and not the hxcpp which uses c++ to function.
+Note again, that these issues have everything to do with c++ itself, and not the hxcpp backend which uses c++ to function.
 
 ### Challenge 1: Name mangling
 
 It's likely you would have heard of this issue when dealing with c++ exports in a dynamic library. When creating code in plain c, functions were _symbols_ and had a singular place - in other words - there was no _namespace_ and no _function overloads_ to make a symbol ambiguous. If you had a symbol called `my_function` that was the only symbol that would be allowed in your linked code with that name. This is one source of the ever so common duplicate symbol errors you will encounter in c/c++.
 
 However, there is a way for a function symbol in plain c to be ambiguous, and that relates direclty to the [calling convention](https://en.wikipedia.org/wiki/X86_calling_conventions). If your function exists as a symbol such as `my_function` there is no real way to ascertain what calling convention was intended/required by the author of the code - so when using certain conventions, the name will need to be "decorated" to differentiate.
 
-Here's an example from the page on Name Mangling of how that looks for three calling conventions. You don't need to understand all the underlying details of the conventions themselves but just understand the existence of name mangling in context of c and later c++.
+Here's an example from the Wikipedia page on [Name Mangling](https://en.wikipedia.org/wiki/Name_mangling) of how that looks for three calling conventions. You don't need to understand all the underlying details of the conventions themselves but just understand the existence of name mangling in context of c and later c++.
 
 ```c++
 int _cdecl    f (int x) { return 0; }
@@ -46,9 +46,9 @@ Notice how the `_f` is undecorated, and the others are decorated. This is name m
 
 Since c++ added namespaces, function overloads and many other ways to differentiate the same symbol, it required a much more elaborate name mangling scheme in order for the exact symbol to be found later.
 
-The scheme is defined by the c++ compiler itself, rather than by the language. This is a crucial issue to take note of, that name mangling is not well defined. Trying to compile a library and using that library elsewhere will require full knowledge of the mangling scheme and how to decode it. In simpler terms, it means that the exact same compiler must be used for the library as well as the _client_ in order to know it will decode correctly. This is a huge limitation of course, as you may want to build a library to be consumed by another language (like python or c#) and having to know at runtime what the library is compiled against for decoding the mangling is not all that practical, especially across multiple platforms and compilers. 
+The scheme is defined by the c++ compiler itself, rather than by the language. This is a crucial issue to take note of, that name mangling is not well defined. Trying to compile a library and using that library elsewhere will require full knowledge of the mangling scheme and how to decode it. In simpler terms, it means that the exact same compiler must be used for the library as well as the _client_ in order to know it will decode correctly. This is a huge limitation of course, as you may want to build a library to be consumed by another language (like python or c#) and having to know at runtime what the library is compiled against for decoding the mangling is not all that practical, especially across multiple platforms and compilers. Still some people attempt this, YMMV.
 
-Let's take a really simple example again from the name mangling page linked above.
+Let's take a really simple example again from the name mangling page linked above, this time compiled by a c++ compiler (instead of c).
 
 ```c++
 int  f (void) { return 1; }