In the last article we examined some simple examples of how to use RE. We will quickly review part one.

One quick note, most programs expect an RE to be on a single line. That is, if looking for three ‘a’ (a{3}) in a row, most programs expect to find

not

The later example can be constructed as a RE – but not by all programs, and only when explicitly told to do so. We won't cover that here.

One thing we have not discussed up until now is if we could detect whether a match occurred. In some cases, we might want to know if the RE did not bind. Specifically, Perl, Awk, Lex and Yacc are languages which can take action base on the returned value of a RE. In the next section, we will see examples of how this works.

Some of the meta-characters we did not considered in the first article include:

These meta-characters are modifiers on other meta-characters. If we use the ‘.’ as an example, then we might better see how they are used. To refresh our memory, the period ‘.’ is a meta-character that binds to any character.

So, if we use the modifiers in conjunction with the period we get:

In the first example, the ‘.?’, usually phrased as 'zero or one' occurrence, will always succeed, or return a value of true. Similarly so, ‘.*’ will always return true. However, when we use ‘.+’, this means that we must bind to with at least one (1) character or the value return is false. As a side note, a single period without a modifier ‘.’ will return true if once it finds one character. If it finds no characters, it returns false.

Another noteworthy item is the greediness of the star (*) character. When the star is used in conjunction with the ‘.’ symbol, it grabs all the characters. This might matter when trying to parse data fields, like CSV (comma separated values). In just a bit we will see how this matters, and one way to handle this.

One special case worth noting is the meta-characters that defines a character exclusion set. It is written like this:

[^n] bind to any lower case alphabetic character, except ‘n’

This useful when we want to grab a string encased in a pair of delimiters. Here are some common examples:

In the first example, grab anything in between commas. In the second example, we grab anything inside a pair of double quotes. Both are commonly used for CSV (comma separated values) formats. The third example is similar to the second, except we use single quotes and it only returns true if there is something in between the quotes. The fourth example grabs the first word on the beginning of a line.

I should now continue with the point mentioned earlier about the star ‘*’ being greedy when it binds. If you'll note, in the last set of examples I wrote

not

The reason is, in the later case, the star (*) becomes greedy and grabs everything after the first single quote ("), even the end-of-line character. To avoid this, we wrote ("[^"]*").

To explain this a bit further, let's look at the character set exclusion rule, [^"]. This tells us to we want to exclude the double quote (") character from our set. Implicitly, this says “include everything else”. As such, if we include the portion with the star ([^"]*), the RE will bind to all characters, except the double quote ("). It will then continue until it finds the next double quote or the end-of-line. If it finds the end-of-line, it will fail (or return false).

If we then include a look at the original RE, we see that it will bind when it finds the first double quote ("), then stop when it finds the next double quote ("). Also, unless it finds both double quotes, the RE will return false.

Lastly, with regards to using quoting characters, some programs ‘interpret’ the meaning of characters within the quotes. For example, when using Lex, all meta-characters lose their meta meaning when inside double quotes, except for “C escape sequences”.

One other special case worth mentioning are the grouping symbols. Their meta-characters are:

They can be used by themselves, but are often used in combination to form more complex statements. Here is an example with the pipe character ‘|’.

In this example, the RE will bind with any of the three words. That is, this RE example will return true if either cow, pig or sheep is found on the line.

As for the round braces, we will give the fairly complex example:

We can see the RE breaks into 2 parts. On the left is [0-9]+. On the right is [0-9]*\.[0-9]+

The left binds to one or more numerical digits. The right binds to a decimal value that may or may not start with a numerical digit and trails with one or more numerical digits. For example:

Lastly, there is precedent ordering. With the exception of *grouping*, RE does not have precedent ordering; it works from left to right. That is, if you build a slightly more complex RE, the binding starts from the left and works to the right. Here is a quick example:

Some legal results are:

That's it. I hope you found this short tutorial and examples useful. In the next article, I hope to show RE in action with Lex, the lexical analyzer.

C++ inline functions may optimise code: inline function saves you the overhead of a function call, that is: loading parameters onto the stack, making a jump, popping parameters off the stack, and then do it all in reverse when you return.

Modern CPUs have pipelines that a function call can disrupt when called, and again, when it returns. By inlining we potentially allow the CPU to further improve execution.

Not only this, but a compiler may be able to optimise code which it has been inlined in a way it cannot if there is a function call simply because the optimisation becomes visible, e.g. optimising register allocations. In the case of empty functions – fairly typical of constructors – making the function inline may allow the compiler to remove the call altogether.

Sometimes an inline function may save time and space. Making a function call requires instruction codes to make the call both on the part of the caller and callee. On occasions, the number of bytes required for this may actually be greater than the number of bytes in the function body itself.

With these kinds of optimisations available, we might wonder why we don’t just make all functions inline. In my opinion there are downsides that out weigh the advantages.

For starters, inline is only a hint to the compiler. The compile can ignore it if the function is too big or too complex. Compilers differ in what they will and will not inline.

Other reasons I avoid using inline are:

• Code bloat: inline functions usually make your code bigger because you duplicate code for each function invocation.
• Increased CPU cache misses: if you increase a function’s size with inline functions, it may outgrow the cache, and fewer big functions may be held in cache at once.
• Coupling between headers and implementation increases. A header with interface and implementation is more likely to change than one with interface alone. Changes in a combined header file will cause a bigger rebuild because other files depend on your header files. By contrast, if the code is in the implementation file, only that file needs to be recompiled. On large systems the difference can be hours.
• By giving the implementation in the header file you are less likely to be able to forward declare classes, so you have to include another header file – increasing coupling and making the code less flexible and more prone to ripple effects – again increasing build times.
• Perhaps more significant is what a lot of inline functions says about your design. Inlining is typically used for get and set functions. Classes with lots of such functions aren’t really hiding anything, they are just containers for values that begs the question – just how object-oriented is your design?
• Finding code in source files can be time consuming. If you have lots of inline functions you need to look in .h files as well. This may seem trivial, but on a large system with several thousand files the time adds up.

Inlines may improve performance. However, they will always make your code less flexible.