Unrelated! (Source code section)
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
@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..
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..
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.
@Luc Lieber. Attaching a .zip file to the article also seems to be a good way to make numerous files available to the reader.
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...
^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.
^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.
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.
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
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...
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.
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
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.
@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
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
@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
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.