Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: API deprecation model  (Read 17395 times)

0 Members and 3 Guests are viewing this topic.

Foaly

  • Sr. Member
  • ****
  • Posts: 453
    • View Profile
Re: API deprecation model
« Reply #15 on: September 18, 2015, 08:21:57 pm »
[deprecated] is only available in C++14 as far as I know.

@Mario: Thanks! Good catch. I'll report that to the openFrameworks developers!

edit: whoops I was to quick ;) This article seems to explain it quiet well. According to the article it is already built in Clang 3.4 and GCC 4.9
« Last Edit: September 18, 2015, 08:26:00 pm by Foaly »

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
Re: API deprecation model
« Reply #16 on: September 19, 2015, 03:18:10 am »
[[deprecated]] and other non-standard C++ compiler-specific intrinsics can be used as an implementation detail of a deprecated-function-marking macro. IMMIC they are all compatible in that you can use them in the same places in code.

Just some input from how we do it in my dayjob (humanoid robot APIs, which have the same kind of issues because interface evolve a lot but most interfaces need to be usable for a long time):

 1. Compile Time: we have a macro using whatever the compiler have available to trigger warning to users of functions and types we mark with that macro. It indeed works well at compile time IF you manage to not have any other warnings on all your supported plateform. We use Boost so we get often tons of warning on some plateforms so it works but we have to patch Boost each time we upgrade it. I don't think SFML would have this kind of problem.

 2. Runtime: we have a logging system and we add a log at "warning" level each in the implementation of each function we mark as deprecated. It helps in our case because we have some magic making our API available through RPC calls automatically, so most APIs are actually messages between processes and when APIs evolve, your client code should still work after at least one iteration of the API. Which basically mean that users might not compile your API code and just do RPC calls so the only way for them to know (in this case) that they are calling a deprecated API is at runtime.
   The obvious side effect is that logging happen even in previously very fast API functions, though it's not yet an issue for us, at least not for deprecated APIs as we are not yet reaching the point where we will need to have tighter performance (it's not one application, its tons of them, so it's almost impossible to try to improve performance on a case by case, we mostly do performance optimization in inter-process and multithreading systems).
   The other issue is that it relies on the fact that the user will use our logging system, which he will in our very specific case but can't work with SFML I believe. I don't know what would work in the case of SFML for this.

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: API deprecation model
« Reply #17 on: September 19, 2015, 03:32:22 pm »
I created a pull request here: https://github.com/SFML/SFML/pull/969

Concerning runtime warnings/logs: that's definitely something to consider. I think it should be part of our overall log/error output redesign.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Klaim

  • Full Member
  • ***
  • Posts: 137
    • View Profile
Re: API deprecation model
« Reply #18 on: September 19, 2015, 04:35:13 pm »
Concerning runtime warnings/logs: that's definitely something to consider. I think it should be part of our overall log/error output redesign.

Cool! Is there a specific thread where you are discussing/anouncing this? I searched with these words but didn't find anything recent. I don't follow much these forums but I'm interested in the rationals for these kinds of "looks simple but actually hard" topics.

 

anything