Ruminationshttp://blog.aaronballman.com
Mulling over topics I find interestingSun, 30 Nov 2014 15:59:58 +0000en-UShourly1https://wordpress.org/?v=5.0.3Member Function Ref Qualifiershttp://blog.aaronballman.com/2014/07/member-function-ref-qualifiers/
http://blog.aaronballman.com/2014/07/member-function-ref-qualifiers/#commentsTue, 08 Jul 2014 14:05:02 +0000http://blog.aaronballman.com/?p=686Continue reading →]]>One of the lesser-known features of C++11 is the fact that you can overload your non-static member functions based on whether the implicit this object parameter is an lvalue reference or an rvalue reference by specifying a functions ref-qualifier. This feature works similar to the way cv-qualifiers work when specifying a method must be called on a const or volatile object, and can in fact be combined with cv-qualifiers.
To specify a ref-qualifier for a member function, you can either qualify the function with & or &&. (The ref-qualifier must come after any cv-qualifiers.) For instance, if you wanted to declare a function to be called on an rvalue reference object only, you would write:

When executed, this code will output: Copy Move Move Move. The Copy is because b is an lvalue, not an rvalue, and so operator()() & will be called. However, the results of that function are an rvalue, and so the subsequent subexpressions will result in calling operator()() &&. Due to this, resources can be stolen from one invocation to the next on the last three subexpressions, reducing the performance penalties of a copy operation.

In case you are wondering why the std::move(*this) is used when constructing a Builder object; the unary expression *this always results in an lvalue, which would end up calling the copy constructor instead of the move constructor. So the std::move call is required to convert the lvalue into an rvalue.

Ref-qualifiers are not something you will likely use often. However, it is never a bad thing to understand the tools the programming language has to offer. Note: ref-qualifiers are currently supported by clang (tested with 3.4), gcc (tested with 4.9) but not MSVC 2013.

]]>http://blog.aaronballman.com/2014/07/member-function-ref-qualifiers/feed/1Binary Operator Overloadinghttp://blog.aaronballman.com/2014/06/binary-operator-overloading/
http://blog.aaronballman.com/2014/06/binary-operator-overloading/#commentsMon, 23 Jun 2014 14:38:32 +0000http://blog.aaronballman.com/?p=678Continue reading →]]>In C++, there are two forms of binary operator overloading you can use when designing an API. The first form is to overload the operator as a member function of the class, and the second form is to overload the operator as a friend function of the class. I want to explore why you would use one form of overloading instead of the other, using a Fraction class as an example.
For the purposes of this discussion, this is part of the interface for our expository class.

One of the ways we can implement our binary operator overloads is as member functions of the Fraction class. I’m going to pick on the equality operator, but any of the overloaded binary operators would suffice.

Since there are two different ways to implement this, it’s reasonable to ask which way is “correct?” The answer to that question depends on your intentions as a class designer. Consider the following use case:

Some coding conventions suggest that equality comparisons against a constant value put the constant on the left-hand side of the comparison (so that an accidental assignment operation by typing = instead of == would trigger a compile error), so this example is not particularly far-fetched.

If you use a member function for the operator overload, this code would not compile because there’s no way for the implicit converting constructor from double to Fraction to be called. However, by using a friend function for the operator overload, the compiler can call the converting constructor to create a Fraction object which would make the comparison viable. Because of this, I would claim that declaring the operators to be friends is the correct approach for the class design.

This exemplifies a reasonable way to decide how to implement the overloaded binary operators. If you want to allow implicit conversions for items on the left-hand side of the operator, then using friend function overloads is required. If implicit conversions are not desirable for some reason, or not possible (due to having no implicit converting constructors), then using a member function is acceptable. If you’re looking for a general rule of thumb, I would recommend always using the friend function form — it’s more likely to behave how the user would expect in all cases, instead of having curious edge cases where their usage fails. Imagine how confusing it would be for the user of a Fraction class that SomeFraction * 1 succeeds, but 1 * SomeFraction fails to compile! That being said, it ultimately boils down to a design choice that you must make as a class designer.

