snprintf?

[Andy_B_]

Hi,

I wonder how can I benefit from snprintf() in ICL for Windows?

I keep getting errors like this, despite including stdio.h and defining Qstd=C++11

launch.cpp(52): error: identifier "snprintf" is undefined

Thanks

[Om_S_Intel]

The snprintf() is part of C99 standard. you may try /Qc99 for the C file.

Could you please help me with test case?

Thanks,

Om

[Andy_B_]

Doesn't work in C++ at least, and when adding /Qc99 it tells me the switch is not valid for .CPP files.

Despite its part of C99 it's reasonable to expect it accessible on C++ imo.

Test case

#include <stdio.h>

int main(void)
{

        int n  = 10;
        char buffer[1024];

        snprintf(buffer, 1024, "I like %s\n", Intel);

        return 0;
}

Written on my phone in a minute. Untested.

Thanks

[TimP]

It's expected that -Qstd=c++11 would go as far as possible toward enabling functions which originally were associated with C99 (current option -Qstd=c99, but of course that's not your answer). 
No doubt you saw the search engine hits which point out that the Microsoft spelling is _snprintf(). and it's common practice to use macro substitution as a work around,   I don't have VS2013 to see whether the improved c++11 support supposedly included there would cover this.  Evidently, ICL doesn't address extending VS to cover .

[Andy_B_]

No but is it the right thing to copy cat the behavior of such a heavily broken, clumsy and rebel compiler like VS?
If you guys want to mimic VS then I should just get VS as well... I mean... whats the point to pay milti k$ license if its the same problems ported over?

I have seen Intel do things differently to be honest. For example allow printf("%lld\n"); which isnt supported in VS.
I would think it would be a reasonable thing to implement the correct function names instead of purposely breaking things like MS does.

[SergeyKostrov]

>>... >>I have seen Intel do things differently to be honest. For example allow printf("%lld\n"); which isnt supported in VS. >> >> I would think it would be a reasonable thing to implement the correct function names instead of purposely >>breaking things like MS does. I do not think that Intel C++ compiler team has a task to work on implementation of "...the correct function names...". When Intel C++ compiler is integrated with a Visual Studio it uses standard header files with declarations of C Run-Time functions, like 'printf', 'snprintf', etc, implemented by Microsoft software developers. Also, 'snprintf' is so old C Run-Time function that it can be used without any command line options specific to some C or C++ standards.

[SergeyKostrov]

>>I have seen Intel do things differently to be honest. For example allow printf("%lld\n"); which isnt supported in VS. What version of Visual Studio do you use?

[TimP]

By fiddling with ICL options it's possible to trigger the error diagnostic (from VS2012) that the Microsoft function _snprintf() is deprecated (by Microsoft) and replacement by _snprintf_s() is required. If you open up your search engine you'll find more expert commentary on that point.

I don't fully understand which Intel options are intended to invoke the stricter Microsoft ones, and the ICL docs are less than helpful about it.

In the role Intel undertook to supply a Microsoft-compatible plugin, it's difficult to buck decisions Microsoft took about dialects.  If you want compilers and libraries which are more independent of Microsoft implementation, such may be available, but Intel's take that there isn't sufficient market for them in the Windows arena seems justified.  ICL puts more priority on "leveraging" instruction set features than on rationalizing discrepancies between Windows and linux usage.

[Andy_B_]

Sergey Kostrov wrote:

I do not think that Intel C++ compiler team has a task to work on implementation of "...the correct function names...".

Your wording sounds like as if it was a huge and difficult request, that would be time taking and a pain to implement. One could do this in about 30 mins, since it's just header stuff. Anyways... I'll leave it at that. I perfectly agree with putting priority on optimizations and bleeding edge techs, yet, a low difficulty request as this one, which would certainly increase linux to win and vice-versa code compatibility, without having the dev to do it by himself, would be IMO a great improvement. And I certainly know what I'm talking about here.

As said, I'm leaving it at that.