I am surprised that no other OSG users have reported this problem yet, we've done quite a few calls for testing with recent releases with active testing under Windows.

What specific compilers and build tools are you using when you see this error?

I am reluctant to merge a change that complicates already overly complicated workaround code, so really want to make sure it's required.

I am surprised that no other OSG users have reported this problem yet, we've done quite a few calls for testing with recent releases with active testing under Windows.

My main machine for testing these releases is MSVC 2015. I also test 2010, 2012, and 2013, though not always against the release candidates. I do not currently build MSVC 2017 (15.8), so I wouldn't have seen this in any of my testing.

I have just compiled the 3.6.2-rc2 using Visual Studio 2017 version 15.7.4 and the seekpos() is still available in this version. So this must have been something that changed in the preview versions of Visual Studio. I have browsed the release notes for 15.8 preview 1, 2 & 3, but I fail to find any notice about this.
https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-preview-relnotes

But it might be related to Microsoft's new deal with trying to be fully standard conformant.

Thanks for the feedback. So a preview version? Does this mean that it could be part of the next VS release like a VS 2018 or just a point release of VS2017?

If this is part of a MS effort to be more standards compliant then could we just change the code to be the same as use for other platforms rather than having all these workarounds - I'm expecting to have all the old workarounds still required, but would rather avoid yet another layer of MS VS workarounds.

This is a point release of 2017. Usually the preview version take about a month or two to propagate to the stable version. So this issue will become apparent for all Visual Studio 2017 users quite soon.

Hi, sorry for the misunderstand about VS15.8, in fact, we are testing OSG in an upcoming VS 2017 release. So for this PR, you can consider it is a future PR that will unblock customer.
I used _MSC_VER to check if customer use VS 2017 or previous VS. Moreover, I think if you merge this PR now, it will unblock anything because below code definaton:
#if (defined(_CPPLIB_VER) && defined(_MSC_VER) && _MSC_VER <= 1900)//newer Dinkumware(eg: one included with VC++ 2003,2005)
fpos_t position = pos.seekpos();
#elif (defined(_CPPLIB_VER) && defined(_MSC_VER)) // VC++ 2017 or latest
fpos_t position = pos;

@LarryIII But shouldn't the _MSC_VER version wait to trigger until it is larger than the current working compiler version, i.e. 1914?

Such that the code should be written as:

#if (defined(_CPPLIB_VER) && defined(_MSC_VER) && _MSC_VER > 1914)   // VC++ 2017 version 15.8 or later
	fpos_t position = pos;
#elif (defined(_CPPLIB_VER) && defined(_MSC_VER)) // Dinkumware (eg: one included with VC++ 2003, 2005...)
	fpos_t position = pos.seekpos();
#else // older Dinkumware (eg: one included in Win Server 2003 Platform SDK )
	fpos_t position = pos.get_fpos_t();
#endif

Thanks @bjornblissing, your suggested code looks more natural ordering, with the latest variant coming first, then the older MS variant then the fall-back.

@LarryIII could you modify your changes along these lines, I can then merge the changes and gets some testing of this, then I'll make a 3.6.2-rc3. Cheers.

[note: Larry & I are on the C++ team in Microsoft]
osg is in vcpkg and we run daily builds for the entire vcpkg catalog with our latest compiler daily builds.

This particular change is indeed a conformance change; the C++ spec does not specify a seekpos() function so it is getting removed in the upcoming 15.8. This is also why it hasn't shown up for users yet.

We will amend this PR with @bjornblissing's suggestion and update to 3.6.2-rc3 in vcpkg. :)

Closed this one! I have sent a new PR in: #569
Please help merge. And we will update to 3.6.2-rc3 in vcpkg. Thanks all!