I would like to thank Jens Maurer for the design discussion which spawned this blog posting.

]]>http://blog.aaronballman.com/2014/06/binary-operator-overloading/feed/2Implementing a four-bit adder with C++ template metaprogramminghttp://blog.aaronballman.com/2013/11/implementing-a-four-bit-adder-with-c-template-metaprogramming/
http://blog.aaronballman.com/2013/11/implementing-a-four-bit-adder-with-c-template-metaprogramming/#commentsThu, 14 Nov 2013 18:53:17 +0000http://blog.aaronballman.com/?p=661Continue reading →]]>I recently read a post by Phillip Larkson where the C preprocessor was used to implement a four-bit adder entirely at compile time. This got me wondering whether I could implement the same concept using C++ template metaprogramming. It seemed theoretically possible as all the components can be calculated at runtime, but I wanted to avoid making use of the preprocessor for anything but supplying the original values to be added. The goal was to compile something on the command line like:

clang -DNUMBER_1=5 -DNUMBER_2=7 foo.cpp

and have the value 12 written out to the command line.
It turns out that this is relatively straight-forward to implement in C++. You can encode the bitwise operators AND and XOR with template specializations, and the remainder of the adder is bookkeeping for the sum and carry bits. The bitwise operators and adder themselves look like:

I define a pair of base structures to represent a zero bit and a one bit. The base operator is not specialized, and results in the zero bit. The specializations for the operators return the one bit for the correct operands. The full_addr structure implements the typical sum and carry operations which are described on Wikipedia.

As I mentioned, implementing the four-bit adder is a matter of bookkeeping for the bits, and so I made a helper structures called two_bit_addr and four_bit_addr_inner to do the bookkeeping. The implementation of each is to hook up the full_addr in a serialized fashion. I suspect there’s a way to make a generalized N-bit adder using template parameter packing, but I didn’t give the design enough though to prove it’s possible.

In order to fit the design I wanted, I needed some helpers that would convert a decimal value into a series of binary digits, and binary digits into a decimal value. This way, I could specify decimal values on the command line, convert them into binary values to pass to the adder, and then convert the binary result from the adder back into a decimal value.

The binary conversion uses recursive template definitions to determine each bit of the value. Given a decimal input and a bit index, it returns the bit value at that index.

To convert from binary back to decimal, I used template parameter packing from C++ to represent the bits in the binary number, and the resulting value is a straight binary-to-decimal calculation using recursive template definitions to perform the calculation. This, of course, requires the ability to get power-of-two values for which I used another recursive template definition.

Finally, I could put all of these helpers together to create the four-bit adder structure. It accepts two decimal values which are converted into binary values when passed to the inner four-bit adder helper. The inner helper performs the calculation and returns the bits for the result. These bits are then passed into the binary-to-decimal helper which returns the resulting decimal value. All of this happens within the template system and results in a constant value.

Thanks to Phillip for giving me the idea to do this! The full source code can be downloaded from here, and it’s been tested and works with clang 3.4 (ToT), gcc 4.8.1 and Visual Studio 2013.

]]>http://blog.aaronballman.com/2013/11/implementing-a-four-bit-adder-with-c-template-metaprogramming/feed/1Interesting Note About the sizeof Operatorhttp://blog.aaronballman.com/2013/06/interesting-note-about-the-sizeof-operator/
http://blog.aaronballman.com/2013/06/interesting-note-about-the-sizeof-operator/#commentsFri, 21 Jun 2013 16:03:17 +0000http://blog.aaronballman.com/?p=654Continue reading →]]>The expression used in a sizeof operator is an unevaluated expression in C and C++. This can make for some surprising situations if you are unaware of it. For instance:

This code will print 12 instead of 13 because the expression ++a is unevaluated.

So what does it mean for an expression to be unevaluated? Basically, it means that the expression is used at compile time only as a way to determine a type, which is then used to evaluate the result of the sizeof operator. So in the above example, a’s type is determined, and the resulting type for ++ is determined, but no code is generated to execute the ++.

