Practice Repositories
Pages: 12
closed account (S6k9GNh0)
I'd like to open up a repository of code or two for a base project where everyone who is a member of cplusplus.com can send patches. This makes our community possibly more productive and helps those who want more realistic practice rather than cheesy exercises. I have a few things in mind but I'd like some ideas before I start devoting to it. Also, repo software to use is also in question.
closed account (3hM2Nwbp)
Some things just came to mind real quick - note some might be personal opinions.
A few things to put in the fore-front of any projects to be:
* A standardized (header) commenting style
* A standard forcing the use of the RAII idiom
* A standard forbidding the use of deprecated methods
* A list of platforms to support
* A list of compilers to support ( including which C++ standard [C99, C03, C1x])
* A list of libraries that may be utilized
* A single configuration header for each project (each contributor doesn't need their own)
* A way of peer-reviewing code before it's committed.
Might throw in a few others as they come to me.
A few things to put in the fore-front of any projects to be:
* A standardized (header) commenting style
* A standard forcing the use of the RAII idiom
* A standard forbidding the use of deprecated methods
* A list of platforms to support
* A list of compilers to support ( including which C++ standard [C99, C03, C1x])
* A list of libraries that may be utilized
* A single configuration header for each project (each contributor doesn't need their own)
* A way of peer-reviewing code before it's committed.
Might throw in a few others as they come to me.
Last edited on
closed account (S6k9GNh0)
I planned on this as there was going to be obvious conflict. I'm still thinking about it. I'm writing everything down and I'll post it here soon, depending on variable feedback.
@xander337, what is zydrate o.0?
@xander337, what is zydrate o.0?
Last edited on
closed account (z05DSL3A)
I would like suggest Git and GitHub
http://en.wikipedia.org/wiki/Git_(software)
http://en.wikipedia.org/wiki/GitHub
http://en.wikipedia.org/wiki/Git_(software)
http://en.wikipedia.org/wiki/GitHub
Last edited on
I second using Git/GitHub.
1. Good idea. I nominate Doxygen comments. Personally I always use C-style comments but I don't think it matters if someone wants to use only C++-style comments, or mix the two. That doesn't need to be standardized.
2. Fine by me.
3. Yes.
4. Agreed, though I think it would be most beneficial if we strived to support all platforms. At the very least we should support Windows, Mac OS and Linux; those make up near-enough 100% of the market.
5. Agreed. I nominate g++ and vc++ as those seem to be the most common. I don't know about vc++ but the following options should be included for g++ IMO: "-Wall -Wextra -pedantic". As for the standard, I guess whatever the current most recent standard that is fully supported by all of our compilers.
6. Agreed
7. This is an excellent idea. We could set up a simple website where people can submit patches, and they only get included if, say, 3 senior users give them a positive review. I could probably write the back-end code (handling logging in and such) but I suck at web design, so if someone better wants to volunteer their talents, that would be good.
I also recommend we standardise coding style. I don't know whether it is a better idea to standardise coding style for the whole project (everyone uses Allman style or K&R style or whatever), or just within files (copy the style of the file's original author). I'm in favour of the former, with Allman style (this is the style used in ANSI documentation so it makes sense to use) or K&R/Linux style (I prefer this but Allman style is a more logical choice).
Also, I think we should have our source tree properly organised. I hate opening the source of a program to find a bunch of source and header files with no structure. The project directory should have a "src" (or "Src" or "Source") folder, an "include" (or "Include") folder and a "bin" (or "Bin" or "Binaries" or "Release") folder.
Another thing that is important but hasn't been mentioned is that everything should be in English. I usually use US English spelling (e.g.
| Luc Lieber wrote: |
|---|
| * A standardized (header) commenting style * A standard forcing the use of the RAII idiom * A standard forbidding the use of deprecated methods * A list of platforms to support * A list of compilers to support ( including which C++ standard [C99, C03, C1x]) * A list of libraries that may be utilized * A single configuration header for each project (each contributor doesn't need their own) * A way of peer-reviewing code before it's committed. |
1. Good idea. I nominate Doxygen comments. Personally I always use C-style comments but I don't think it matters if someone wants to use only C++-style comments, or mix the two. That doesn't need to be standardized.
2. Fine by me.
3. Yes.
4. Agreed, though I think it would be most beneficial if we strived to support all platforms. At the very least we should support Windows, Mac OS and Linux; those make up near-enough 100% of the market.
5. Agreed. I nominate g++ and vc++ as those seem to be the most common. I don't know about vc++ but the following options should be included for g++ IMO: "-Wall -Wextra -pedantic". As for the standard, I guess whatever the current most recent standard that is fully supported by all of our compilers.
6. Agreed
7. This is an excellent idea. We could set up a simple website where people can submit patches, and they only get included if, say, 3 senior users give them a positive review. I could probably write the back-end code (handling logging in and such) but I suck at web design, so if someone better wants to volunteer their talents, that would be good.
I also recommend we standardise coding style. I don't know whether it is a better idea to standardise coding style for the whole project (everyone uses Allman style or K&R style or whatever), or just within files (copy the style of the file's original author). I'm in favour of the former, with Allman style (this is the style used in ANSI documentation so it makes sense to use) or K&R/Linux style (I prefer this but Allman style is a more logical choice).
Also, I think we should have our source tree properly organised. I hate opening the source of a program to find a bunch of source and header files with no structure. The project directory should have a "src" (or "Src" or "Source") folder, an "include" (or "Include") folder and a "bin" (or "Bin" or "Binaries" or "Release") folder.
Another thing that is important but hasn't been mentioned is that everything should be in English. I usually use US English spelling (e.g.
struct color) for code and British English for comments (e.g. /* Represents a colour (RGBA) */). I propose that we use US English for code and whatever dialect of English you want for comments. Slang and jargon should be avoided, though.
Last edited on
closed account (S6k9GNh0)
1. I also think Doxygen is the best option. Easy documentation tool.
2. RAII concepts will be enforced.
3. Deprecated functions will not be used. However, whatever library or API we use, we will use the stable version of these functions, not deprecated nor unstable functions.
4. I think we should support the three main platforms, Windows, Mac OS, Linux. However, the code will be organized in such a way (for whatever project we use) that we can add implementations to other platforms if wanted.
5. The most portable compiler currently is gcc/g++. As a result, this is the only compiler that is required to be compatible with. However, most code that is compiler specific code should be looked down upon. Including this, most popular libraries compile with both g++/vc++/many others. As a result, natural compatibility with multiple compilers should come about.
6. I think Boost could be utilized but even _this_ is debatable. Some libraries may also be project specific (such as compression libraries, etc.). I'll need some more suggestions on this.
7. This should go along with whatever compilation system we use, whether it be cmake or whatever. I'm still kinda lost on what to do here as there isn't really any perfect compilation system. Even make itself has portability problems.
8. Peer Review is required. I would not do this otherwise. This is a learning experience and everything as a result will be judged to some extent. If we are to be productive, there must be a way for us to prevent counter-productive ideas and code.
9. As far as coding style, I don't care. We all have different styles, etc. However, whatever style you use is required to be easily readable, clean, and common. I do not think we need some radical style of coding requiring plenty of whitespace or perhaps not enough.
10. The English language should be used in all cases, including comments (unless self-noted comments).
11. All source and files that need to be compiled or are required to have to compile something will be held in a folder within the project base directory named "src". All interfacing header files will be held in "include". All external libraries, binary or source, will be held in "extlib". All compiled binaries resulting from our project will be held in "bin". All project files or files used in a compilation system will be held in the base directory (although this should be natural).
I'm still lacking on project ideas. I want to avoid networking projects at first. I was thinking back on some of the suggestions from the Logic Warz topic. Although this would be challenging and fun for most, there's a lot of conflictual ideas there. I'm not sure what the dividing line should be.
2. RAII concepts will be enforced.
3. Deprecated functions will not be used. However, whatever library or API we use, we will use the stable version of these functions, not deprecated nor unstable functions.
4. I think we should support the three main platforms, Windows, Mac OS, Linux. However, the code will be organized in such a way (for whatever project we use) that we can add implementations to other platforms if wanted.
5. The most portable compiler currently is gcc/g++. As a result, this is the only compiler that is required to be compatible with. However, most code that is compiler specific code should be looked down upon. Including this, most popular libraries compile with both g++/vc++/many others. As a result, natural compatibility with multiple compilers should come about.
6. I think Boost could be utilized but even _this_ is debatable. Some libraries may also be project specific (such as compression libraries, etc.). I'll need some more suggestions on this.
7. This should go along with whatever compilation system we use, whether it be cmake or whatever. I'm still kinda lost on what to do here as there isn't really any perfect compilation system. Even make itself has portability problems.
8. Peer Review is required. I would not do this otherwise. This is a learning experience and everything as a result will be judged to some extent. If we are to be productive, there must be a way for us to prevent counter-productive ideas and code.
9. As far as coding style, I don't care. We all have different styles, etc. However, whatever style you use is required to be easily readable, clean, and common. I do not think we need some radical style of coding requiring plenty of whitespace or perhaps not enough.
10. The English language should be used in all cases, including comments (unless self-noted comments).
11. All source and files that need to be compiled or are required to have to compile something will be held in a folder within the project base directory named "src". All interfacing header files will be held in "include". All external libraries, binary or source, will be held in "extlib". All compiled binaries resulting from our project will be held in "bin". All project files or files used in a compilation system will be held in the base directory (although this should be natural).
I'm still lacking on project ideas. I want to avoid networking projects at first. I was thinking back on some of the suggestions from the Logic Warz topic. Although this would be challenging and fun for most, there's a lot of conflictual ideas there. I'm not sure what the dividing line should be.
Last edited on
closed account (S6k9GNh0)
Hmm... give your feedback on the license and I'll choose highest vote. I've generally never even provided a license with my project since I often don't care what you do with whatever I produce (unless the project is serious, in which I do not make the source public).
However, (as I'm not familiar with names), I'll probably vote for WTFPL. Although, I've seen various cases on which people will take code, claim it as there own, etc. Actually, this has happened to me T.T and various other communities I've been with. :/ Now you'll say you don't care but it does get incredibly annoying, especially if we create anything nice.
However, (as I'm not familiar with names), I'll probably vote for WTFPL. Although, I've seen various cases on which people will take code, claim it as there own, etc. Actually, this has happened to me T.T and various other communities I've been with. :/ Now you'll say you don't care but it does get incredibly annoying, especially if we create anything nice.
Last edited on
closed account (S6k9GNh0)
Perhaps a small game or perhaps a server or client for something (despite my will to wish to avoid networking at first as their are simply too many conflicting ways to accomplish a networking task...)?
I vote for the three-clause FreeBSD license. If the majority go with two-clause, however, count my vote as for that.
Maybe we could come up with a library of easy-to-use classes for common tasks (i.e. arbitrary precision decimals, networking classes, etc.)?
-Albatross
Maybe we could come up with a library of easy-to-use classes for common tasks (i.e. arbitrary precision decimals, networking classes, etc.)?
-Albatross
closed account (S6k9GNh0)
But there's already too many networking libraries >.>! Another surface for conflict.
There's a utility libraries made for just about everything. There's generally not enough code to utilize those utility libraries though. I just think it'd be less "productive". However, if everyone feels that we should start with a networking utility library, so be it :P.
If we don't decide on anything, I'll choose something, and start the repository up regardless.
EDIT: What is "arbitrary precision decimals"? Never heard of such terminology...
EDIT 2: Friend suggests a project that creates an alternative to X.org.... I can't tell whether to laugh or cry.
There's a utility libraries made for just about everything. There's generally not enough code to utilize those utility libraries though. I just think it'd be less "productive". However, if everyone feels that we should start with a networking utility library, so be it :P.
If we don't decide on anything, I'll choose something, and start the repository up regardless.
EDIT: What is "arbitrary precision decimals"? Never heard of such terminology...
EDIT 2: Friend suggests a project that creates an alternative to X.org.... I can't tell whether to laugh or cry.
Last edited on
closed account (3hM2Nwbp)
Oh man...C++ is turning into a "There's a class for that!" language. :-\
Really though, pretty much everything useful has already been done.
*Edit - The second to last project that I made was a heavily templated networking library.
*The last project I did in C++ was a barcode rendering library.
They're both technically not my property anymore, so I can't contribute any of the source code that I may or may not still have.
Edit2 - The only other project that I can think of would be a ZIP library in proper C++.
Really though, pretty much everything useful has already been done.
*Edit - The second to last project that I made was a heavily templated networking library.
*The last project I did in C++ was a barcode rendering library.
They're both technically not my property anymore, so I can't contribute any of the source code that I may or may not still have.
Edit2 - The only other project that I can think of would be a ZIP library in proper C++.
Last edited on
closed account (S6k9GNh0)
file archive manager sounds awesome actually as an alternative to something like 7zip, winrar, or something.... I vote for that.
closed account (3hM2Nwbp)
I was thinking more along the lines of library code as in:
extract files/directories
compress files/directories
extract to memory (stream?)
search compressed directory
etc.
Another useful project would be dealing with compressed image formats. It's been a long while since I've looked, but the only libraries that I saw were either in C or a C++ wrapper (which still required compiling the deprecated C library under the hood.) neither of which should really compile/link correctly on a modern compiler.
Me and GUI's don't get along (unless I'm the user!)
extract files/directories
compress files/directories
extract to memory (stream?)
search compressed directory
etc.
Another useful project would be dealing with compressed image formats. It's been a long while since I've looked, but the only libraries that I saw were either in C or a C++ wrapper (which still required compiling the deprecated C library under the hood.) neither of which should really compile/link correctly on a modern compiler.
Me and GUI's don't get along (unless I'm the user!)
Last edited on
| computerequip wrote: |
|---|
| What is "arbitrary precision decimals"? |
Something like GMP, I believe. Basically for arithmetical computations without rounding error or fixed numbers of significant figures.
EDIT: A compression library would be pretty cool. Which algorithm did you have in mind?
Last edited on
I think an archiver + compression library is a great idea.
The compression library should support a variety of commonly used archive formats and algorithms - perhaps even some more obscure ones (PAQ, anyone?). The archiver can then internally use the library to do its work.
I think this is a good idea because while there is already a pretty good archiver for Windows (7-zip), I'm not satisfied with the current situation under Linux. While in Gnome, you can easily compress files using the file manager, you have no configuration options such as compression levels or control over the algorithm used (e.g. a choice between LZMA or PPMd for 7z).
So an easy-to-use cross-platform archiver that integrates nicely into file managers while giving users who need it configuration options is something the world still needs.
The compression library should support a variety of commonly used archive formats and algorithms - perhaps even some more obscure ones (PAQ, anyone?). The archiver can then internally use the library to do its work.
I think this is a good idea because while there is already a pretty good archiver for Windows (7-zip), I'm not satisfied with the current situation under Linux. While in Gnome, you can easily compress files using the file manager, you have no configuration options such as compression levels or control over the algorithm used (e.g. a choice between LZMA or PPMd for 7z).
So an easy-to-use cross-platform archiver that integrates nicely into file managers while giving users who need it configuration options is something the world still needs.
Pages: 12