Poco::format receives empty Vector<Any>

[KevDi]

Describe the bug
I have the strange behaviour that when i call Poco::format(std::string& result, const std::string& fmt, const std::vector<Any>& values) the function always receives an empty vector. This will then crash the Program because it tries to dereference an iterator to that vector.

To Reproduce
This is the Example which leads to the crash on my side:

#include <iostream>
#include <Poco/Any.h>
#include <vector>
#include <Poco/Format.h>


void dummy_func(const std::vector<Poco::Any>& para) {
  std::cout << para.size() << '\n';
}

int main()
{
  std::vector<Poco::Any> values;
  std::string dummy{ "3.3.2" };
  std::string result;
  std::string fmt{ "Dummy: %s" };
  values.emplace_back(dummy);
  dummy_func(values);
  Poco::format(result, fmt, values);
}

If i call a function which accepts a Reference to an std:vector<Poco::Any> the function receives the correct vector.
I'm not sure why it is not working in the Poco::format function.

Here you can see that the vector contains elements before calling Poco::format:

and inside Poco::format:

Please add relevant environment information:

• Windows 10
• 1.12.0

[aleks-f]

Can't reproduce

[aleks-f]

@KevDi I recommend a thorough cleanup and check of your development environment - my best guess at this point is that you have some headers or binaries version mixup somewhere

[KevDi]

ok yeah this could be possible because i just did a git pull to get the latest version of the master branch so maybe i check it out directly from git again to get a clean version of poco

[KevDi]

@aleks-f I just did a clean build from poco. Same error. But i found out that if i add the /permissive- (Conformance Mode) Option i got again the Issues i mentioned (#3683 & #3682)

[KevDi]

@aleks-f i did some further investigations on two different systems.
System 1:

• Windows 10
• Visual Studio 2019 Professional
• Platform Toolset v142

System 2:

• Windows 10
• Visual Studio 2022 Professional
• Platform Toolset v142 & v143

On both systems i did a clean checkout of the Poco Library and build them with the buildwin.cmd command. I built the standard CppUnit, Foundation, Encodings, Net, XML, JSON, Util, Prometheus components. On both systems with the option 160 build shared both x64 nosamples notests

On both systems i created a simple Console Application with the default settings from Visual Studio.
This was the code i added to both projects:

#include <iostream>
#include <Poco/Any.h>

int main() {
  Poco::Any any_type;
  std::cout << "Test\n";
}

Both of the Project had the Conformance Mode set to /permissive- (Conformance Mode enabled).
If i build both projects the compiling failed with the Message from Issue #3682.

If i set Conformance Mode to /permissive (Conformance Mode disabled) both projects did compile successfully.

I searched then about the option on the Windows Documentation (/permissive- (Standards conformance)

I looked also into what of the /Zc options are set if the /permissive- Option is given.

It seems like the Option which causes the Problem is the /Zc:twoPhase. With this option Windows uses two-phase name lookup.
If i disable this Option by adding /Zc:twoPhase- as an additional Option under Configuration Properties > C/C++ > Command Line the program compiles even with /permissive- .

Here is the Documentation of the /Zc:twoPhase Option: /Zc:twoPhase- (disable two-phase name lookup)

[aleks-f]

ah, it probably wants a typename or template somewhere in the assign function declaration. see if you can find where, or wait until I have time (and patience) to deal with that dumb compiler (other compilers seem to have no issues with it)

[KevDi]

@aleks-f i stopped counting how often i was frustrated by Microsoft and it's interpretation of the C++ Standard.
If i have the time i will check the assign function tomorrow and see if i can fix that issue

[KevDi]

@aleks-f i tried adding typename or template to the function declaration but with no luck. But it could be that there is a bug in the Compiler it self. I opened a ticket at the Microsoft Visual Studio Developer Community.

[aleks-f]

I'm starting to lean towards a compiler bug. If there is a corresponding define for the /Zc:twoPhase, then we can disable SOO for it as a workaround until MS compiler comes to its senses.

Btw, I'm not seeing /permissive- as a default on VS 2019 or 2022

[aleks-f]

An interesting observation: it will compile with both /Zc:twoPhase and /Zc:twoPhase-

Although it obviously has an effect, the explicitly enabled two-phase lookup is not recognized as a valid option:

cl : command line warning D9002: ignoring unknown option '/Zc:twoPhase'

[KevDi]

@aleks-f according to the documentation it seems like there is only the /Zc:twoPhase- option to disable it. To enable it you have to set the /permissive- option. As far as i understand it from the documentation.
But yes i agree with you that it is more likely a bug in the Compiler.

[KevDi]

@aleks-f It seems like Microsoft has approved this as a Bug according to my Request on the Developer Community.
They also provide a Workaround which should let the Code compile in /permissive mode.
Instead of using:

struct Size
{
	static const unsigned int value = SizeV;
};

an enum should be used:

struct Size
{
	enum { value = SizeV };
};