If you run this code, you will see 8, 1 printed and will not get a link error (because of the failure to define operator++)!

]]>http://blog.aaronballman.com/2013/06/interesting-note-about-the-sizeof-operator/feed/6MSVC Pointer Type Attributeshttp://blog.aaronballman.com/2013/05/msvc-pointer-type-attributes/
http://blog.aaronballman.com/2013/05/msvc-pointer-type-attributes/#commentsWed, 15 May 2013 15:49:37 +0000http://blog.aaronballman.com/?p=639Continue reading →]]>One of the lesser-known features of Visual Studio’s C/C++ compiler are the pointer type attributes __ptr32 and __ptr64. More information about them can be found on MSDN. These pointer type attributes are used to control the visible size and behavior of pointers in 32- and 64-bit applications. Their usage is a bit strange, but if you need to do interop between 32- and 64-bit mode, they can be handy features to have. Additionally, there are the __sptr and __uptr qualifiers which allow you to specify how the pointer types are extended. __sptr denotes sign extension, and __uptr denotes zero extension. Information about these qualifiers can also be found on MSDN.
The behavior of these type attributes is strange, to say the least. I wanted to take a moment to document what I’ve observed the behavior to be, as of Visual Studio 2012.

For starters, the documentation is a bit misleading for __ptr32 and __ptr64. Specifically, the documentation states:

On a 32-bit system, a pointer declared with __ptr64 is truncated to a 32-bit pointer. On a 64-bit system, a pointer declared with __ptr32 is coerced to a 64-bit pointer.

However, this isn’t strictly accurate. When you use a type with a specific pointer size, the returned pointer will be sized accordingly regardless of architecture you are targeting. For instance, if you use __ptr64 on an x86 build, you will get a 64-bit pointer value. If you pass it to functions, use it in structures, call sizeof on it, etc, it will occupy 8 bytes of space, even though you are on a 32-bit system. However, when you dereference the pointer, it will only use the low 32-bits of the pointer. For instance:

So while you are asking for a 64-bit pointer, and actually receive a 64-bit value in response, you really can only use 32-bits of it which is what the MSDN documentation is alluding to.

Considering that __ptr32 and __ptr64 yield types of different sizes, you might expect the types to differ such that you can overload on them. For instance, you can overload based on long and long long types. Additionally, if you view them as qualifiers (like const or volatile), you can also overload. So what about __ptr32 and __ptr64? It turns out that the compiler treats these qualifiers as sugar instead of as part of the canonical type, so you cannot overload based on them.

As if this isn’t confusing enough, the name mangler implies the types are different!

void f( int * __ptr64 i ) {}
void f2( int * __ptr32 i ) {}

PUBLIC ?f@@YAXPEAH@Z ; f
PUBLIC ?f2@@YAXPAH@Z ; f2

So as far as the name mangler is concerned, they are different types!

__sptr and __uptr fit into the equation as pointer type qualifiers that affect how pointers are extended. If you specify __sptr, the pointer will be sign extended. If you specify __uptr, it will be zero extended. Modifying our x86 example slightly:

We’ve added the __uptr qualifier to the variable p in main. This means that when p is converted to a 64-bit pointer as an argument to func, it will be zero extended instead of sign extended. Looking at the disassembly shows this to be true:

The semantics for __sptr and __uptr are a bit more consistent than __ptr32 and __ptr64 as they don’t affect warning semantics, overload semantics, or the name mangler. However, that leaves them with their own peculiar quirks.

int * __sptr p1 = 0;
int * __uptr p2 = p1;

This code will compile without warning, because as far as the compiler is concerned, __sptr and __uptr only affect code generation, and not semantics. Additionally, template specialization treats them as equivalent, so when a template is instantiated, it gets whatever pointer qualifiers are on the first instantiation. For instance)

If you run this code, you will see the first two pointers being sign extended, and the last one being zero extended. This happens because the template instantiation is pulling in the __sptr from the first call, not generating a new instantiation for the second call, but doing so for the third call.

