I think the Portland Project from, is a great idea and
everyone should be supporting it in their applications.

I’ve just created a very small C++ wrapper (libxdgmm) for accessing XDG more easily. To use it, you need libxdgmm.h and libxdgmm.cpp. Just add these to your project and then use them like so:

#include <libxdgmm/libxdg.h>
int main(int argc, char** argv)
  if (!xdg::IsInstalled()) std::cout<<"XDG is not installed"<<std::endl;
  else {
    std::string data;
    std::string config;
    // Obviously these have to exist to work.  You can translate the error code returned by calling xdg::GetOpenErrorString(int result);
  return EXIT_SUCCESS;

I still have to wrap some of the other functionality, such as XDG_DESKTOP_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, desktop-file-utils, xdg-desktop-menu and xdg-desktop-icon etc. I will wrap these as I need them (Or at special request). I don’t think I will be supporting xdg-screensaver or xdg-mime as I don’t have a use for them right now.

C++0x compiling with gcc

Gcc has some early support for C++0x. You can enable it with -std=c++0x (Note: You can already use Boost without enabling this flag). Enabling this flag broke boost::filesystem for me, but this has already been reported and fixed:


661	661	    inline bool is_empty( const path & ph ) 
662	 	-      { return is_empty<path>( ph ); } 
 	662	+      { return boost::filesystem::is_empty<path>( ph ); } 
663	663	    inline bool is_empty( const wpath & ph ) 
664	 	-      { return is_empty<wpath>( ph ); } 
 	664	+      { return boost::filesystem::is_empty<wpath>( ph ); }

The full patch is much longer, but this seemed to be all I needed to get it to work (Note: You will need to su and then gedit /usr/include/boost/filesystem/operations.hpp).

Anyway, you will want to test it out:

enum A
enum B
void Test()
  B b = 0;
  b = true;
  b = 1;
  b = A_1;
  b = A::A_1;
  b = B_1;
  b = B::B_1;

The only lines of Test that compile are “b = B_1;” and “b = B::B_1;”. Under C++98/C++03 this would 100% compile, which could easily create bugs where the code compiles but may not be what is intended. We can also get slightly tighter restrictions again, by defining “enum B” as “enum class B”. This restricts the correct lines of Test to “b = B::B_1”, meaning the enum must be fully qualified which should lead to less ambiguous code. In a real situation you will also want to actually initialise b to a decent value initially as well: “B b = B::B_1” for example.

Anyway, this is a pretty trivial example, just a tidy up of the language really, you will want to delve deeper. Variadic templates, Initializer lists, Lambda expressions and closures, New character types, Unicode string literals, Raw string literals and Universal character name literals look good. Extern templates, Inheriting constructors, nullptr, __func__, C99 preprocessor, long long, Extended integral types can’t get here soon enough.