boost::filesystem -- "Aborted"
Hi, I am currently writing a gtkmm component which acts as a file browser, much like a small filemanager which can be embedded in gtkmm applications as a scrolled window. I have just rewritten the component to use the boost::filesystem classes instead of the C functions for interacting with the filesystem. However I am getting a strange error when I start my app: When iterating through a directory I suddenly get the message: Aborted. void FileBrowser::rebuild_file_list() { namespace boostfs = boost::filesystem; boostfs::path cur_path( m_cur_dir ); FileContainer tail; // m_files will first only contain directories, // while tail will contain only files m_files.clear(); try { boostfs::directory_iterator end; for( boostfs::directory_iterator dir( cur_path ); dir != end; ++dir ) { std::cout << (*dir).string() << std::endl; if( boostfs::is_directory( *dir ) ) m_files.push_back( *dir ); else tail.push_back( *dir ); } } catch( std::runtime_error & e ) { std::cerr << e.what() << std::endl; } m_files.sort( SortedByName() ); tail.sort( SortedByName() ); drx::list_concat( m_files, tail ); } OUTPUT: [...] /home/mkay/.acrobat /home/mkay/.synce /home/mkay/.gimp-2.0 /home/mkay/.fonts /home/mkay/.designerrctb2 /home/mkay/.eclipse /home/mkay/.gftp /home/mkay/.ntrc_2 /home/mkay/.DCOPserver_anthrax__0 /home/mkay/.DCOPserver_anthrax_:0 /home/mkay/.kpackage /home/mkay/.fonts.conf /home/mkay/.xscreensaver /home/mkay/xdefaults_old /home/mkay/.reslisarc /home/mkay/.aMule /home/mkay/.gtkrc Aborted At this point the application exits. Any idea what is causing this? Thanks in advance, Matthias
matthias wrote:
However I am getting a strange error when I start my app: When iterating through a directory I suddenly get the message: Aborted.
Most likely, an exception is thrown but is never caught. I suggest you wrap the entire function in a try/catch block and print the caught exception. - Volodya
Vladimir Prus <ghost <at> cs.msu.su> writes:
matthias wrote:
However I am getting a strange error when I start my app: When iterating through a directory I suddenly get the message: Aborted.
Most likely, an exception is thrown but is never caught. I suggest you wrap the entire function in a try/catch block and print the caught exception.
- Volodya
I found the error in the meantime by divide and conquer. It wasn't the function I posted which caused it, my apologies. I called boost::filesystem::file_size without checking if I am actually working on a "file" (at least in the boost::filesystem terminology) in some other function. This caused an exeption to be thrown. Frankly, I don't think this behaviour of file_size is appropriate. In UNIX, for example, directories are files too. Therefore, file_size should return 0 when called on a directory because it's not really an exceptional situation to call file_size on a directory (which, as said above, often is a file). Any comments? Best regards, Matthias
Hi, how can I expand my C++ class by adding a new contructor with PyLong as an parameter without changing my C++ Class. Is it possible? Benjamin
On Mon, 2005-01-31 at 14:24 +0100, Benjamin Schmeling wrote:
Hi, how can I expand my C++ class by adding a new contructor with PyLong as an parameter without changing my C++ Class. Is it possible?
Yes, it is. See libs/python/test/injected.{cpp,py} in the source package, and the documentation for make_constructor in the reference manual (its under "Function Invocation and Creation"). HTH, -Jonathan
Benjamin Schmeling wrote:
Hi, how can I expand my C++ class by adding a new contructor with PyLong as an parameter without changing my C++ Class. Is it possible?
I found out that if I define a function: void consructor(_object* a,long_ l){ } and overload the __init__ by .def("__init__", constructor) my constructor function is called. Now I have the problem that I don't know how to handle _object* and to realize my constructor. Benjamin
On 1/31/05 5:00 AM, "matthias" <matthias@digitalraid.com> wrote: [SNIP]
I found the error in the meantime by divide and conquer. It wasn't the function I posted which caused it, my apologies. I called boost::filesystem::file_size without checking if I am actually working on a "file" (at least in the boost::filesystem terminology) in some other function. This caused an exeption to be thrown.
Frankly, I don't think this behaviour of file_size is appropriate. In UNIX, for example, directories are files too. Therefore, file_size should return 0 when called on a directory because it's not really an exceptional situation to call file_size on a directory (which, as said above, often is a file).
Any comments?
Don't forget new-wave file-systems where directories can contain data. (In that case, a file is just a directory that has file-nesting disabled.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (5)
-
Benjamin Schmeling -
Daryle Walker -
Jonathan Brandmeyer -
matthias -
Vladimir Prus