#557 OWLNext 6.44 does not compile with C++ 17

[Lars Fastrup]

OWLNext 6.44 does not compile with C++ 17! I get this error:

\VS2022\owlnext-6.44.20\include\owl\objstrm.h(408,47): error C2039: 'seek_dir': is not a member of 'std::basic_ios<char,std::char_traits<char>>'

Changing line 408 in objstrm.h from
ipstream& seekg(std::streamoff, std::ios::seek_dir)
to
ipstream& seekg( std::streamoff, std::ios::seekdir );
resolves the issue and our code compiles with C++ 17
Can you confirm this?
Can the fix be applied to the OWLNext version 6 branch?

[Vidar Hasfjord]

This is not a bug, but a feature. Version 6.44 has Long-Term Support with support for a lot of old legacy compilers, so need to work even for compilers not fully C++11 compliant. Support and requirement for C++17 was introduced in OWLNext 7 for far fewer modern compilers. Version 8, in development, supports C++20 and just the latest compilers from Embarcadero and Microsoft.

If you need C++17 in 6.44, you can apply a private patch. See [r3793]. If you really want official support for C++17 in 6.44, you can create a feature request ticket. But be prepared to provide long-term support, including for all the old compilers.

Tip: If you have a problem, and you are unsure whether it is a bug in OWLNext or not, post in our discussion forum for clarification and advice, so that we avoid "won't fix" tickets.

See FAQ | How do I report an issue?

[Lars Fastrup]

Ok thanks - will do a private patch for now!
We will eventually upgrade to OWLNext 7 - but for now this task stays in our backlog.

PS. Sorry for reporting this as a bug - just assumed it was one as I only encountered problems with this one line of code. Will consider a feature request with some #ifdef logic on the value of __cplusplus.

[Vidar Hasfjord]

@lfastrup wrote:

Sorry for reporting this as a bug

Just to let you know; I found it deeply insulting that you could suggest we release bugs. :-)

Will consider a feature request with some #ifdef logic on the value of __cplusplus

Please don't. I hate conditional code. And it would mean I will have yet another build mode to test. Leave a good reason for hastening the transition to version 7 instead.

A private patch should work well, I would think. 6.44 is in long-term support maintenance state now, with very little happening on that release branch. So you should be able to apply your private patch and pretty much forget about it.

That said, if there are volunteers forthcoming and keen to further develop, maintain and support 6.44, then by all means.

[Lars Fastrup]

He he - you would then be the first developer in history to release bugfree software 😅
But still you have a history of 557 - sorry 556 bugs 😁
I think that is still quite an impressive low number for this framework, considering the scope and number of years in the market. I'll leave it here and advise the decisionmakers to prioritize the upgrade to version 7 sooner than later. Until then we live with a private patch. Thanks again for your great and prompt support 👍😀

[Vidar Hasfjord]

@lfastrup wrote:

[556 bugs - that] is still quite an impressive low number for this framework

Well, with me around, no one dares creating bug tickets. :-)

you would then be the first developer in history to release bugfree software

I don't release bugs. I only release regressions. And of those, only the chief himself @jogybl is brave enough to mention them. I don't know why.

I'll leave [the issue of C++17 support] here and advise the decisionmakers to prioritize the upgrade to version 7 sooner than later.

Great! The closer we all are to the trunk, the better for the project.

Actually, your request to fix the compilation error isn't that much to ask. The problem is the broader issue of promising C++17 support in 6.44. That may limit what patches can be made later, or at least make them more involved to test. Say, for example, an issue arises for a user of an old but supported compiler for 6.44. However, the obvious fix isn't C++17 compliant. Then we would have a conflict. And, even if the fix wasn't an issue for C++17 support, I would have to test that it wasn't. See?

In conclusion, keep you eyes open for the preparation of the next maintenance release of 6.44, if any, and then suggest a code fix that will eliminate the compilation error for all the supported compilers (maybe they actually all already support the new name std::ios::seekdir). That could make 6.44 build with C++17 compliance, without us promising to maintain C++17 support — unless you stick around and always make sure that future releases for 6.44 maintain the support, of course.

[Lars Fastrup]

Ha ha - yes learned that as a newbie in this forum 😁
Thanks - will be ready to test next release of 6.44

[Vidar Hasfjord]

Thanks - will be ready to test next release of 6.44

Super — good to have you aboard!

[Vidar Hasfjord]

@lfastrup wrote:

will be ready to test next release of 6.44

@jogybl has started preparation for a maintenance release. So, if you can provide a API and ABI compatible patch that works with all supported compilers for 6.44, now is your chance to have it included.