2

I have a question, if the following short code is actually valid:

class Foo {
public:
   Foo(std::string param, 
       const std::vector<std::string>& vec = std::vector<std::string>({ "value 1", "value 2" }))
   {}
};

This compiles without warning with both gcc and VC++ 2013, but while the gcc compiled program aslo runs fine (on Linux) the VC++ compiled program breaks with a runtime error when the default parameter should be set.

Foo foo("value"); // breaks
Foo foo("test", std::vector<std::string>({ "value", "value1" })); // runs fine

The error when calling Foo foo("value"); is:

File: f:\dd\vctools\crt\crtw32\misc\dbgdel.cpp
Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

Can anyone hint to what is wrong?

xchris
  • 23
  • 2

1 Answers1

1

VC2013 internal bug. It's not entirely up to date with new C++ constructs.

The problem surfaces in the debug delete code, in particular code that's checking against double deletes and deletion of non-heap-allocated objects. Since the relevant objects are std::vector and std::string, there are roughly four options:

  1. Bug in std::string implementation
  2. Bug in std::vector implementation
  3. Bug in dbgdel.cpp code which checks delete in debug mode
  4. Compiler bug in default argument code

Considering the two test cases, the first three are rather unlikely.

Edit2: From the duplicate: "The initializer_list behavior is buggy. In its destructor it calls a vector delete (a delete[]) of the entire range and then deletes the first entry in the array again)." initializer_list is part of the implementation, so this is indeed an internal error in VS2013.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • 2
    link to connect issue? – Mgetz Dec 09 '14 at 15:35
  • It's not that I don't believe you but, until you can provide some evidence to back up your claim (or a solid reason that no such evidence can feasibly be produced), this isn't a good answer. – Lightness Races in Orbit Dec 09 '14 at 15:41
  • 3
    _"Since there are people who don't understand why this is a VC++ bug"_ There's no need to be rude about it. You know how SO works! We expect _evidence_ for claims, for the benefit of anyone reading the answer be it today or in three years' time, whether we personally understand how such a bug could arise or not. – Lightness Races in Orbit Dec 09 '14 at 15:46
  • 1
    I hope we don't follow Skeptics.SE, where they require pure arithmetic to be sourced (I wish that was a joke). Trivial claims don't need evidence. If VS2013 throws an error on its own code, it's by definition a VS2013 internal error. We have a reasonable idea how VS2013 works internally (i.e. vector and string are not compiler magic) so we can narrow it down even further, but that's not even necessary. – MSalters Dec 09 '14 at 15:54
  • @MSalters There is an easy solution to this issue, either find or file a connect bug. That's all I'm asking for. – Mgetz Dec 09 '14 at 15:55
  • 1
    @Mgetz: Sounds eerily familar to Skeptics.SE too: you can't provide original research on the site itself, but put it anywhere else on the web and link to it to bypass the formal rule. – MSalters Dec 09 '14 at 15:58
  • 2
    @MSalters I think the point is that a bug report that you file would provide a concrete continuation to your claim for future visitors, via official bug report replies. –  Dec 09 '14 at 16:00
  • This is clearly a `VC` *bug*! Why are you down-voting, people? Are you familiar with `C++` at all? – GreenScape Dec 09 '14 at 16:01
  • Ah ok thank you. And yes I know it can be easily fixed by overloading the constructor, but I was wondering if the code is actually correct (and thus it's a vc bug) or not. – xchris Dec 09 '14 at 16:04
  • 1
    @MSalters on the contrary it's easily testable, making a simple test case and filing a bug is all that's required. There is no anecdotal evidence required at all. – Mgetz Dec 09 '14 at 16:06
  • @xchris, your code is perfectly fine according to `C++` standards (C++03, C++11, C++14). It's just you're development tools are faulty. Usual thing for MS, don't worry. It's easier to workaround (2 overloaded versions of constructor) and forget about it. – GreenScape Dec 09 '14 at 16:08
  • "It's a compiler bug" is equivalent to "There's a problem in your code" for regular programming mistakes, IMHO. – Shoe Dec 09 '14 at 16:11
  • 1
    @Jefffrey: With vague symptoms, yes. But then the error message points to the compiler code itself, that's less likely. (of course, there's always the possibility that there are errors in both the compiler _and_ your code) – MSalters Dec 09 '14 at 16:16
  • If nothing else you did not present a workaround so the answer is still not particularly useful. :) – Lightness Races in Orbit Dec 09 '14 at 16:16
  • @GreenScape: Read the comments. And stop enclosing non-code in code formatting please. – Lightness Races in Orbit Dec 09 '14 at 16:18
  • @LightnessRacesinOrbit the absence of link to bug report is bad reason for down-vote. Correct me if I am wrong. Especially when this is obviously a *compiler bug*. Personally I feel like this is just a down-vote flood, done by MS lovers. Do not take it personally. – GreenScape Dec 09 '14 at 16:25
  • @GreenScape hardly, we want MS to fix their garbage just like everybody else, but without a bug report that's less likely to happen. – Mgetz Dec 09 '14 at 16:33
  • @GreenScape: What? I don't use Microsoft products, let alone defend them. Just because a problem is caused by a compiler bug doesn't mean the required standard of answers magically gets cut down to single-line assertions with no solution suggested. – Lightness Races in Orbit Dec 09 '14 at 16:36
  • @GreenScape The original answer before the edit was a one-liner without additional details, which isn't a great answer regardless of whether or not it's correct. –  Dec 09 '14 at 17:40
  • @remyabel, Mgetz, LightnessRacesinOrbit, sorry, guys, I just misunderstood. When I saw this answer having -2 it was pretty much complete, so I was confused. – GreenScape Dec 10 '14 at 09:03