Joshua Burkholder

Forum	Thread	Replies	Latest activity
Tech Off	C++0x (vs2010) question, please tell me what i'm doing wrong	33	Feb 22, 2011 at 4:53 PM

Variadic Templates are Funadic
Feb 09, 2012 at 4:01 PM
@zbigg:
That pack expansion occurs when it is an argument of another function that you are calling (see Slide 8/34 where the pack expansion of Ts and vs occurs on std::forward when calling the gun function).
Here's another example:
```
#include <iostream>

template < typename TYPE >
inline TYPE g ( TYPE value ) {
    return value;
}

inline void f () {
    //
}

template < typename HEAD_TYPE, typename ... TAIL_TYPE_PACK >
inline void f ( HEAD_TYPE head_value, TAIL_TYPE_PACK ... tail_value_pack ) {
    std::cout << head_value << '\n';
    f( g( tail_value_pack ) ... );
}

int main () {
     f( 1.0, "2", 3, "four" );
    return 0;
}
```
The code (I believe) you are interested in is the line ...
```
f( g( tail_value_pack ) ... );
```
... in the templated f function. The first time through the templated f function, you could think of the tail_value_pack as being { "2", 3, "four" } and the f( g( tail_value_pack ) ... ) call as expanding to
```
f( g( "2" ), g( 3 ), g( "four" ) );
```
. Similarly for the recursive-looking overloaded calls to the templated f function. Once the tail_value_pack is empty, then you could think of the tail_value_pack as being { } and the f( g( tail_value_pack ) ... ) call as expanding to
```
f(  );
```
... hence, the empty regular f function before the templated f function in the code above.
Using MinGW's g++ version 4.6.2, you can compile and run this using:
```
g++ -o main.exe -std=c++0x -march=native -O3 -Wall -Wextra -Werror main.cpp && ./main.exe
```
The following is the output of the code above:
```
1
2
3
four
```
I believe this is covered in section 14.5.3 point 5 ... it seems to be listed in the exampe as:
```
f(const_cast<const Args*>(&args)...); // OK: “Args” and “args” are expanded
```
. I don't have the ISO standard, but this was page 346 of N3291 (released April 5th of 2011).
Hope This Helps,
Joshua Burkholder
Rob Relyea: Kinect for Windows SDK Beta 2 Released!
Nov 06, 2011 at 1:18 PM

Does the SDK provide functions/classes that automatically align/register the RGB camera images and the depth camera images?
In other words, if I'm indexing a pixel on someone's face in the RGB image, can I easily get the associated depth measurement? Or do I have to do all that alignment/registration between the RGB and depth images myself?
Similarly, if I'm in the depth image at some (row,column,depth) coordinate and I want to get the RGB value that should be at that coordinate, does the SDK return the correct RGB value? Or does it just give me whatever the RGB value is (however incorrect) at the (row,column) coordinate such that I would still have to do all that offset/interpolation coding between the RGB and depth images myself to come up with the correct RGB value?
Rock Hard: C++ Evolving
May 16, 2011 at 7:05 PM
@Boris: In order to show more C++0x features without comprimising non-disclosure agreements on future versions of Visual C++, you can use g++ with the flag: -std=c++0x.
Even though g++ is popular on Unix-based systems like Linux, there is also a popular open source port of g++ for Windows: MinGW. MinGW can be found here:
http://sourceforge.net/projects/mingw/
and here:
http://www.mingw.org/
As Ron noted, here is the current state of C++0x development for g++:
http://gcc.gnu.org/projects/cxx0x.html
Although g++ is well behind Visual C++ 2010 in C++0x standard library development (for instance, g++ has not fully implemented std::regex ... currently, there are only stubs), g++ does have many C++0x core language features implemented ... and even some that Visual C++ 2010 does not.
So if MinGW is installed on Windows and we have a main.cpp, then we can just execute the following command line to compile main.cpp into main.exe:
```
g++ -o main.exe -std=c++0x -march=native -O3 -Wall -Wextra main.cpp
```
and then execute main.exe to run on the local machine.
Since MinGW currently ports g++ version 4.5.2 ... which implements C++0x raw strings, then main.cpp could contain the following code:
```
#include <iostream>

using namespace std;

int main () {
    cout << R"("C:\Program Files\")" << endl;
    return 0;
}
```
This code doesn't currently compile in Visual C++ 2010 (because C++0x raw strings aren't yet implemented); however, g++ 4.5.2 has no issues ... so if we execute the following on the command lines:
```
g++ -o main.exe -std=c++0x -march=native -O3 -Wall -Wextra main.cpp
./main.exe
```
Then main.exe will compile and run ... producing the following output:
```
"C:\Program Files\"
```
Very Respectfully,
Joshua Burkholder
Rock Hard: C++ Evolving
May 03, 2011 at 11:19 PM

