Is there a way to make the following code portable?

....It is quite portable inside the unix land....but I'm looking for a way to make it more standard.
The two following functions are 1.constructor for a disk class (for a virtual machine) and a way to execute shell directory commands of the host system.

Code:

disk::disk(string name,vm* owner)
{
    /// Check if name is already in the global list


    ofstream new_disk("disks/"+name+"_prop");
     
    new_disk<<"Name: "<<name<<endl;
    system(("mkdir disks/"+name).c_str());
    
    pwd="disks/"+name+"/";
    disk_of = owner;
    //(*disk_of).shell(); //Works
}

Code:

void disk::command(std::string com)
{
    istringstream in(com);
    string test;
    in>>test;
    if(test=="cd")
        {
            in>>test;
            pwd+=test; //pwd is a string containing the present working dir to carry over from calls to system();
            system(("cd "+test).c_str());
        }
    else
    {
        system(("cd "+pwd+" && "+com).c_str());
    }
}

This perhaps ?
Filesystem Home

That page , at a point says that

A proposal, N1975, to include Boost.Filesystem in Technical Report 2 has been accepted by the C++ Standards Committee. The Boost.Filesystem library will stay in alignment with the TR2 Filesystem proposal as it works its way through the TR2 process.

Does that mean, C++11 would contain something like the Boost Filesystem library ?.. I can't find anything to verify it ..(open-std.org only mentions that it'd been proposed....)

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 ....

Code:

//   untested code, written to demonstrate the basic approach, follows.

#if defined (_WIN32)      //   _WIN32 is defined by many compilers that target windows
#include <winbase.h>
#else                            //   assume POSIX (or, at least, some common unix setup)
#include <sys/stat.h>
#include <sys/types.h>
#endif

bool create_directory(const char *path)   // return false if we succeed
{
#ifdef _WIN32
      return bool(CreateDirectory(path, LPSECURITY_ATTRIBUTES(NULL)));
#else
      return bool(mkdir(path, S_IRUSR | S_IWUSR | S_IXUSR));    //   grant owner access only
#endif     
}

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.

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").