Improvements

[IWishIKnew]

I have just released a program that I would like suggestions on:

https://github.com/BeenEncoded/filesystem-macro-program

Anything that you thnk could be done better?

If you want to contribute, you may.

[10X9216C]

Personally i would avoid spaces in folder names, they can be annoying to type in command line and such. Think the standard is "src" for source files. Not that big of an issue, if that's your preference, it is fine.

[BHX]

There is no standard, but common preference is src obj and bin for directory names.

[10X9216C]

It is standard for linux kernel.

[NoXzema]

I don't believe it is... would you mind posting something that would convince me otherwise?

[Lachlan Easton]

mind posting something that would convince me otherwise?

Best I could find http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (ctrl-f src)
on-topic Edit:
As for the file sys program, is it kind of like a shell emulator? I haven't tried it out yet, I've just browsed some of the source. Maybe put a short user guide in the readme with a few examples. As far as what I've read of the code there isn't anything jumping out and scaring me, though what's with all the

catch(...)
{
   throw;
}

s everywhere? (I say everywhere, but they've only shown up in one file so far) They're redundant and make the code harder to read. Are they just preparation for when you do want to handle exceptions?
Also I think you could probably reorganize your folders a bit better. There's a folder with only one file and a few with only two. Personally I'd look at how I could better group related files.

[BHX]

You are referring to the Filesystem Hierarchy Standard created (well may have existed before that, but was definitely copyrighted) in 1994 for UNIX-like OSs by the Free Standards Group. That is a *nix specific standard that some take and adopt parts of that standard for projects, but when it comes to directory naming for personal projects there is no standard.

This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems.

[EDIT]
Hmm...Lachlan's link says Linux Foundation, but I found another link that says Free Standards Group. Either way, LF or FSG, still doesn't take away from the fact that there is no standard for directory naming in personal projects. It is the preference of the programmer or team lead to decide that.

[IWishIKnew]

Lachlan Easton said\:

What's with all the try-catch statements?

I believe you're referring to the filesystem class. That is so that if somthing is thrown by boost, it referrs the user to the namespace instead of... well... boost.

myesolar said:

Personally i would avoid spaces in folder names...

Well, the build system is CMake, so if you use the provided CMakeLists.txt it doesn't actually matter. I will remember that, though, and take it into consideration in the future.

Lachlan Easton said\:

...is it kind of like a shell emulator?

You're not too far off. Using that code, you could definitely make a shell, but that's not what it's for. I included documentation on all of the major objects, including the command_class. Take a look at it and see what it's for. I basically tried to design it to be as extensible as I could in anticipation for future additions I plan to implement.

[helios]

BHX: It's the same deal as with code indentation. No one can force you to use a particular style or to use it consistently, but people are still right to get annoyed if you right-justify the code.

[10X9216C]

BHX wrote:

the fact that there is no standard for directory naming in personal projects. It is the preference of the programmer or team lead to decide that.

There is no standard for the extension a header or source file needs to take, but i'm pretty sure if you use "cpp" for headers and "h" for source files no one will end up using your code :).

[NoXzema]

Actually, there are various projects that have funky extensions for filenames. DMD from D uses .c for C++. I used to work on a project that would include .c files.

As long as the people implementing the project understand what it means, then it hardly matters. The main problem with poor filename extensions is that an IDE won't pick up on it automatically (or think it's a different type of language).

[helios]

I used to work on a project that would include .c files.

That's not so unusual, particularly for automatically generated sources.

[BHX]

helios wrote:

BHX: It's the same deal as with code indentation. No one can force you to use a particular style or to use it consistently, but people are still right to get annoyed if you right-justify the code.

True, but I wasn't correcting him for getting annoyed, I was correcting him for saying there was a standard when there isn't.

myesolar wrote:

There is no standard for the extension a header or source file needs to take, but i'm pretty sure if you use "cpp" for headers and "h" for source files no one will end up using your code :).

Again, for personal projects you can name the files whatever you want, but when it comes to the tools you run into problems. Most compilers will have nothing to do with it. Just tested your claim under Code::Blocks, Geany, and command line all with GNU G++ and had different outcomes for each one. I did the hello world example, but did as you claimed a programmer could and named it hello.h and behold it didn't do anything. C::B continually tells you nothing was built yet and asks if you want to build it. Geany says it can't find iostream: no such file or directory. Command line, created a file, but nothing that can be executed.

Also, no one would use your code if you flip the header and source files around because it makes you look like you are an incompetent programmer or just trolling those interested in using your program.

[helios]

There is a standard. It's just not a de jure standard.

[BHX]

In my mind, it is either or. It is either a recognized standard (like the Filesystem Hierarchy Standard, C++ Standard, etc.) or it is just a widely accepted and used preference.