@Boris: I don't know about Ron, but I want more coverage of std::thread (§ 30 from the draft standard): common scenarios and code walkthroughs for futures, code walkthroughs of mutual exclusions and conditional variables, thread local storage, (esp.) the strengths and limitations of the thread model chosen, and std::thread's interaction with other standard libraries (like std::atomic [from § 29], the standard containers [from § 23], the standard iterators [from § 24], and the standard algorithms [from § 25] ... if there is any interaction).
Secondly, from § 8.5.4, I would also like to see more coverage of std::initializer_list and how these initializer lists can be manipulated at compile-time (if at all) ... the same way type_traits manipulates items at compile-time (i.e. template meta-programming). I would like to enter in easy-to-type info into an initializer list, have a manipulation/optimization of that info happen at compile-time (instead of at run-time in the constructor), and then let the constructor create the object at run-time using this manipulated/optimized info.
Lastly, from § 2.14.5, I would like to see coverage of raw strings (that whole R"..." thing) and how the delimiters and parentheses work. Raw strings seem like C# @"..." string ... but with extra stuff ... so I'm wondering what the extra use-cases are. I'm also wondering if raw strings enable any special use cases with std::regex (from § 28).

Joshua Burkholder
C9 Lectures: Stephan T Lavavej - Advanced STL, 2 of n
Mar 11, 2011 at 7:00 PM

