Update documentation to syntax highlight code

googlemock/docs/FrequentlyAskedQuestions.md

@@ -27,7 +27,7 @@ later.  Fortunately, it's usually not hard to migrate an existing
 matcher to the new API.  Here's what you need to do:
 
 If you wrote your matcher like this:
-```
+```cpp
 // Old matcher definition that doesn't work with the latest
 // Google Mock.
 using ::testing::MatcherInterface;
@@ -44,7 +44,7 @@ class MyWonderfulMatcher : public MatcherInterface<MyType> {
 ```
 
 you'll need to change it to:
-```
+```cpp
 // New matcher definition that works with the latest Google Mock.
 using ::testing::MatcherInterface;
 using ::testing::MatchResultListener;
@@ -65,7 +65,7 @@ argument of type `MatchResultListener*`.)
 
 If you were also using `ExplainMatchResultTo()` to improve the matcher
 message:
-```
+```cpp
 // Old matcher definition that doesn't work with the lastest
 // Google Mock.
 using ::testing::MatcherInterface;
@@ -91,7 +91,7 @@ class MyWonderfulMatcher : public MatcherInterface<MyType> {
 you should move the logic of `ExplainMatchResultTo()` into
 `MatchAndExplain()`, using the `MatchResultListener` argument where
 the `::std::ostream` was used:
-```
+```cpp
 // New matcher definition that works with the latest Google Mock.
 using ::testing::MatcherInterface;
 using ::testing::MatchResultListener;
@@ -110,7 +110,7 @@ class MyWonderfulMatcher : public MatcherInterface<MyType> {
 ```
 
 If your matcher is defined using `MakePolymorphicMatcher()`:
-```
+```cpp
 // Old matcher definition that doesn't work with the latest
 // Google Mock.
 using ::testing::MakePolymorphicMatcher;
@@ -130,7 +130,7 @@ class MyGreatMatcher {
 you should rename the `Matches()` method to `MatchAndExplain()` and
 add a `MatchResultListener*` argument (the same as what you need to do
 for matchers defined by implementing `MatcherInterface`):
-```
+```cpp
 // New matcher definition that works with the latest Google Mock.
 using ::testing::MakePolymorphicMatcher;
 using ::testing::MatchResultListener;
@@ -150,7 +150,7 @@ class MyGreatMatcher {
 
 If your polymorphic matcher uses `ExplainMatchResultTo()` for better
 failure messages:
-```
+```cpp
 // Old matcher definition that doesn't work with the latest
 // Google Mock.
 using ::testing::MakePolymorphicMatcher;
@@ -176,7 +176,7 @@ void ExplainMatchResultTo(const MyGreatMatcher& matcher,
 
 you'll need to move the logic inside `ExplainMatchResultTo()` to
 `MatchAndExplain()`:
-```
+```cpp
 // New matcher definition that works with the latest Google Mock.
 using ::testing::MakePolymorphicMatcher;
 using ::testing::MatchResultListener;
@@ -254,7 +254,7 @@ C++ as much as possible.
 ## MSVC gives me warning C4301 or C4373 when I define a mock method with a const parameter.  Why? ##
 
 If you compile this using Microsoft Visual C++ 2005 SP1:
-```
+```cpp
 class Foo {
   ...
   virtual void Bar(const int i) = 0;
@@ -279,7 +279,7 @@ warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous v
 In C++, if you _declare_ a function with a `const` parameter, the
 `const` modifier is _ignored_.  Therefore, the `Foo` base class above
 is equivalent to:
-```
+```cpp
 class Foo {
   ...
   virtual void Bar(int i) = 0;  // int or const int?  Makes no difference.
@@ -298,7 +298,7 @@ Note that we are talking about the _top-level_ `const` modifier here.
 If the function parameter is passed by pointer or reference, declaring
 the _pointee_ or _referee_ as `const` is still meaningful.  For
 example, the following two declarations are _not_ equivalent:
-```
+```cpp
 void Bar(int* p);        // Neither p nor *p is const.
 void Bar(const int* p);  // p is not const, but *p is.
 ```
@@ -318,7 +318,7 @@ you'll gain insights on why the expectations you set are not met.
 
 ## How can I assert that a function is NEVER called? ##
 
-```
+```cpp
 EXPECT_CALL(foo, Bar(_))
     .Times(0);
 ```
@@ -345,7 +345,7 @@ Whenever you derive from a base class, make sure its destructor is
 virtual.  Otherwise Bad Things will happen.  Consider the following
 code:
 
-```
+```cpp
 class Base {
  public:
   // Not virtual, but should be.
@@ -375,7 +375,7 @@ will be happy.
 
 When people complain about this, often they are referring to code like:
 
-```
+```cpp
 // foo.Bar() should be called twice, return 1 the first time, and return
 // 2 the second time.  However, I have to write the expectations in the
 // reverse order.  This sucks big time!!!
@@ -399,7 +399,7 @@ harder to do so.
 There are two better ways to write the test spec.  You could either
 put the expectations in sequence:
 
-```
+```cpp
 // foo.Bar() should be called twice, return 1 the first time, and return
 // 2 the second time.  Using a sequence, we can write the expectations
 // in their natural order.
@@ -416,7 +416,7 @@ put the expectations in sequence:
 
 or you can put the sequence of actions in the same expectation:
 
-```
+```cpp
 // foo.Bar() should be called twice, return 1 the first time, and return
 // 2 the second time.
 EXPECT_CALL(foo, Bar())
@@ -450,14 +450,14 @@ may creep in unnoticed.
 
 If, however, you are sure that the calls are OK, you can write
 
-```
+```cpp
 EXPECT_CALL(foo, Bar(_))
     .WillRepeatedly(...);
 ```
 
 instead of
 
-```
+```cpp
 ON_CALL(foo, Bar(_))
     .WillByDefault(...);
 ```
@@ -488,12 +488,12 @@ extent, Google Mock's syntax was chosen for several practical advantages it
 has.
 
 Try to mock a function that takes a map as an argument:
-```
+```cpp
 virtual int GetSize(const map<int, std::string>& m);
 ```
 
 Using the proposed syntax, it would be:
-```
+```cpp
 MOCK_METHOD1(GetSize, int, const map<int, std::string>& m);
 ```
 
@@ -503,7 +503,7 @@ around this you can use `typedef` to give the map type a name, but
 that gets in the way of your work.  Google Mock's syntax avoids this
 problem as the function's argument types are protected inside a pair
 of parentheses:
-```
+```cpp
 // This compiles fine.
 MOCK_METHOD1(GetSize, int(const map<int, std::string>& m));
 ```