Skip to content

Commit

Permalink
Undeed some of Crayon's changes
Browse files Browse the repository at this point in the history
  • Loading branch information
@shauleiz
shauleiz committed Jan 13, 2016
1 parent 69192b3 commit 3cce81e
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions inc/public.h
View file
Original file line number Diff line number Diff line change
Expand Up @@ -55,9 +55,9 @@ DEFINE_GUID(GUID_DEVINTERFACE_VJOY, 0x781EF630, 0x72B2, 0x11d2, 0xB8, 0x52, 0x00
#else
#define DEVICENAME_STRING "vJoy"
#endif
#define NTDEVICE_NAME_STRING "\\Device\\" DEVICENAME_STRING
#define SYMBOLIC_NAME_STRING "\\DosDevices\\" DEVICENAME_STRING
#define DOS_FILE_NAME "\\\\.\\" DEVICENAME_STRING
#define NTDEVICE_NAME_STRING "\\Device\\"DEVICENAME_STRING
#define SYMBOLIC_NAME_STRING "\\DosDevices\\"DEVICENAME_STRING
#define DOS_FILE_NAME "\\\\.\\"DEVICENAME_STRING
#define VJOY_INTERFACE L"Device_"

// Version parts
Expand Down

4 comments on commit 3cce81e

@Crayon2000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @shauleiz, just so I understand. What is the reason why this change was reverted?

@shauleiz
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Crayon,
I'm a big fan of "If it ain't broke don't fix it"
I did not go into the finesses of the syntax of #define.
Either the blank does not matter (so why fix it)
Or it does - so we should not change it because it might brake backwards compatibility.

Actually, many of the changes that did go in might also fall under this category. However, redundant ';' is considered as bad practice.

@Crayon2000
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either the blank does not matter (so why fix it)

Yes it does matter, but it's for forward compatibility. Since I'm not that good for explaining stuff this an explanation (lightly modified for this context) from Daniel Holbert at https://bugzilla.mozilla.org/show_bug.cgi?id=865396

So, this code is trying to do string concatenation (where 'DEVICENAME_STRING' is a macro-parameter for a string literal). BUT in C++ 11, the code "\Device"DEVICENAME_STRING could be interpreted differently, because C++11 has special syntax for characters immediately following a string literal. They're interpreted as being a user-defined literal suffix, sort of like the suffixes after numeric literals in 7.0f and 1000u.

More information here:
http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals
and see in particular this example from that wikipedia page, demonstrating the syntax:
> OutputType some_variable = "1234"_ssuffix; // Uses the 'const char *' overload.

SO ANYWAY: If we insert a space between the two string literals, the result is unchanged and it becomes unambiguous even in light of the new C++11 syntax.

@shauleiz
Copy link
Owner Author

@shauleiz shauleiz commented on 3cce81e Jan 14, 2016 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please sign in to comment.