Unrelated! (Source code section)

Pages: 1234
Jan 23, 2012 at 6:35pm
closed account (3hM2Nwbp)
Does anyone actually have non-trivial programs they'd like to put there?


I'd be willing to put up my linear barcode generation API (C++11), however I'm a firm believer in using 1 class per file, so the API is made up of around 30 files, not including the C++/CLI GUI. I'd be curious to see how the source code section would accommodate for projects made up of many files.

* Another thought would be a way to put up doxygen documentation, since all of my projects are meticulously documented and compatible with doxygen.
Last edited on Jan 23, 2012 at 6:38pm
Jan 24, 2012 at 4:35pm
@Luc Lieber,
I use 1 class/file and Doxygen comments too :P Except in C#, then I use xmldoc comments. I prefer Doxygen though.

I think it should be okay if you use lots of files - just put them in an archive..
Jan 25, 2012 at 12:05am
closed account (D80DSL3A)
@Catfish. Thanks for the report.

@Luc Lieber. Attaching a .zip file to the article also seems to be a good way to make numerous files available to the reader.
Jan 25, 2012 at 12:44am
I believe in one *.hpp file per class and the only time I have a corresponding *.cpp file is if there are static member variables. I pretty much define all functions as implicitly inline and let the compiler decide what's best - it sure keeps down the mess and management hassle with two separate files for the exact same thing. I would still use a ZIP though...
Jan 25, 2012 at 12:46am
^But then you missing most of the point of having separate files. By putting the implementation in the header file, if you change anything, all the files that include that have to be recompiled, even if it is not an interface change.
Jan 25, 2012 at 12:53am
^But then you are missing most of the point of having self-contained files. By putting the implementation in a source file the user of your library has to add an extra file to compile in their code rather than just #include the header.
Jan 25, 2012 at 1:14am
But then they don't have to recompile their entire program if your library changes some internal code that doesn't (and IMO shouldn't) affect their program.
Jan 25, 2012 at 2:13am
closed account (3hM2Nwbp)
Attaching a .zip file


If I were an end-user (the one that's reading the source code section), I'd prefer something like this ( http://docs.oracle.com/javase/1.5.0/docs/api/ ) as opposed to downloading a zip archive, pilfering through X files, and finding the documentation details that you need in the actual header / source code files.

That's actually my biggest beef with C/C++, documentation accessibility.

IIRC, doxygen even generates pages that contain the implementation code.
Last edited on Jan 25, 2012 at 2:15am
Jan 25, 2012 at 2:15am
In my opinion documentation should be external to prevent file bloating and deranged intellisense...I swear if I see one more long docstring covering up the code I am trying to read...
Jan 25, 2012 at 2:31am
closed account (3hM2Nwbp)
IMO, API end-users should NEVER need to read the source code. If they do, the person that wrote the project documentation has failed, big time.

For non-traditional end-users however, I can see your point. I speak of end-users in the fashion that they only need / care about the public interface.
Last edited on Jan 25, 2012 at 2:33am
Jan 25, 2012 at 2:52am
I do really like the java docs. I feel like c++ just doesn't have good documentation in general, which is probably another reason people tend to view it as a harder language.
Jan 25, 2012 at 5:40am
@Luc Lieber
LLVM would be one such library. And yes, I think they failed bigtime.

@ResidentBiscuit
Really? I haven't found that at all, but each to their own I guess.

-Albatross
Jan 25, 2012 at 10:32am
as opposed to [...] pilfering through X files [...]


WHAT.
Jan 25, 2012 at 3:05pm
@Albatross, yup. My university uses Java as its primary language so ir web exposed to it quite a bit. And I tend to have to do my own research and from I've seen, the Java docs are much more navagatable and put together it seems. But, that might also be because it has a larger standard library, so a lot of the info you need is one place and follows the same format.

But, I'm not hating on C++ here. I still much rather prefer it over Java for most tasks. I do like Java's built in GUI library though
Topic archived. No new replies allowed.
Pages: 1234