I gave myself an hour to add multi-line search-and-replace support in my code.  It took 3, and C++11 std::regex_replace() gave me a hard crash with inline replacement.  The syntax can be annoying (for example, using double escape), so for reference, here’s a jumpstart.

Given:

using namespace std;
string str = "Lots of text to search\nacross lines";
string from = "text[\\s\\S]*lines";
string to = "rainbows";

Boost happily did the job:

#include 
 boost::regex reg;
 reg.assign(from);
 str = boost::regex_replace(str,reg,to,boost::match_default);

C++11 is even simpler, but it crashes with gcc 4.9.2 if you use the same string for source and target, like this:

#include 
 std::regex reg(from);
 str = std::regex_replace(str,reg,to);

You can fix that by using a swap string:

#include 
 regex reg(from);
 string newstr = regex_replace(str,reg,to);
 str = newstr;

But it isn’t working across lines, with this particular syntax, and I’ve seen others complain that they couldn’t get multiline syntax going.  I’ll stick with boost for now until this smooths out a little bit more.  Onwards.

 

I really like the “fast” C++11 types, that give best performance for a guaranteed minimum bit width. Use them when you know a variable will not exceed the maximum value of that bit width, but does not have to be a precise bit width in memory or elsewhere.

Pick specific-width fields whenever data is shared with other processes and components and you want a guarantee of its bit width.

And when using pointer size and array indices you should use types defined for those specific situations.

FAST types:


    int_fast8_t
    int_fast16_t                fastest signed integer type with width of
    int_fast32_t                at least 8, 16, 32 and 64 bits respectively
    int_fast64_t

    uint_fast8_t
    uint_fast16_t               fastest unsigned integer type with width of
    uint_fast32_t               at least 8, 16, 32 and 64 bits respectively
    uint_fast64_t

SMALL types:


    int_least8_t
    int_least16_t               smallest signed integer type with width of
    int_least32_t               at least 8, 16, 32 and 64 bits respectively
    int_least64_t

    uint_least8_t
    uint_least16_t		smallest unsigned integer type with width of
    uint_least32_t		at least 8, 16, 32 and 64 bits respectively
    uint_least64_t

EXACT types:


    int8_t                      signed integer type with width of
    int16_t                     exactly 8, 16, 32 and 64 bits respectively
    int32_t                     with no padding bits and using 2's complement for negative values
    int64_t                     (provided only if the implementation directly supports the type)

    uint8_t                     unsigned integer type with width of
    uint16_t                    exactly 8, 16, 32 and 64 bits respectively
    uint32_t                    (provided only if the implementation directly supports the type)
    uint64_t

SPECIFIC-USE types:


    intptr_t                    integer type capable of holding a pointer
    uintptr_t                   unsigned integer type capable of holding a pointer 
    size_t                      unsigned integer type capable of holding an array index (same size as uintptr_t)

Pretty much SAY BYE BYE TO [int]! 🙂 …or when going across OSes and 32/64bit platforms you will be playing with this matrix of fun (originally from here):

image2

c++11 containers
sorted_vector use when doing lots of unsorted insertions and maintaining constant sort would be expensive
map sorted binary search tree; always sorted by key; you can walk through in sorted order
multimap same as map but allows dupe keys; need for this should be pretty rare
unordered_map hashmap; always sorted by key; additional bucket required for hash collisions; no defined order when walking through
unordered_multimap same as map but allows dupe keys; dupes are obviously in the same bucket, and you can walk just the dupes if needed
set
multiset
unordered_set
unordered_multiset
sets are just like maps, except the key is embedded in the object, great idea
but… they are ruined by the constraint that contained items must be const
but… then redeemed by mutable
You can use mutable on the variable that are not part of the key to remove the const!
This changes the constness of the object from binary (completely const) to logical (constness is defined by the developer)
so… set is an excellent way to achieve both encapsulation and logical const

Final note: using object pointers is the ultimate solution.
The entire object can be dereferenced and accessed then without const issues.
Two requirements: you must make sure yourself that you do not change the key values;
you must create sort functors that dereference the pointers to sort using object contents if needed
(the default sorting will be by pointer address).
The arguably biggest advantage, as a result, is that you can create multiple sets
to reference the same group of objects with different sort funtors to create multiple indices.
OH YEAH! 🙂