Tapatalk

new C++14 single quotation marks in binary literals

new C++14 single quotation marks in binary literals

1
NewbieNewbie
1

    Jul 16, 2017#1

    Dear people,

    I'm having UltraEdit version 15.00.0.1035.

    The new C++14 adds support for binary literals like 0b00010010. That's great. And you can also add digit separators with the single quotation mark to further enhance readability. Like this 0b0001'0010. But currently in UltraEdit with C++ syntax highlighting the single quote is interpreted as a character/string quotation. I think I do need to adjust my C++ wordfile in order to prevent Ultraedit to color my binary literals like strings.

    I'm no guru in Regular Expressions and I'm afraid when altering the Regular Expression fields I might break something in the syntax highlighting feature.

    I cannot identify anything in the wordfile that will define the syntax of the "Number" Color Group. So, I'm lost to see how I can implement this.

    Would someone please show me how I should adjust the wordfile to have the syntax highlighting working properly for C++14 binary literals?

    Thank you.

    6,685587
    Grand MasterGrand Master
    6,685587

      Jul 16, 2017#2

      UltraEdit up to currently latest v24.10.0.24 supports regular expressions only for parsing a file for strings listed in function list view.

      All words (according to definition of word delimiters as defined on line starting /Delimiters =) starting with a digit are automatically interpreted as numbers.

      Everything between "..." or '...' whereby there is no backslash before " or ' is highlighted as string because of Escape Char = \ String Chars = "' in the wordfile c_cplusplus.uew which can be opened via Advanced - Configuration - Editor Display - Syntax Highlighting.

      So it is impossible to define a syntax highlighting rule with a regular expression which informs syntax highlighting feature of UltraEdit to interpret ' not as word delimiter and also not as begin/end of a string when existing in active file within a number consisting only of 0s and 1s and starting with 0b.

      What is possible is modifying in c_cplusplus.uew
      • in first line String Chars = "' to just String Chars = ",
      • remove on line starting with /Delimiters = the single quote character ',
      • insert above line starting with /C1 a line with /Marker Characters = "''" (two single quotes enclosed in two double quotes), and
      • add '' (two single quotes as in marker characters definition) like a keyword to any existing color group or to a new color group like /C6"Single Quoted".
      This results in getting 0b0001'0010 highlighted completely as number and for example 'x' highlighted with the color defined for the color group containing the two single quotes as keyword.

      But this works only if there are left and right of 'x' always word delimiting characters as defined on line starting with /Delimiters = which is usually the case in C/C++ source files.

      And this solution has the disadvantage that '\'' is not highlighted correct anymore because of the backslash character inside marker characters string is not interpreted anymore as escape character.

      I have used binary representation of a number sometimes in assembler code, but never in C/C++ code. I have used in C/C++ always just decimal or hexadecimal representation of a number even when initializing special function registers of a controller in C/C++ like in assembler.

      I think the main reason for this difference on binary representation usage between assembler and C/C++ code is that in C++ and C it was not possible without using a preprocessor macro before C++14. And whenever I initialize a special function register in my source code files I add above a large comment block explaining in detail what each bit of the value is responsible for and therefore it does not really matter if the value read by assembler/compiler is specified in code in binary or in hexadecimal notation.

      Furthermore after 25 years of programming, hexadecimal and binary numbers are interpreted by my brain without any delay. For me reading 13 is like reading 0x0D or 0b00001101. I can access the hexadecimal and binary values from 0 to 255 with my eyes closed.
      Best regards from an UC/UE/UES for Windows user from Austria