I continuously get this warning whenever a constructor delegates to another constructor within the containing type, having virtual bases.
warning C4100: '$initVBases' : unreferenced formal parameter

It's the same warning as when a parameter or local goes unused, it in this case it seems to be referring to the virtual bases to initialize, but in this case, still makes no sense.

I'm using Visual C++ Compiler 12.0.

2 Years
Discussion Span
Last Post by James19142

Just to test & ensure the warning wasn't caused by something else, considering all the code in the scenario that could've contributed, I wrote this little sample and got the same exact warning.

#include <iostream>

using namespace std;

struct Base
     inline Base(int a) : a(a){}
     int a;

struct Derived : virtual Base
    inline Derived(int a) : Base(a){}
    inline Derived() : Derived(2) {}

int main()
    return 0;

I don't wanna disable it, because I usually find the unrefenced parameter warning quite useful, but in this case, not so much. I need to know what's causing it and/or if I should ignore it.

When I remove the virtual specifier the warning goes away.
Still using Visual C++ Compiler 12.0

Edited by James19142


This is a very weird error. I suspect that it's a bug in MSVC. Delegating constructors is a pretty new feature for MSVC. AFAIK, there isn't much experience with it yet, i.e., people, like me, don't use delegating constructors yet because we have to cater to the lowest common denominator when it comes to compiler issues, and the lowest common denominator is always the Microsoft compiler, of course. MSVC's support for C++11 features is still very flimsy, and as a compiler in general, MSVC is more unstable than ever now. The 2008 and 2010 versions were quirky but stable, but the 2012 and 2013 versions are totally out of wack and frantically trying to support C++11 features but falling short.

I compiled your code with every compiler I have easy access to: Clang 3.5 (Linux), Clang 3.6 (Linux), Clang-cl 3.6 (MSVC-compatible compiler, Linux), GCC 4.8.2 (Linux), GCC 4.9.2 (Windows), and MSVC12 (Windows). And I enabled every possible warnings.

The only compiler that said anything about this code was MSVC-12, giving the warning that you reported in your first post.

Your code looks perfectly fine to me (except that your inline qualifiers are useless here, because it's implied when member functions are defined within the class definition).

And a google search seems to show a remarkably low level of references to this particular problem. The only one I found was a pull request on github about avoiding the use of delegating constructors because of this spurious warning from MSVC.

All of that tells me that this is a bug in MSVC, plain and simple. I suggest that you file a bug on Microsoft Connect with that particular example which reproduces the problem. And in the meanwhile, just avoid delegating constructors.

When I remove the virtual specifier the warning goes away.

Which is probably why this bug went undetected until now. Combining two extremely rarely used features, delegating constructors in MSVC12 and virtual inheritance, made the probability of ever finding this bug very low. Which is why you should file it. Of course, MSVC's bug tracker still has bugs lingering from 2003, so I've heard... so, don't get your hopes up for some sort of fix to that bug, unless it happens to be very easy to fix.

Edited by mike_2000_17: typo


Thanks for the reply, and unfortunately, I found that the warning does correspond to strange runtime errors; while debugging them, I noticed the debugger had the wrong types associated with the virtual pointers. After reading your reply, I reverted to calling the original constructor and the issue seemingly disappeared.

I found the delegating contructor feature quite convenient, but usage of the DirectX api requires that I use the Visual C++ compilier, so it seems that I have somewhat limited usage of the feature for now. I guess I'll take your advice and report the bug and hope it isn't present in their 2015 release as well.

This question has already been answered. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.