All this being said, __ptr32, __ptr64, __sptr and __uptr aren’t things you are likely to ever use unless you happen to be doing some highly specific work. But hopefully this sheds a bit of light on the weird behavior of these quirky features!

]]>http://blog.aaronballman.com/2013/05/msvc-pointer-type-attributes/feed/2Small Break in the Silencehttp://blog.aaronballman.com/2012/08/small-break-in-the-silence/
http://blog.aaronballman.com/2012/08/small-break-in-the-silence/#respondTue, 14 Aug 2012 13:05:39 +0000http://blog.aaronballman.com/?p=574Continue reading →]]>Just because I’ve not written many posts lately doesn’t mean I’ve been silent. You should go check out the Tidbits page, it currently has over 20 little juicy pieces of information about C and C++. I’ve been using it as a training exercise for my coworkers, and it’s been very successful so far. I’ll likely be continuing with regular Friday updates of Tidbits for quite a while to come.

I do hope to write some more full-length blog posts now that life is starting to settle back down again. So I’m not dormant, honest!

]]>http://blog.aaronballman.com/2012/08/small-break-in-the-silence/feed/0How Variable Argument Lists Work in Chttp://blog.aaronballman.com/2012/06/how-variable-argument-lists-work-in-c/
http://blog.aaronballman.com/2012/06/how-variable-argument-lists-work-in-c/#commentsWed, 20 Jun 2012 20:24:25 +0000http://blog.aaronballman.com/?p=558Continue reading →]]>Variable argument lists are very arcane in the world of C. You’ll see them expressed in function signatures as … at the end of the parameter list, but you may not understand how they work or what they do.
There are two sides to every function at runtime: the caller and the callee, and they both need to agree on the semantics of how the function call works (how do parameters get passed, return values returned, etc). The caller’s side is pretty easy with variable arguments because the compiler will continue to pass parameters like it normally would, right up until the terminating parenthesis. For the caller, it’s no different than any other function call except for the fact that the compiler will allow any number of arguments (including zero) after the initial parameters. They all get pushed onto the stack (depending on architecture and calling conventions) in the proper order, and the callee is responsible for figuring them out.

The callee side, on the other hand, is quite interesting. Let’s take a look at a typical function:

The way it works on the callee side is that you must use the “va” functions: va_start, va_arg and va_end as a way to query for the parameter list. The first thing you’ll notice is the only way to call va_start is by passing in the last parameter in the list (the parameter preceding the …). This is because the only way for variable argument lists to work is for the callee to know where the function parameters live, and you can only do that if you have at least one formal parameter. Because va_start needs the exact location of the parameter, it is a macro instead of a function — this allows it to get at the address of the parameter on the correct stack. Once you’ve gotten the start of the va_list, you get each individual argument by using the va_arg macro. This macro takes the list as well as a type, translates into the actual argument value, and advances the list to the next parameter. va_end is called when completed to clean up. There’s no compiler magic required for this implementation, everything can be done with vanilla C functionality.

This has some interesting ramifications. For instance, you must know where to stop looking for arguments or else you will walk off the end of the argument list. Also, this means that the function taking a variable argument list must be declared as __cdecl because the caller is the only one who knows how to properly clean up the call stack (the callee doesn’t know how many parameter were passed to it, remember?). Finally, in order to walk the list, you must know exactly what types are expected in what order. If you don’t, then when va_arg attempts to read in a parameter, it may give you garbage by reading too much or too little memory. And when it advances to the next argument, it may do the same because the previous argument’s size information was wrong.

To better understand what I am talking about, this is a hint as to how these macros might be implemented on x86:

They may look dense, but they’re rather simplistic in their implementation. The va_list is nothing more than a byte pointer. va_start assigns the address of the first parameter *after* the one passed in. va_arg advances the byte pointer by the parameter size and stores it, then backs up a bit to grab the actual value.

