1

Except for the fact, that it would probably confuse every windows c++ developer out there,

wouldn't it be prudent to expand _In_ to a mandatory const (if not already present) to ensure const correctness?

So 

int DoSomething( _In_ int * pInput);

becomes

int DoSomething( const int * pInput);

Obviously _[In]Out_ should still expand to nothing.

Edit: Obviously the first problem is that, this only makes sense when expanding in front of a pointer or a reference parameter.

So maybe a simpke macro expansion will not suffice. I don't want to abandon the notion of enforcing const just yet. The motto is: We already have a SAL notation that tells us what parameter is ro and what not, let's make some use of it.

MrPaulch
  • 1,423
  • 17
  • 21
  • Isn't the real question, why is the argument a pointer in the first place? – Sebastian Redl Nov 11 '14 at 11:03
  • No. But rather, can I (in cooperation with the precompiler) determine whether the following argument really is a pointer. – MrPaulch Nov 11 '14 at 11:05
  • @SebastianRedl: I don't think `boost::optional<>` made it into the C++11 specification (though [cppreference has a related entry?](http://en.cppreference.com/w/cpp/experimental/optional), so what convenient alternative is there for passing an optional argument that doesn't have a convenient sentinel value, and why is it always better? – Tony Delroy Nov 11 '14 at 11:07
  • 1
    @TonyD: `optional` didn't make it, not even in 14. But SAL has a separate annotation for "this is a pointer because it's optional": `_In_opt_`. Since the argument in the example is just `_In_`, I was curious. – Sebastian Redl Nov 11 '14 at 12:15
  • 1
    @MrPaulch The preprocessor will never cooperate with you, especially not on matters of types, since it operates purely on tokens. – Sebastian Redl Nov 11 '14 at 12:16

2 Answers2

1

Assuming it's a macro expansion, that wouldn't work for values copied into parameters, i.e.

void f( _In_ X x) { g(++x); // ok to modify }
Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
1

You should train your programmers to use const for pointer/reference parameters that are intended to be immutable, even if the SAL annotation is used.

Here are some problems with expanding _In_ to const:

  • Programmers who haven't seen SAL annotations before are extra confused.
  • These programmers will then write _In const int* and possibly get a compiler error, depending on whether the compiler diagnoses double const.
  • It's annoying for by-value parameters that the programmer wants to modify inside the function.
  • It's catastrophic for COM interface pointers. COM interfaces never have const members (because that's a very C++-specific thing). This means that a pointer to a const interface is absolutely useless. But you will still, quite often, pass _In_ or _In_opt_ parameters of interface type.
Sebastian Redl
  • 69,373
  • 8
  • 123
  • 157