Can I force a compiler error if certain functions are called?

Promoting my comment to an answer:

You can use a macro to redefine them to something that won't compile:

#define GetProfile  HAHA_Nice_try_This_will_not_compile!!!

The catch is that you need to make sure that it isn't (legitimately) called outside your code.
(So you should put the macro after all your includes.)

If you're free to turn the function into a template, you can do something like this:

template <typename...>
struct always_false { static constexpr bool value = false; };

template <typename... Ts>
void never_call_me(Ts&&...)
{
  static_assert(always_false<Ts...>::value,
                "You should have never called this function!");
}

This has the advantage that the compile error will be clean + you can provide an error message. Found here, see that answer for more info on why this works + why always_false is needed.

The accepted answer is to mark the functions as deprecated, but that doesn't really fit what the question is asking, for two reasons:

• It only gives a warning, not an error.
• It will give warnings even if you're using the v1 code.

There's good reasons to want that, but it's not actually what the original question asks for.

Luckily, there's a really easy way to get what the questions asks for. The compiler will always throw an error if the function simply doesn't exist. Just throw the functions in an #ifndef.

#ifndef V2

void GetProfile()
{
  // Get the profile
}

void WriteProfile()
{
  // Write the profile
}

#endif

Since this answer is accepted I might as well include the solution the asker actually used:

jacobsee discovered the deprecated pragma

#pragma deprecated(GetProfileInt)

---

Original answer:

You may be able to declare them as deprecated using __declspec(deprecated). It would look like this:

UINT __declspec(deprecated) WINAPI GetProfileInt(
  __in  LPCTSTR lpAppName,
  __in  LPCTSTR lpKeyName,
  __in  INT nDefault
);

You'll have to do so from a header that is included in every translation unit you care about. Doing so will result in a warning any time a translation unit that includes the deprecated declaration uses that function.

If you want a compiler error and if your project doesn't already treat warnings as errors then you'll have to turn that on, and maybe fix all the warnings you've been ignoring. (These are good practices whether you use this solution or not.)