MSVC Compatibility

- Changed location of pointer operator in declarations.
  - Updated `CODESTYLE.md` to reflect this.
  - Updated `API_AND_NAMESPACE.md` to reflect this.
This commit is contained in:
Jim Derry 2017-03-02 09:32:02 -05:00
parent 81d2d26883
commit 92621d6f99
4 changed files with 17 additions and 2 deletions

View file

@ -36,6 +36,18 @@ The `TIDY_EXPORT` call clearly indicates that this function prototype is meant t
Although this makes things obvious from the documentation perspective, the truth is a little murkier. In some environments one might define `TIDY_EXPORT` and `TIDY_CALL` differently in order to control compiler behavior, especially in environments that have special requirements for dynamic libraries. In general, though, you shouldn't have to worry about this. Although this makes things obvious from the documentation perspective, the truth is a little murkier. In some environments one might define `TIDY_EXPORT` and `TIDY_CALL` differently in order to control compiler behavior, especially in environments that have special requirements for dynamic libraries. In general, though, you shouldn't have to worry about this.
Note that MSVC has issues with macros inserted before pointer operators, and so the preferred use of pointer operators when documenting with macros is this:
~~~
const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )
~~~
…instead of this:
~~~
const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter )
~~~
# External types are opaque # External types are opaque

View file

@ -18,6 +18,9 @@ From reading of the Tidy source, some things are self evident... in no particula
- No C++ single line comments using `//`. - No C++ single line comments using `//`.
- The openning `{` is indented on the next newline. - The openning `{` is indented on the next newline.
- While the maximum code line length varies, generally long `if`, `while`, ... statements are wrapped to newlines. - While the maximum code line length varies, generally long `if`, `while`, ... statements are wrapped to newlines.
- For compatibility with MSVC, pointer operators in declarations must precede any macro documentation, e.g, `const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )` instead of `const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter )`.
Look forward to this document being filled out in detail... Look forward to this document being filled out in detail...

View file

@ -1173,7 +1173,7 @@ TIDY_EXPORT TidyIterator TIDY_CALL getWindowsLanguageList();
* Returns the next record of type `localeMapItem` in * Returns the next record of type `localeMapItem` in
* Tidy's structure of Windows<->POSIX local mapping. * Tidy's structure of Windows<->POSIX local mapping.
*/ */
TIDY_EXPORT const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter ); TIDY_EXPORT const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter );
/** /**
* Given a `tidyLocalMapItem`, return the Windows name. * Given a `tidyLocalMapItem`, return the Windows name.

View file

@ -2428,7 +2428,7 @@ TidyIterator TIDY_CALL getWindowsLanguageList()
//#define tidyOptionToImpl( topt ) ((const TidyOptionImpl*)(topt)) //#define tidyOptionToImpl( topt ) ((const TidyOptionImpl*)(topt))
//#define tidyImplToOption( option ) ((TidyOption)(option)) //#define tidyImplToOption( option ) ((TidyOption)(option))
const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter ) const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )
{ {
/* Get a real structure */ /* Get a real structure */
const tidyLocaleMapItemImpl *item = TY_(getNextWindowsLanguage)( iter ); const tidyLocaleMapItemImpl *item = TY_(getNextWindowsLanguage)( iter );