Aws-sdk-cpp: POLL: Would you be in favor of migrating the SDK to C++17?

[marcomagdy]

Notes:

• The C++11 codebase can either continue to be on the master branch or moved to a C++11 branch.
• If C++17 were to be released in the master branch, it would obviously result in a major version bump. So, v2.0.0 of the SDK.

[Bu11etmagnet]

I consider migrating to C++17 a bit premature. The default C++ dialect of both clang and GCC is C++14 (and clang only recently moved its default to C++14 from C++98). Plus, the SDK doesn't even take full advantage of C++11.

[marcomagdy]

Plus, the SDK doesn't even take full advantage of C++11.

Can you give examples, please?
I suspect what you might have in mind is due to lack of support in one of the compilers that we _still_ have to support (looking at you VS2013). But I'd love to hear from you. Maybe it's something we overlook.

[crusader-mike]

C++17 is good, but in terms of priorities I suggest spending resources on:

• getting rid of iostreams
• asynchronous programming model support
• more templates and fewer virtual functions -- as of now (if statically linking) using any part of SDK causes your binary to gain few megabytes (because compilers can't discard symbols referenced by vtables). If linking dynamicaly -- you have to drag couple of megabytes of SDK libraries with you

[Bu11etmagnet]

For example,

inline void Aws::CloudWatch::Model::PutMetricDataRequest::SetMetricData(Aws::Vector<MetricDatum>&& value) { m_metricDataHasBeenSet = true; m_metricData = value; }

looked like this until about a year ago (performing a copy instead of a move).

[webbnh]

(I only just became aware of this poll -- thanks @singku for pinning it!)

We use C++11, because it has enough features and because it's supported by the components that we depend on (none of which, to the best of my knowledge, support anything newer).

Am I right in thinking that, if the SDK moved to C++17, I won't be able to use it from C++11 anymore? That would be crushing!

What's the pressure to move to '17? (I would expect that runtimes like the SDK would lag not lead the switch to newer language versions, assuming that layered code written in newer versions could still call down to code written in older versions.)

I would rather see effort on providing full-featured streaming support (so that files can be read _as_ they are downloaded, so that they can even be processed on the fly and never saved anywhere).

[kcrossen]

There are so many other issues as the sdk stands.

For example, some of these issues make the sdk nearly unusable for anyone not ready to dive into (and fix) the make process itself.

Migrating to C++17 can only degrade the sdk's usefulness, if only by draining time better spent resolving these other issues. None of these issues can possibly be resolved solely via C++17 w/o a complete rewrite anyway.

[infinitebuzz]

Too early, and what would be the advantage. C++11 compiles everywhere and has a great feature set. Until there is a C++17 feature the SDK needs, stay on C++11.

[Bu11etmagnet]

What I would support wholeheartedly is taking advantage of C++17 if available, but not requiring it.

For example, overloads for std::string_view, guarded by #if __cplusplus >= 201703L

[marcomagdy]

Too early, and what would be the advantage. C++11 compiles everywhere and has a great feature set. Until there is a C++17 feature the SDK needs, stay on C++11.

There are plenty of C++17 (and C++14) features that can be advantageous to the SDK. To name a few:
Features that affect performance and/or memory footprint:

• relaxing constexpr constraints (we have many hashing functions that hash to a static value that can benefit from this).
• std::string_view, std::optional
• inline variables

Features that affect the expressiveness of the code:

• generic lambda expressions
• structured bindings
• CTAD
• nested namespaces

[marcomagdy]

What I _would_ support wholeheartedly is taking advantage of C++17 if available, but not requiring it.

For example, overloads for std::string_view, guarded by #if __cplusplus >= 201703L

That significantly increases the complexity of the SDK (and debugging it). Many code paths, bugs that happen given one code path but not the other.

If we ever move to C++14 or C++17, it will be a v2.0 type of thing. And we can rid ourselves of all the cruft that was added over the years to support non-conforming compilers while taking advantage of the new features. And just to be clear. I'm not speaking of a re-write (that would be insane), but more of a cleanup round.

[github-actions[bot]]

Greetings! Sorry to say but this is a very old issue that is probably not getting as much attention as it deservers. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.

[Deikras25]

Dobr

[Deikras25]

?