So variable argument lists aren’t as powerful or easy to use as they are in other languages like C# or Python. They basically are at the mercy of the programmer. But now you probably understand why you have to put all the type information into a printf format specification, or why you need to specify sentinel values to terminate lists.

]]>http://blog.aaronballman.com/2012/06/how-variable-argument-lists-work-in-c/feed/11Source Indexing SVN Repositories is Brokenhttp://blog.aaronballman.com/2012/05/source-indexing-svn-repositories-is-broken/
http://blog.aaronballman.com/2012/05/source-indexing-svn-repositories-is-broken/#commentsTue, 08 May 2012 17:30:19 +0000http://blog.aaronballman.com/?p=543Continue reading →]]>Some of us spend a fair amount of time pouring through crash dumps generated on Windows. For us, the symbol server support provided by Microsoft’s debugging engines is a godsend. However, source indexing is an even bigger boon because it allows us to not only see the symbols within the crash, but be able to pull the exact source down for source-level debugging.

Unfortunately, it seems that SVN 1.7 broke this functionality! Since it is so critical to my daily workflow, I set about fixing it.
The way source indexing works is that Microsoft collected a bunch of perl scripts to process the text from various version control systems, and then provided a common interface for them to push this information to an alternate stream within the PDB file. The debugger then pulls this information from the alternate stream and can use it to fetch the exact file.

For SVN, the perl script executes svn info -R on the source base to find the file path and revision information, and this is matched up against the output from srctool.exe -r for the PDBs found. For example:

The important piece to notice is that Path no longer returns an absolute path, but instead returns a path relative to Working Copy Root Path (which didn’t previously exist). This is what causes source indexing to break for SVN.

I’m no Perl expert, but I did manage to create a version of the svn source indexing module that handles both the 1.6 and 1.7 formats for svn info. Basically, I’m assuming that Path is correct right up until I find a Working Copy Root Path, at which point I assume Path is a relative path and fix it up. This seems to fix the cases I’ve run into, but I have not run it on a huge sample of code bases. You can find the fixed file here. This file should replace svn.pm in the srcsrv directory of your WinDbg installation folder.

Hopefully this fixes any source indexing problems you’ve run into with SVN 1.7! I’ve filed a report with Microsoft, so if this issue affects you, please up-vote it on Connect.

]]>http://blog.aaronballman.com/2012/05/source-indexing-svn-repositories-is-broken/feed/1Value Types in C++11http://blog.aaronballman.com/2012/03/value-types-in-c11/
http://blog.aaronballman.com/2012/03/value-types-in-c11/#commentsThu, 29 Mar 2012 18:37:01 +0000http://blog.aaronballman.com/?p=530Continue reading →]]>You may have heard these terms used for various programming languages before, but I wanted to discuss them in a bit more detail since they’re a fairly fundamental concept in compilers that spill over into the way you use the languages themselves.
The terms “lvalue” and “rvalue” come from a seminal work by Christopher Strachey called Fundamental Concepts in Programming Languages, which is actually a composition of lecture notes from 1967.

At the core, lvalues and rvalues are quite simple concepts. An L-Value is named because it can appear on the left-hand side of an assignment operation, and an R-Value is named because it can appear on the right-hand side. However, the devil is in the details (so to speak).

More properly, an L-Value is a named value that has a memory location associated with it. For instance, when you declare a local integer variable with the name ‘x’, you are creating something that can be an L-Value. An R-Value is just that: a value. It does not require a memory location to be associated with it, nor does it require a name. For instance, literals are R-Values.

Interestingly, this means that L-values can be R-values. For instance:

int x = 12;
x = x + 100;

In the first statement, x is being declared as an integer. Then it is used as an l-value, to accept the literal number 12 as an r-value. In the second statement, x is used as an l-value, to accept the result of the expression x + 100. However, that expression uses two r-values: the literal 100, and the value of x. So even though x is an l-value, it undergoes an l-value-to-r-value conversion. The result of the expression x + 100 is itself an rvalue, having a value but no firm memory address.

This seems rather cut and dried, but in reality, the rules are more complicated. C++11 makes them even more complex by adding what are called “r-value references.” This change mutates the notion of traditional r-values slightly, causing some definition changes. The taxonomy used for C++11 involves several value types: lvalue, xvalue, prvalue, rvalue, and glvalue.

