However, since I'm still trying to understand how C++ applications are structured, I'm not sure how the project should be organized.
This depends greatly on what tools and process you will use. You mention Visual Studio and XCode. Each has it's quircs and both optimize the sources for their own interractions with them (which makes the sources poorly organized for the other IDE).
If you wish to do cross-platform development you should create a source tree that makes sense to you (i.e. not to an IDE). This means you will probably create at least parts of it, manually.
For example, I usually have a project root directory, with something like this inside:
- src (C++ source files)
- include (C++ include files)
- docs (documentation, todo list(s), user stories, etc)
- tools (build tools, custom python scripts for the sources, etc)
- build (for build artifacts and binaries)
- test (for test source code)
I mostly work with command-line tools.
If I want to (for example) integrate the project with Visual Studio, I would create a new directory (e.g. vstudio-2013) and create in there the solution and other specific files. This ensures that when you use an IDE, you don't see specific files from the other IDE (i.e. you don't have to look at Visual Studio solution file from XCode).
These days, I tend to maintain a CMakeLists.txt file and use that to generate a CLI build configuration or IDE-specific configurations (it can generate Visual Studio, Netbeans and XCode projects, and it can also generate a Makefile-based build configuration).
Should I just do this? root/Code (shared .cpp/.h), root/Win, root/Mac, ...
Probably not. You can consider centralizing all items of a single type in a directory, and then specialize it by type, category, module, etc.
- root/src (src - all sources)
- root/src/os/win (windows specific)
- root/src/os/linux (linux specific)
- root/src/os.h (header hiding os-specific implementation behind abstract OS interface)
- root/src/gamelogic (or whatever)
- root/src/unittest (you should probably have one directory per library/module)
- root/build/tmp (temporary build artifacts)
- root/build/bin (binary outputs)
This will allow you to treat all files of a single type in a unified way (e.g. add all windows-specific sources to a library, by providing the directory only).
I guess to a degre it's personal taste, but I do wonder if there are best practices.
More like guidelines for things that work (and these are not universal). The "best practices" that apply to a linux&mac project will probably have to be altered a bit to fit Windows as well (and similar in the other cases).
on Windows, I use Visual Studio 2012 (Considering buying '14' once it's out), on Mac OS X and iOS I'll be using whatever the latest XCode is (right now 5.1) and I haven't looked into options for Linux yet.
I use NetBeans (C++) on Linux and OSX. I also use a terminal and CLI on both (doing mostly editing in NetBeans, and compilation, SCM, running, and tests in the CLI. Also, because I use unit tests, I rarely need to use a debugger (when feasible, prefering unit tests to debugging, can be considered a "best practice").