Depends on how much portability you wish. If you're willing to get ahead of the curve, with functions that might find their way into the C++ standard, look up boost filesystem. Otherwise, it is not hard to roll your own, depending on what you want to achieve.
Using system calls inherently limits you to your original target system (or systems compatible with it). More importantly, however, such things can be broken depending on how your system is configured, because system calls inherently rely on whatever command interpreter is invoked by the system() call - such things are inherently implementation defined. Furthermore, relying on command interpreters also makes your program vulnerable to system configuration (what version of a shell is configured) and user configuration (what startup scripts the user executes).
If you are happy being limited to posix systems, you might want to look up functions named mkdir() and chdir(). Information on those may be found via "man 2 mkdir" and "man 2 chdir" respectively (on most unix systems, assuming man pages are installed).
More generally, however, you will need to write code that detects the target system (or maybe, compiler) and responds accordingly. For example, for a function that creates a directory ....
Depending on what systems you wish to port to, you will need to identify particular macros and header files for each one. Since these capabilities are outside scope of the C or C++ standards, you are left with having to use techniques that vary with target system.
// untested code, written to demonstrate the basic approach, follows.
#if defined (_WIN32) // _WIN32 is defined by many compilers that target windows
#else // assume POSIX (or, at least, some common unix setup)
bool create_directory(const char *path) // return false if we succeed
return bool(CreateDirectory(path, LPSECURITY_ATTRIBUTES(NULL)));
return bool(mkdir(path, S_IRUSR | S_IWUSR | S_IXUSR)); // grant owner access only
In the above, I have assumed you want to use win32 API functions under windows, and otherwise will only build on a posix system. Those assumptions are not true in general (libraries with compilers targeting windows often support posix functions, and "not windows" is also not the same as "posix").