Where to put using directives in C++ header files

but now I read that using using in that way can be problematic, since it forces this alias on everything that includes this header.

This problem applies equally much to the class Bar that you define. All programs that include this header are bound to use this definition of Bar.

So, I just put the using inside the class

You've reduced the number of declarations in the global namespace. This is good.

However this has the drawback, that I need to restate the alias in the source file

This is unnecessary.

If you make the alias public, you can refer to it using the scope resolution operator as Bar::FooTable. Or you can use a trailing return type, in which context names are looked up within the scope of the class:

auto Bar::create_foo() -> FooTable

There is a more general solution: namespaces. Put all your own declarations into a single namespace (which can further be divided into subnamespaces). This way you only introduce one name into the global namespace which greatly reduces chance of name conflicts.

Where to put using directives in C++ header files

Same reasoning applies as where you would put any of your other declarations. At least into your own namespace, but generally putting declarations into as narrow scope as is sufficient is a decent rule of thumb. If the type alias is only used with that one class, then a member type alias makes a lot of sense.


However this has the drawback, that I need to restate the alias in the source file:

That is incorrect. You need only make it public then specify the proper scope, so you'd call it Bar::FooTable outside of the scope of Bar (which includes return types, unless trailing!):

Bar::FooTable Bar::create_foo()
{ /* ... */ }

or

auto Bar::create_foo() -> FooTable
{ /* ... */ }

(Just FooTable is fine within the definition, as it's a member!)

Your approach is fine, though I'd put everything in a namespace too. Then it doesn't really matter whether your alias is in the class or not: it's still self-contained within your own code. It becomes purely a matter of style, with little to no impact on anyone else.