@Mr Crash:Unfortunately, the "Eclipse IDE for C/C++ Developers" does require the JRE 1.5 or higher to run. There is a way to "install" the JRE without actually installing the JRE (i.e. no Windows registry and no admin rights) - place the bin folder of that unzipped JRE temporarily in the PATH and execute Eclipse with that temporarily revised path ... but that requires a little more leg work. It's easier to just install Java.
I have never had a problem with Java on Windows. The JRE and JDK on Windows have always played nicely for me ... and never interfered with anything. I'm not a fan of Java ... I only develop using it when forced by requirements ... and I would always choose C# (on .NET/Mono) over Java (on JRE) for managed work, but Java has always worked for me ... so no M$ conspiracy theories here.
If you really, really want to use Visual Studio, you could always extend Visual Studio by wrapping it around gcc/g++ yourself (like they did for IronPython Studio: http://ironpythonstudio.codeplex.com/ ). Here's Microsoft's "Extending Visual Studio" page:
http://msdn.microsoft.com/en-us/vstudio/ff718165.aspx
Lastly, some of my friends like Bloodshed's Dev-C++ ... although I have never tried it myself. It doesn't require Java. Here's the site:
http://www.bloodshed.net/devcpp.html
Hope This Helps,
Joshua Burkholder
C9 Lectures: Stephan T Lavavej - Advanced STL, 2 of n
Mar 11, 2011 at 4:20 PM

@Mr Crash:For an IDE that wraps gcc & g++, use the "Eclipse IDE for C/C++ Developers":
http://www.eclipse.org/downloads
I've used the Eclipse IDE for C/C++ Developers on Windows to wrap MinGW's version of gcc & g++ (i.e. gcc & g++ on Windows: http://sourceforge.net/projects/mingw/ ) ... and it works very well ... and is easy to understand ... and has lots of colors. The default is not C++0x, so you'll need to add "-std=c++0x" by editing the properties of your C++ project in C/C++ Build / Settings / Tool Settings tab / GCC C++ Compiler / Miscellaneous / Other flags text field. You'll need to add that to the Debug and Release configurations. For the Release configuration, you also might want to add "-march=native" (or whatever architecture you're writing for) to the same text field; otherwise, the default instruction set that gets used is a little old.
There is probably an easy way to make that "-std=c++0x" addition the default for all future projects, but I haven't had to worry about that yet.
Hope This Helps,
Joshua Burkholder
C9 Lectures: Stephan T Lavavej - Advanced STL, 2 of n
Mar 06, 2011 at 9:19 PM
@STL: Outstanding video!
Suggestion: Sometimes it helps to look at the Release-mode assembly output (i.e. assembly output after optimizations) to convince a programmer that template meta-programming is actually doing something useful. I know that this has helped me. Using /FAs (or [in the IDE] selecting "Assembly With Source Code (/FAs)" from the "Assembler Output" drop-down box in Configuration Properties \ C/C++ \ Output Files from a project's Property page), allows a programmer to see the fruits of their template-meta-programming labor.
If certain instructions in the assembly output are unfamiliar (like they are for me), then looking at the instruction set reference in combination with the assembly output can also be helpful:
http://www.intel.com/products/processor/manuals/
Specifically, these pdfs:
http://www.intel.com/Assets/PDF/manual/253666.pdf
http://www.intel.com/Assets/PDF/manual/253667.pdf
Hope This Helps,
Joshua Burkholder
P.S. - For g++ to output assembly, the following command line can be used (assuming a file named main.cpp):
```
g++ -S -fverbose-asm main.cpp -std=c++0x -march=native -O3 -Wall -Wextra -Werror
```
C9 Lectures: Stephan T Lavavej - Advanced STL, 1 of n
Feb 26, 2011 at 11:03 PM
@STL:Well, I have to say that I'm really learning a lot about C++0x through this discussion. Hopefully, you're getting something out of this as well ... so that I'm not just irritating you.
> Where in the proposed C++0x standard does it state that function parameter adjustment does not affect explicit template parameters?
Function parameters and template parameters are totally different, so function parameter adjustment can't affect template parameters. The Standard/Working Paper doesn't need to explicitly say this, even in a footnote.
Sorry about that. I didn't mean to confuse you. I should have written "explicit template __arguments__", vice "parameters". Since we were previously writing about the interaction between explicit template arguments for templated functions ( the A in "f<A>( a )" where f is "template<T>void f( T t )" ) and what the function parameters eventually get adjusted into ( where f<A> is adjusted to type "void ( adjusted(A) )" ), I figured that you would understand what I was writing about ... even though I slacked on the terminology. All apologies.
> If so, where can I look this up?
N3225 5.3.3 [expr.sizeof]/1: "The sizeof operator yields the number of bytes in the object representation of its operand. The operand is either an expression, which is an unevaluated operand (Clause 5), or a parenthesized type-id."
When 8.3.5 [dcl.fct]/5 says "After determining the type of each parameter, any parameter of type “array of T” or “function returning T” is adjusted to be “pointer to T” or “pointer to function returning T,” respectively." it's talking about function parameters.
Because the function parameter has been adjusted to be a pointer, sizeof(t) is 4. t behaves as a pointer in every other respect (e.g. when being passed to other templates).
The template parameter is unaffected - it is still an array type. sizeof(T) therefore returns how many bytes would be in such an array, which is 20.
Thanks! I completely forgot about that in C++98/03!!!
I think that I'm starting to get a clearer picture of what is going wrong here ... and what is going right. In order to clarify things even more, I'm trying to test something out using decltype() ... but VC++ 2010 is not cooperating. If I have the following function template and regular function:
```
template < typename T >
void f ( T t ) {
    (void) t;
}

void g ( char s[20] ) {
    (void) s;
}
```
g++ 4.5.2 compiles the following decltype of the instantiated function template just fine, but I cannot get VC++ 2010 to compile the same code (I get the following error in VC++: error C3556: 'f': incorrect argument to 'decltype'):
```
decltype( f<char[20]> )
```
Note: I can put regular functions in decltype in VC++ 2010 with no issues. In other words, I __can__ compile the following in VC++ 2010:
```
decltype( g )
```
Is decltype fully baked in VC++ 2010? Or are there known limitations?
Joshua Burkholder
P.S. - I would love more info and examples of that static_cast< function pointer >( function template name ) thing that you were writing about.
C9 Lectures: Stephan T Lavavej - Advanced STL, 1 of n
Feb 26, 2011 at 12:21 PM
Function parameter adjustment does not affect template parameters.
Where in the proposed C++0x standard does it state that function parameter adjustment does not affect explicit template parameters? My interpretation of 14.8.2.3 (PDF page 383) and the explicit template arguments in it's example seems to suggest that it does (esp. #2, where f<const int> implies that T and decltype( t ) are both const int, but the signature of the explicit f<const int> is adjusted to void(*)(int) ). In other words, T agrees with decltype( t ) in spite of adjustment ... but my interpretation could be wrong.
In particular, this behavior (sizeof(T) is 20, sizeof(t) is 4) is shared by VC and GCC, and mandated by C++98/03.
I don't have a copy of the C++98/03 standard handy. Is this still in the proposed C++0x standard? If so, where can I look this up? I did a quick search of "sizeof" in the PDF and I didn't see anything applicable to this situation ... but I might have read right over it.
> Using implicit or explicit template arguments should produce exactly the same results
It mostly does, when you're careful to specify exactly the same template argument that automatic deduction would have chosen for you - but then, why bother? And if you specify something different, now you're forcing the template into an unusual mode of operation.
In order to pass functions around, function types must be known at compile-time. If you have a templated function, then we have to explicitly instaniate the function template in order to pass it around. Contrived Example:
```
#include <iostream>

using namespace std;

template < typename F, typename P >
class delayed_call_t {
    private:
        F m_f;
        P m_p;
    public:
        delayed_call_t ( F f, P p ) : m_f( f ), m_p( p ) {}
        void call () { m_f( m_p ); }
};

template < typename F, typename P >
delayed_call_t< F, P > make_delayed_call ( F f, P p ) {
    return delayed_call_t< F, P >( f, p );
}

template < typename T >
void f ( T t ) {
    cout << "t:                       " << t << '\n';
    cout << "sizeof( T ):             " << sizeof( T )             << '\n';
    cout << "sizeof( t ):             " << sizeof( t )             << '\n';
    cout << "sizeof( decltype( t ) ): " << sizeof( decltype( t ) ) << '\n';
}

int main () {
    char s[] = "Hello, World!";
    auto delayed = make_delayed_call( f< decltype( s ) >, s );
    delayed.call();
    return 0;
}
```
Joshua Burkholder

C9 Lectures: Stephan T Lavavej - Advanced STL, 1 of n

Feb 25, 2011 at 1:31 PM

@STL:Wow ... time to submit a bug report on g++! Or have you already done so?

I hear what you are saying about C++ staying consistent with C via adjustment ... which is why void ( char[123] ) is the same as void ( char * ) ... and void (*) ( char[123] ) is the same as void (*) ( char * ); however, VC++ seems to be just as inconsistent as g++ ... only in a slightly different way. Here's the inconsistency (switching to character arrays ... because sizeof( void () ) is not allowed by the standard):

#include <iostream>
#include <type_traits>

using namespace std;

template < typename T >
void check_size_of ( T t ) {
    (void) t;// to suppress unreferenced formal parameter warnings: 
    cout << "    sizeof( T ):             " << sizeof( T )             << endl;
    cout << "    sizeof( t ):             " << sizeof( t )             << endl;
    cout << "    sizeof( decltype( t ) ): " << sizeof( decltype( t ) ) << endl;
}

int main () {

    cout << "template < typename T >" << endl;
    cout << "void check_size_of ( T t );" << endl;
    cout << endl;

    char a[] = "My type is char[20]";

    cout << "char a[] = \"" << a << "\";" << endl;
    cout << "Is decltype( a ) char[20]? " << is_same< decltype( a ), char[20] >::value << endl;
    cout << "Is decltype( a ) char *?   " << is_same< decltype( a ), char* >::value << endl;
    cout << endl;

    cout << "check_size_of( a ):" << endl;
    check_size_of( a );
    cout << endl;

    cout << "========================================================" << endl;
    cout << "***** Inconsistent on both VC++ 2010 and g++ 4.5.2 *****" << endl;
    cout << "========================================================" << endl;
    cout << "check_size_of< decltype( a ) >( a ):" << endl;
    check_size_of< decltype( a ) >( a );
    cout << "========================================================" << endl;
    cout << endl;
    
    cout << "check_size_of< decltype( a ) & >( a ):" << endl;
    check_size_of< decltype( a ) & >( a );
    cout << endl;
    
    return 0;
}

VC++ 2010 gives the following output:

template < typename T >
void check_size_of ( T t );

char a[] = "My type is char[20]";
Is decltype( a ) char[20]? 1
Is decltype( a ) char *?   0

check_size_of( a ):
    sizeof( T ):             4
    sizeof( t ):             4
    sizeof( decltype( t ) ): 4

========================================================
***** Inconsistent on both VC++ 2010 and g++ 4.5.2 *****
========================================================
check_size_of< decltype( a ) >( a ):
    sizeof( T ):             20
    sizeof( t ):             4
    sizeof( decltype( t ) ): 4
========================================================

check_size_of< decltype( a ) & >( a ):
    sizeof( T ):             20
    sizeof( t ):             20
    sizeof( decltype( t ) ): 20

g++ 4.5.2 gives the following output:

template < typename T >
void check_size_of ( T t );

char a[] = "My type is char[20]";
Is decltype( a ) char[20]? 1
Is decltype( a ) char *?   0

check_size_of( a ):
    sizeof( T ):             4
    sizeof( t ):             4
    sizeof( decltype( t ) ): 4

========================================================
***** Inconsistent on both VC++ 2010 and g++ 4.5.2 *****
========================================================
check_size_of< decltype( a ) >( a ):
    sizeof( T ):             20
    sizeof( t ):             4
    sizeof( decltype( t ) ): 20
========================================================

check_size_of< decltype( a ) & >( a ):
    sizeof( T ):             20
    sizeof( t ):             20
    sizeof( decltype( t ) ): 20

If the currently proposed standard allows either one of these inconsistencies, then maybe some compiler warnings should happen ... or just fix the proposed standard before it is finalized. Big Smile

Lastly, you wrote:
"Indeed, providing explicit template arguments when you shouldn't is a subtle way to misuse C++"

I'm gonna go with "what?" on this one. Wink Using implicit or explicit template arguments should produce exactly the same results ... because that would make the most sense (i.e. the whole "intuitive" thing). Don't you agree?

Joshua Burkholder

See more comments…

Staff