Thanks for this, one question, where is CXX defined ?
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
CXX is defined in the bowels of make somewhere. It is the default variable for the C++ compiler, and is used in the rules for constructing default recipes. So for example, suppose you had an otherwise empty directory with only one file, hello.cpp, in it. Without needing to create a Makefile, you can build the hello executable just by saying "make hello". There's default rules for all kinds of things, C, Fortran, ranlib (.a) libraries, yacc, tex, and on and on. You can get a list of available recipes by saying "make -p", which for my version of make produces 1357 lines of output.
The CXX variable can be overridden by specifiying a shell variable of the same name at run time, so if for example you wanted to see what error messages clang++ spits out instead of g++ you can say
CXX=clang++ make target
Similarly you have CXXFLAGS and CPPFLAGS which pass arguments to the C++ compiler and the CPreProcessor, respectively. So you could say
gnu make hack: You can rebuild everything from scratch, even if already compiled, without having to "make clean" by using the -B flag
It should also be noted that the Makefile I provided earlier uses GNU makeisms e.g. $(wildcard),$(patsubst). If you find yourself on a BSD or other unix like system that does not have GNU tools installed, the given make file will fail. But the variable substitutions mentioned here will still work.
I have a more or less strict rule i.e. to wit in particular to be specific namely things that act like pointers are passed via copy constructor not via reference since raw pointers are fundamental type objects so take up little space and a reference is a pointer anyway. I agree w/ the chap who suggested passing only what the function requires i.e. first, last iterators. Further at point of call the code is easier to understand its purpose as it passes only what the function requires also it just looks better and is easier to understand as fewer ideas/concepts are involved namely the one idea/concept "iterator" rather than the two ideas/concepts "iterator and container". Was there not a recent article in a recent CP newsletter discussing this very thing i.e. minimizing the number of ideas/concepts needed to understand any code?
No problem: the iterator is a pointer in a UTF-8 encoded string and the function (called next) has to advance to the next code point (1, 2, 3 or 4 char). If iterator is at end of string it doesn't advance.
Although a very simple function, I had a number of design decisions to make:
- How should I deal with improperly encoded UTF-8 strings? I decided to return false if the string is not properly encoded.
- Should I just leave out the boundary check and just document it? I decided against as it would have been unsafe.
And the last one I was asking about: For limit check, should I just pass the string or the end iterator.
It means that your "tcbcollecter" list was empty when you assigned the "tcbitrate" iterator. Calling begin() on an empty list will give you the end() iterator, because there is no real element to point to. You can't dereference it because it doesn't point at anything.