Review of Overload "editorials"

Frances Buontempo from BuontempoConsulting

I have run Charles Stross' code over my Overload "editorials" in the hope of generating some kind of end of year review. Any favourite phrases anyone?

the incoming information and produced metres of punched cards, for example musing on the name to the death of Ceefax. Started in and being replaced by keyboards. On Wednesday I got 0. On Wednesday I got 258 (plus some on accounts.

the perpetual call. There is the problem. Seek its axioms, based on Euclid’s, were consistent, in other words it does not mean by a configuration file, if a program written in 1976 [vi]. Many editors allow syntax high-lighting now, adding an.

the words 'Surreal' 'Mutation' standing out proudly. Word clouds are played through the hole representing the frequency of words contained in documents. A more traditional approach would present a histogram, with bars showing how many times an item appears. Wikipedia suggests.

the creation of the calculus gave ways to form the language, though paused for Turing. Secondly, armed with an automatic Computer Science paper generator, [SCIGen] and allow me to order to say “Many then fall in love with their brains engaged.

the system within the system, but when it’s dead. Perhaps code is easier to work with from another language than a team of programmers who were obsessed with C++ by writing a parser for C++, which can read a 300-page book..

the mouse (1968) and ways of solving problems to emerge. Introduction of the calculus gave ways of us the fore [Matthews]. Perhaps code is a long history and churn of members, using the Standard Template Library, I was a histogram, with.

the way humans did things, hoping this was a lucky find that allowed translation between languages. Can you will have to press the trendy face of ways to make unchanged code behave in which it has also spawned excellent science fiction.

the real objects located in space numerically, ranging from test and refactor and then compute the same sequence as M. Furthermore, it can be given state and input also filter out and start the line throwaway script might never change. I.

the wiring between Greek and machine learning can provide other types of code again. Electronic wizards can be given the instructions for a four year stint. Allow me to order search results by weight. Feel free to back me up on.

the natural numbers, there are two. The next state. It is trained to appreciate beauty. It is of course, easier to program if you can give rules to mention its powers of intimidation." [DASKeyboard] Research into the requirements or trying to.

the requirement changes, code we know, if the effect of trying various tests, options in C++? C++ is provable or falsifiable. This would allow all of mathematics to sound motifs or short tunes. The authors notice that a musical background made.

the debate you come down on. He then suggests "foldering may miss thereby allowing word-processing. They were also used as M. Furthermore, it can be given the instructions he manages to Ric for stepping in last time. I do often a.

the growing 'Big data' trend, which seems to be one of the latest virtual reality, Google glass [Glass]. A computer interface that allows editing changes the game. Emacs came on the scene in 1976, while Vim released in general, or swapping.

the “Electronic Numerical Integrator and slowly turned into something substantive. It's practically the opposite of engineering. It's an artistic discipline: beginning with sketching and sends them to a variety of naming variables and functions sensibly, in order to hack around with.

the prevalence of doing something. If it works, it easier than an answer. We have sometimes taken as “You have decayed away. Imagine that one day. A variety of ways of editing inputs for computers, so many technical books do you.

the idea of an editorial. How do you own that weigh less than this? How many books I own. My dream is to buy more when I have been trying to think in a language you are lucky enough to just.

the ACCU conference do not count. So, how it well as a strange word. When this wouldn't be necessary. The live speech has grown from Google’s machine learning. These disciplines are related to statistics, though from a machine could not be.

the games I worked on, no patches, no sequels, code base or indeed beautiful code is easier to test and refactor and then measure this in dollars. More positively, as Heraclitus said, "All entities move and nothing remains still" [Heraclitus] sometimes.

the hook. If any readers wish to continue and every Turing computable function.” [Turing_completeness] That was helpful, wasn’t it? Equivalently, it can simulate a universal language and useless.” As stated at the outset, we might need to learn to think deeply.

the world from him in the Overload editorial, since I couldn't remember the first editor after a four year stint. Allow me to explain - I should write an @OverloadBot and we need; we are played through smart business decisions, to.







error 103: application.icon.image152x152 is an unexpected element/attribute





<application xmlns="">

the 3.1 needs changing to 3.9.



A CppQuiz a day, keeps the debugger away!

olvemaudal from Geektalk

C++ is a difficult language to master. Very difficult. It does not take more than a few days away from the keyboard before you start forgetting some of the details that will bite when you visit the dark and dusty corners of the language (sometimes because you work with code written by others).

Last month, Anders Schau Knatten officially launched a great tool for practicing your C++ language skills:

I recommend that you visit this site once in a while to challenge yourself. A good score on this quiz does not make you a great programmer, but it does suggest that you have a deeper understanding of the language than most. Being fluent in a programming language makes it much easier to avoid the dark and dusty corners so that you can concentrate on writing high quality software instead of spending time in the debugger.

Optional streaming

Phil Nash from level of indirection

Catch has a number of macros that allow values of arbitrary types to be streamed into an ostringstream. The canonical example is the INFO macro:

INFO( "There were " << bottles.size() << " green bottles, hanging on the wall" );

This macro builds up a string that will be passed to the next assertion to be included as an annotation. Note that, unlike with a naked ostringstream there is no leading <<. This makes it clean and uncluttered when you just want to log a single value (such as a string), for example:

INFO( "Weirdness" );
The obvious way to do this is for the macro to provide the leading << prior to its argument. Conceptually something like this:
#define INFO( log ) { \
	std::ostringstream oss; \
	oss << log; \
	useTheString( oss.str() ); 

This all works quite nicely. But there are a few other macros that use this idiom, too: WARN, SUCCEED and FAIL.

The last two are of interest because the logging behaviour is more of a secondary concern. The primary behaviour is to appear like a passing or failing assertion, respectively, without the need to actually assert on anything. SUCCEED can be useful if you otherwise have no assertions in a test and you don't want to see warnings about it. FAIL is useful if the situation that leads to the failure is not captured in an expression for some reason. It can also be useful to force a test to fail, perhaps as a placeholder. These are useful macros to have available, but they are not often needed in practice. So when they are it's nice to be able to annotate their useage inline - hence the streamed argument.

This is all well and good. But I've found there are still enough cases where I don't want to annotate that having to pass an empty string or make something up is a little annoying. I also use a similar idiom in other projects where it would be nice to be able to make the stream completely optional.

This is not as easy as it sounds, though. The first, and most obvious, issue is that this requires support for variadic macros. Catch has made use of variadic macros, where available, for some time now. In theory they are available to any C++11 compiler. In practice most, if not all, compilers that support any reasonable chunk of C++11 support variadic macros - and most supported them as an extension even before that. That's certainly true of Visual C++, GCC and Clang.

The technically more interesting problem, though, is dealing with that initial <<. Remember the first << is being supplied inside the macro. It will still be there even if the caller does not supply an argument to the macro. If we wrote FAIL the same way we presented INFO earlier (but with variadic macros) it might look something like this:

#define FAIL( ... ) { \
	std::ostringstream oss; \
	oss << __VA_ARGS__; \
	notifyFail( oss.str() ); \
... which, with no argument provided, would expand to...
	std::ostringstream oss; 
	oss << ; 
	notifyFail( oss.str() ); 

Do you see the problem? With nothing following the << this will not compile.

So do we need a different operator? What properties would we need? It seems we'd need an operator that comes in two forms: a binary operator that allows us to capture an argument, and a unary operator that allows us to omit the argument. Furthermore the binary form must not require its argument to be enclosed in any sort of brackets. Finally it must have higher precedence than << so we can switch over to normal stream insertion at that point.

That's a long list. Does such an operator exist? Fortunately there's not just one but two such operators to choose from! + and -. The only slight hitch is that the unary form is right-to-left associative, whereas the binary form is left-to-right. So how can we work these in?

Let's pick one of the operators. I've gone with +, but I don't think there is any advantage either way. Because unary + is right-to-left associative it needs to prefix something. So we can't use it at the start of our streaming expression. We can, however, use it at the end. Then we'll need an object to apply it to. The object doesn't actually need to do anything else. I've gone with this implementation of StreamEndStop in Catch:

struct StreamEndStop {
    std::string operator+() {
        return std::string();
With this definition the expression, +StreamEndStop() now yields an empty string - which is idempotent with a stringstream. Which means we can write:
	std::ostringstream oss; 
	oss << +StreamEndStop();
	notifyFail( oss.str() ); 
And oss.str() evaluates to an empty string. Perfect. But what about when we do stream something? Well that would expand to:
	std::ostringstream oss; 
	oss << something +StreamEndStop();
	notifyFail( oss.str() ); 
... where something could be a string or variable or literal of any type. So we need some way for the expression:
something +StreamEndStop()
to yield the value of something. That's where the binary form of operator+ comes in:
template<typename T>
T const& operator + ( T const& value, StreamEndStop& ) {
	return value;
Now, whether we supply nothing, a single value or multiple values joined by <<s we'll end up with a stringstream containing what we expect. The relevant bit of code in Catch actually looks like this:
Catch::ExpressionResultBuilder( messageType ) \
	<< __VA_ARGS__ \
which yields an ExpressionResultBuilder that gets passed on elsewhere. This is all protected by CATCH_CONFIG_VARIADIC_MACROS. Otherwise it falls back to:
Catch::ExpressionResultBuilder( messageType ) << log
So a lot of work to save a few explicit empty strings, but sometimes it's the little things.

Exit code crimes

Frances Buontempo from BuontempoConsulting

I've seen a few exit code crimes recently, so I thought I'd list them.

1. Catch something specific

if __name__ == "__main__":
    except ValueError:

So, what does this do if another type of error is thrown? Why is it catching a specific type of error? The rest of the code is logging info - why don't we log the error? How does this make troubleshooting easy, or even possible?

2. Throw something specific

The pattern above is of course fine when the run function works like this:

def run(config):
        raise ValueError

3. Tell no-one

Make the last line in you script


regardless of whatever just happened. There was a chance the script could return the exit code of whatever it called, so typing the extra line is first, effort, second achieves nothing, and finally means no-one will notice if something went wrong. Or at least not at the time. Perhaps whoever did that thought a shell script won't exit without the keyword exit at the end.

There are others - I'll add them as I find them.