In this taxonomy, lvalue remains exactly the same. It represents a named item with a concrete memory location associated with it. For instance, functions, local variables, etc. The “named item” part is slightly tricky:

int& foo();

In this example, foo is an l-value, but so is the int& *result* of foo even though it’s not strictly named. But if you think about it more deeply, it really is named, just in an opaque manner. In order for you to return a reference from the function, you must return something that is named. Consequently, this is why it is legal for you to do: foo() = 5; Since the result is an l-value, you are allowed to assign into it.

The prvalue object is identical to what I described for r-values above. It stands for “pure r-value”, and is the traditional concept of r-values. For instance, the result of a function that return l-values (not l-value references) is an r-value. For example:

int foo();

foo is still an l-value, but the result of calling foo is an r-value. This is why you cannot do: foo() = 5;

xvalues are “eXpiring” values that refer to an object near the end of its lifetime, such as functions returning rvalue references. For instance:

int&& foo();

foo is still an l-value, but the result of calling foo is an xvalue. The && syntax is called an “r-value reference”, and it’s a way for you to signal to the compiler that an object can be safely “stolen” using move semantics. For more information on move semantics, see this.

xvalues are interesting in that they can be thought of as both an lvalue and a prvalue, depending on the context. If an xvalue object is named, then it is treated as an lvalue, otherwise it is treated as a prvalue. So in our example, the results of calling foo will be treated as a prvalue, so you cannot do foo() = “12”;. However, if you had an r-value reference parameter, you could use it as an l-value, like this:

void foo( int&& i ) {
i = 12;
}

These three value types (lvalue, xvalue and prvalue) are called the “fundamental” value types, and every expression belongs to exactly one of these types. The remaining two type descriptions are glvalue (a generalized lvalue) and rvalue. A glvalue is either an lvalue or an xvalue, and an rvalue is either a prvalue or xvalue. They are mostly used when requiring generalized statements about what value types are allowed.

So that’s a brief run-down of the various value types in C++11, what they mean and when they’re used. Now for some more in-depth examples. Imagine:

In this case, f defines an l-value of type Foo. Foo::Get and bar are also an l-values due to being a function.

When you call Foo::Get, which Get will be called in each of the statements?

The first statement will call version 2 of Get because of the rvalue temporary required for the assignment operator. The result of that call is an xvalue. Because it is unnamed, it will be treated as a prvalue and assigned into the lvalue named data.

The second statement will call version 1 of Get because there is no rvalue temporary involved. The result of the second statement is an lvalue, which will be converted into a prvalue when being passed into the call to bar. Once inside of bar, the parameter b will be treated as an lvalue again.

Hopefully this gives you a pretty good understanding of the various types of values in C++11 and how they’re used.

tl;dr: lvalues are things which have a concrete memory location for storage and can appear on the left-hand side of an assignment, (p)rvalues are things which have values and can appear on the right-hand side of an assignment.

]]>http://blog.aaronballman.com/2012/03/value-types-in-c11/feed/6Now, With More Tidbits!http://blog.aaronballman.com/2012/03/now-with-more-tidbits/
http://blog.aaronballman.com/2012/03/now-with-more-tidbits/#respondFri, 23 Mar 2012 14:51:33 +0000http://blog.aaronballman.com/?p=528Continue reading →]]>Sorry about the distinct lack of content lately, but I’ve been busy putting together a new training initiative for my day job. This initiative involves sending weekly snippets of information on C and C++ to many of our developers. The content is too small to justify a full blog post in many cases, but is interesting enough to warrant discussion. As a content management system, I have decided to collate these tidbits here on Ruminations. You can find all of them here: http://blog.aaronballman.com/tidbits/. Be sure to check back every Friday, as that’s when I’ll be posting new tidbits. If you have suggestions for tidbits you’d like to see, or want clarification on existing tidbits, feel free to leave comments on the Tidbits post.
]]>http://blog.aaronballman.com/2012/03/now-with-more-tidbits/feed/0