Merge pull request #3905 from corob-msft/docs/corob/bulk-entity-6

PRMerger12 · web-flow · commit 4b0fb9c85432 · 2021-11-10T19:46:31.000-08:00
Remove HTML ehtities for hyphen
diff --git a/docs/build/reference/hint-files.md b/docs/build/reference/hint-files.md
@@ -155,7 +155,7 @@ The illustration shows some of the physical directories in a Visual Studio C++ p
 
 ### Hint File Directories
 
-![Common and project&#45;specific hint file directories.](media/hintfile.png "HintFile")
+![Diagram showing the common and project specific hint file directories.](media/hintfile.png)
 
 ### Directories and Hint File Contents
 
diff --git a/docs/cpp/arrays-cpp.md b/docs/cpp/arrays-cpp.md
@@ -164,7 +164,7 @@ int i2[5][7];
 
 It specifies an array of type **`int`**, conceptually arranged in a two-dimensional matrix of five rows and seven columns, as shown in the following figure:
 
-![Conceptual layout of a multi dimensional array.](../cpp/media/vc38rc1.gif "Conceptual layout of a multi&#45;dimensional array") <br/>
+![Conceptual layout of a multi dimensional array.](../cpp/media/vc38rc1.gif) <br/>
 Conceptual layout of a multi-dimensional array
 
 You can declare multidimensioned arrays that have an initializer list (as described in [Initializers](../cpp/initializers.md)). In these declarations, the constant expression that specifies the bounds for the first dimension can be omitted. For example:
diff --git a/docs/cpp/cpp-bit-fields.md b/docs/cpp/cpp-bit-fields.md
@@ -62,7 +62,7 @@ struct Date {
 
 then the memory layout is as shown in the following figure:
 
-![Layout of a Date object with a zero length bit field, which forces alignment padding.](../cpp/media/vc38uq2.png "Layout of Date object with zero&#45;length bit field") <br/>
+![Layout of a Date object with a zero length bit field, which forces alignment padding.](../cpp/media/vc38uq2.png) <br/>
 Layout of Date Object with Zero-Length Bit Field
 
 The underlying type of a bit field must be an integral type, as described in [Built-in types](../cpp/fundamental-types-cpp.md).
diff --git a/docs/cpp/cpp-type-system-modern-cpp.md b/docs/cpp/cpp-type-system-modern-cpp.md
@@ -52,7 +52,7 @@ The fundamental types are recognized by the compiler, which has built-in rules t
 
 The following illustration shows the relative sizes of the built-in types in the Microsoft C++ implementation:
 
-![Diagram of the relative size in bytes of several built in types.](../cpp/media/built-intypesizes.png "Size in bytes of built&#45;in types")
+![Diagram of the relative size in bytes of several built in types.](../cpp/media/built-intypesizes.png)
 
 The following table lists the most frequently used fundamental types, and their sizes in the Microsoft C++ implementation:
 
diff --git a/docs/cpp/function-overloading.md b/docs/cpp/function-overloading.md
@@ -283,7 +283,7 @@ This same rule applies to pointer-to-member conversions. Conversion from type `T
 
 The preceding rule applies only along a given path of derivation. Consider the graph shown in the following figure.
 
-![Diagram of multiple inheritance that shows preferred conversions.](../cpp/media/vc391t2.gif "Multiple&#45;inheritance that shows preferred conversions") <br/>
+![Diagram of multiple inheritance that shows preferred conversions.](../cpp/media/vc391t2.gif) <br/>
 Multiple-inheritance graph that shows preferred conversions
 
 Conversion from type `C*` to type `B*` is preferable to conversion from type `C*` to type `A*`. The reason is that they are on the same path, and `B*` is closer. However, conversion from type `C*` to type `D*` isn't preferable to conversion to type `A*`; there's no preference because the conversions follow different paths.
diff --git a/docs/cpp/multiple-base-classes.md b/docs/cpp/multiple-base-classes.md
@@ -48,7 +48,7 @@ Simulated lunch-line graph
 
 In the figure, `Queue` is the base class for both `CashierQueue` and `LunchQueue`. However, when both classes are combined to form `LunchCashierQueue`, the following problem arises: the new class contains two subobjects of type `Queue`, one from `CashierQueue` and the other from `LunchQueue`. The following figure shows the conceptual memory layout (the actual memory layout might be optimized).
 
-![Simulated lunch line object.](../cpp/media/vc38xp2.gif "Simulated lunch&#45;line object") <br/>
+![Simulated lunch line object.](../cpp/media/vc38xp2.gif) <br/>
 Simulated lunch-line object
 
 Note that there are two `Queue` subobjects in the `LunchCashierQueue` object. The following code declares `Queue` to be a virtual base class:
@@ -64,17 +64,17 @@ class LunchCashierQueue : public LunchQueue, public CashierQueue {};
 
 The **`virtual`** keyword ensures that only one copy of the subobject `Queue` is included (see the following figure).
 
-![Simulated lunch line object, virtual base classes.](../cpp/media/vc38xp3.gif "Simulated lunch&#45;line object, virtual base classes") <br/>
+![Diagram showing a simulated lunch line object, with virtual base classes.](../cpp/media/vc38xp3.gif)<br/>
 Simulated lunch-line object with virtual base classes
 
 A class can have both a virtual component and a nonvirtual component of a given type. This happens in the conditions illustrated in the following figure.
 
-![Virtual and nonvirtual components of a class.](../cpp/media/vc38xp4.gif "Virtual and non&#45;virtual components of a class") <br/>
+![Diagram showing virtual and non virtual components of a class.](../cpp/media/vc38xp4.gif)<br/>
 Virtual and non-virtual components of the same class
 
 In the figure, `CashierQueue` and `LunchQueue` use `Queue` as a virtual base class. However, `TakeoutQueue` specifies `Queue` as a base class, not a virtual base class. Therefore, `LunchTakeoutCashierQueue` has two subobjects of type `Queue`: one from the inheritance path that includes `LunchCashierQueue` and one from the path that includes `TakeoutQueue`. This is illustrated in the following figure.
 
-![Virtual & nonvirtual inheritance in object layout.](../cpp/media/vc38xp5.gif "Virtual & non&#45;virtual inheritance in object layout") <br/>
+![Diagram showing virtual and non virtual inheritance in object layout.](../cpp/media/vc38xp5.gif)<br/>
 Object layout with virtual and non-virtual inheritance
 
 > [!NOTE]
@@ -199,7 +199,7 @@ If virtual base classes are used, functions, objects, types, and enumerators can
 
 The following figure shows how objects are composed using virtual and nonvirtual inheritance.
 
-![Diagram showing virtual derivation and nonvirtual derivation.](../cpp/media/vc38xr1.gif "Virtual derivation and non&#45;virtual derivation") <br/>
+![Diagram showing virtual derivation and nonvirtual derivation.](../cpp/media/vc38xr1.gif)<br/>
 Virtual and non-virtual derivation
 
 In the figure, accessing any member of class `A` through nonvirtual base classes causes an ambiguity; the compiler has no information that explains whether to use the subobject associated with `B` or the subobject associated with `C`. However, when `A` is specified as a virtual base class, there is no question which subobject is being accessed.
diff --git a/docs/cpp/scope-visual-cpp.md b/docs/cpp/scope-visual-cpp.md
@@ -29,7 +29,7 @@ There are six kinds of scope:
 
 You can hide a name by declaring it in an enclosed block. In the following figure, `i` is redeclared within the inner block, thereby hiding the variable associated with `i` in the outer block scope.
 
-![Diagram that shows block scope name hiding.](../cpp/media/vc38sf1.png "Block&#45;scope name hiding") <br/>
+![Diagram that shows block scope name hiding.](../cpp/media/vc38sf1.png)<br/>
 Block scope and name hiding
 
 The output from the program shown in the figure is:
diff --git a/docs/cpp/single-inheritance.md b/docs/cpp/single-inheritance.md
@@ -9,7 +9,7 @@ ms.assetid: 1cb946ed-8b1b-4cf1-bde0-d9cecbfdc622
 
 In "single inheritance," a common form of inheritance, classes have only one base class. Consider the relationship illustrated in the following figure.
 
-![Diagram of a basic single inheritance hierarchy.](../cpp/media/vc38xj1.gif "Basic single&#45;inheritance graph") <br/>
+![Diagram of a basic single inheritance hierarchy.](../cpp/media/vc38xj1.gif)<br/>
 Simple Single-Inheritance Graph
 
 Note the progression from general to specific in the figure. Another common attribute found in the design of most class hierarchies is that the derived class has a "kind of" relationship with the base class. In the figure, a `Book` is a kind of a `PrintedDocument`, and a `PaperbackBook` is a kind of a `book`.
diff --git a/docs/cpp/standard-conversions.md b/docs/cpp/standard-conversions.md
@@ -181,7 +181,7 @@ The first case is when the specified base class is accessible and the conversion
 
 Whether a base class is accessible depends on the kind of inheritance used in derivation. Consider the inheritance illustrated in the following figure.
 
-![Inheritance graph showing base class accessibility.](../cpp/media/vc38xa1.gif "Inheritance graph showing base&#45;class accessibility") <br/>
+![Inheritance graph showing base class accessibility.](../cpp/media/vc38xa1.gif)<br/>
 Inheritance Graph for Illustration of Base-Class Accessibility
 
 The following table shows the base-class accessibility for the situation illustrated in the figure.
