It's a vague question. Do you really mean "assembly language" or are you talking about binary machine code in some executable format (like an exe file in Windows or the contents of a ROM)?
If you're trying to reverse-engineer compiled binary of a program originally written in C++, forget about it. Too much information has been discarded during the compilation process. For example, all non-extern names (arguments, local variables, static functions, templates, etc.) are gone, as are any comments (though comments seem to be a thing of the 20th century.)
Many function calls can be replaced with inline code. There's an "inline" keyword in C++ to suggest that the compiler do that, but it's always the compiler's choice. Function calls without the inline keyword may be "inlined" as well. There's no way to recognize whether binary code was expanded inline from a function definition or actually written inline.
The implementation of the standard library varies from one compiler to another--even on the same processor and OS. Inlined code from standard library templates has replaced the function calls, so anything that you "decompile" from that will be specific to one version of one compiler, and not useful on another compiler or OS.
Furthermore, with a decent optimizing compiler, most of the program structure (if statements, loops, function calls that have been inlined, etc.) has been mangled into the kind of "spaghetti code" that programmers used to write directly, for efficiency. Even if you manage to get something that compiles and runs correctly, it will be a unmaintainable mass of "random" logic and computer-generated identifiers
C# conversion from IL code is easier in that the .NET runtime is precisely defined. Many of the above problems still exist, though. Still, you may want to look at dotPeek from JetBrains. It says that it can "reliably decompile any .NET assembly into equivalent C# or IL code."