http://yaml.org/ , in particular, yaml-cpp. From their example/tutorial:

YAML::Node config = YAML::LoadFile("config.yaml");

if (config["lastLogin"]) {
  std::cout << "Last logged in: " << config["lastLogin"].as<DateTime>() << "\n";
}

const std::string username = config["username"].as<std::string>();
const std::string password = config["password"].as<std::string>();
login(username, password);
config["lastLogin"] = getCurrentDateTime();

std::ofstream fout("config.yaml");
fout << config;

As has been said before the current format is already much simpler than XML... I wouldn't bother with XML unless you end up with complex enough structures to warrant deep trees. Doesn't look like that's the case here.

If you really want to switch to something more standard, I guess you could go with INI files, though there's a bunch of libraries out there to look for... and it may even be feasible to just write your own parser (the main reason they took off back then is that they're that simple, after all). Or even modify your own, I mean, replace the space with an equals sign and you're halfway there =P

Honestly, XML is pretty verbose and doesn't carry its weight in simple scenarios where flat files, ASCII, JSON, or Yaml would do just as well. XML is an awesome thing (with its share of flaws as well), but it really only shines when you need to represent complex, arbitrarily-nested information in a structured hierarchy, and it only comes into its own when that structure is formally specified, verified, and transformed through the XML ecosystem.

If what you really need is just a list of variables, flat files or ascii text files are just fine. If you need arbitrarily-nested information -- but don't need formal structure -- JSON or Yaml are perfect; in fact, they're great options when you explicitly *don't want* a formal structure -- many times the lack of strict structure is a benefit, all JSON and Yaml structure is ad-hoc. Only when you need a formally specified, hierarchical structure that can be verified and transformed is XML necessary. XML might be sometimes beneficial for interop scenarios as well, or certain encoding scenarios, but JSON is usually just as good unless you're tied to some (rare) party that understands XML but not JSON.

Note that parsers which respect XSDs are about 10x larger libraries and much slower, too.

And on this point, note that you probably don't need the functionality that XSD provides at runtime in any case. XSD is useful for validation, and for authoring content in aware text editors, and for enabling XSLT transformations, but you don't need any of that after release. Your XML files will already have been authored and transformed and ought already have been validated by the time you ship them to customers.

Lets see, verbose XML:

<d3d11_settings>
  <xresolution>1280</xresolution>
  <yresolution>720<yresolution>
  <windowed>true</windowed>
</d3d11_settings>

If you're doing XML you should probably do it like:

<d3d11_settings
 xresolution="1280"
 yresolution="720"
 windowed="true" />

ie, use attributes.

If you're doing JSON:

"d3d11_settings": {
  "xresolution": 1280,
  "yresolution": 720,
  "windowed": true
}

ie, nicer.

If you're doing YAML:

d3d11_settings:
  xresolution: 1280
  yresolution: 720
  windowed: true

ie, "look ma! no double quotes!".

I'd use something else than XML, YAML is nice. JSON is not as nice, but its much more widely used (thus more info on it, more libs, etc).

EDIT: Fixed the JSON as fastcall mentions below.

Anyway, this is my YAML window stuff as an example:

width: 1280
height: 720
fullscreen: false
vsync: yes
softsync: false
vfov: 75
renderdist: 256
resizable: yes

Basically using it as a normal key-value thingy, except i can just call "load" and I get a Map<String,Object> out of it. My renderer pipeline is also made in YAML, using the compact notation, here is a render pass:

dirlight_pass: &dirlight_pass
  name: dirlight_pass
  program: df_dir_light
  drawing:
    name: gbuffer
    targets: [light_acc]
  sampling:
    name: gbuffer
    targets: [albedo, normal, misc, depth]
  samplers:
    - [default, default, default, default]
  batch: LIGHT_DIR
  updaters: [DIRLIGHT]
  descriptors:
    writing: COLOR_ONLY
    depth:
      func: GREATER
      range: [1.0, 1.0]
      testing: YES
      clamping: NO
    scissor: DEFAULT
    viewport: DEFAULT
    stencil: NO
    triangle: DEFAULT
    blending: NO
    clearing: COLOR_ONLY