As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Is the use of namespaces as well as folders to organize code overkill?
Example:
Folder Structure:
Engine (Root)
--Audio
--Exceptions
--Game
--GFX
--Input
--Math
--Messages
--Physics
--Time
--[global headers]
All classes are contained in a [root]:: namespace to prevent collisions with std:: and third party code. The Math folder contains a header of some helper (free) functions contained in the [root]::Math:: namespace and Audio has some more helper (free) functions in the [root]::AudioHandler:: namespace.
Should I put the classes in each folder into a similarly describing namespace? (i.e. classes in the Physics folder would also be in the [root]::Physics:: namespace.)
Namespaces organise the logical interfaces, directories the "physical" files.
The more code within a single namespace, the more important it is that it's relatively stable and well-coordinated; if identifiers are volatile and uncoordinated you'll likely see conflicts as changes are merged. Based on your experience of or feel for such conflicts, you can choose your namespaces.
std:: is an obvious example of a very stable and well coordinated namespace, which means a lot of stuff can be successfully bundled into it. If you're working on a one-man project - all the way from libraries through application - you're more likely to cope with fewer namespaces too.
On the other hand if you have several global teams working independently - changing/adding identifiers constantly - then it's good to separate the code into namespaces. Further, if you have regular experiences that the obvious and desirable identifier to use in one system is already in use in another - that suggests namespaces too.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm doing a software to generate animations for algorithms. These algorithms are written in an interpreted language, near to C (more or less a C-oriented pseudocode). Thus, my program must interprets algorithms written in these language. Also, this language will be incremented all the time to support more and more features. The key issue here is to search an library allowing increase the language easily and making easy integrate different parsers in the same program. The app is written in C++ licensed under GPL.
A object-oriented parser is my target solution indeed. I need help to choose a good library with this purposes. Also it's desirable the library is multiplataform and available in official repositories of commons distributions: Ubuntu, Suse and so on.
Actually, I know more or less well the next two libraries/tools:
Flex/Bison++: Both are Flex/Bison wrappers that allow generate C++ code instead of C code, and choose a name for your class. Problems: if you install Flex/Bison++, Flex/Bison are overwritten. I don't want to complicate users if they want compile my code. Moreover, CMake fails search the version number of the library. This can be solved manually, but isn't elegant.
Boost.Spirit: It doesn't have the previous problems and match with all desirable features I described above. But, I've read it isn't fine to parse big languages and to solve grammar ambiguities. Moreover, the compilation times are enormous. But, I love it can compose grammars in a constructive manner. This is very important to make the code/language/programm extensible.
What is your recommendation?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Earlier, a friend of mine sent me a block of code over instant message. It took some working to hammer into place, because they had a series of custom types defined in a header they use in all their projects, just for shorthand - byte, ushort, uint, ulong, and so on.
I was about to chastise them for embedding such custom shorthand into their code, but... is it actually bad practice? Instant messaging is not the normal method for code sharing, and if I'd had the entire functioning project the header with the definitions would have come with it. The shorthand types are all intuitive, and often save typing, but on the other hand that might just lead to laziness.
Is there any kind of official verdict on this?
If the environment doesn't define the types you want to use, then why not define them yourself? Keeping all such definitions in a single header file helps to prevent inconsistencies. It also means you can base your definitions on the most appropriate types that do already exist, and easily update them if you port to a different platform or compiler.
I cannot see why anyone should consider this bad practice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As we all know, varScoping your ColdFusion code is an absolute must for any non-trivial project.
CF9 brings many enhancements to CFScript, such as being able to write entire CFC's in script, including component, function and property tags.
However varScoper won't work with cfScript defined functions/components. It just doesn't attempt to check functions declared in script.
The question is, what is everyone using for varscoping their cfScript based CFC's?
dave
VarScope is under an Apache licence, so is "open source". You could always touch base with the bloke in charge of it and see if he'd be interested in third-party updates to it, and perhaps you could make the changes yourself? It would certainly earn you community brownie points!
Not an entirely satisafactory answer, I know.
To answer your actual question: until CF has full CFScript coverage for the functionality we use (or are likely to want to use) in CFCs we won't implement any script-only CFCs. And for our tag-based ones we just use a tight coding standard and have code peer review before committing anything for release. Occasionally we run varscoper, but it does a less good job of finding problems than two sets of eyes do: varscoper does seem to come up with a lot of false positives.
Another consideration is that if you have 100% unit test coverage (yes, I know: who does?) then checking what's in the variables scope of a CFC after you've run your tests will show up any leaks into the variables scope.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is there a DI framework comparable to Google Guice? And what does Google use?
There is nothing as mature or standard as Guice in the C++ world. However, some people have put together simplistic implementations on their own. Here's a couple.
http://adam.younglogic.com/2008/07/dependency-injection-in-c/ (source for implementation is at the end of the post)
http://sourceforge.net/projects/qtioccontainer/ (requires Qt)
http://code.google.com/p/autumnframework/ (hasn't been touched since 2007)
http://programmaticallyspeaking.blogspot.com/2010/04/beautiful-dependency-injection-in-c.html (more of a description, really)
http://sourceforge.net/projects/cpp-resolver/ ("Alpha" quality)
You're unlikely to be satisfied by any of these.
If you really wanted to put in the effort to rally the world around a DI framework for C++, probably the way to go about it would be to make a proposal to the Boost guys.
I'm the author of wallaroo. It's actively developed and has the following features:
it's lightweight but powerful
its interface supports both C++11 and C++98 with boost
it's type safe
it doesn't need custom preprocessors / code generators
you can load classes defined in shared libraries
you can use a DSL syntax for object creation and wiring or
you can get object creation and wiring by parsing one or more xml / json file.
Any comment, suggestion or request are welcome.
There is a recent one that looks very interesting called Hypodermic, i haven't tested it but it looks pretty active
I am currently authoring one called sauce, whose design (and name) is directly inspired by guice. I still consider it alpha, but you may find it useful.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am wondering what directory structure are commonly used in development projects. I mean with the idea of facilitating builds, deploys release, and etc.
I recently used a Maven structure for a java project, but I am not sure it's the best structure for a non-maven driven project.
So, I have two questions: When you guys start new projects, what structure you use? And: What if you need to integrate two different languages, like for example java classes into a PHP application; PHP files are source files, web files, you you use a /src, /classes, webapps/php ? What are your choices in such scenarios.
As a note: I am wondering also what are you choices for directories names. I like the 3-letters names (src, lib, bin, web, img, css, xml, cfg) but what are your opinions about descriptive names like libraris, sources or htdocs/public_html ?
After a couple years working with different structures I recently found a structure that hols most variations for me:
/project_name (everything goes here)
/web (htdocs)
/img
/css
/app (usually some framework or sensitive code)
/lib (externa libs)
/vendor_1
/vendor_2
/tmp
/cache
/sql (sql scripts usually with maybe diagrams)
/scripts
/doc (usually an empty directory)
Although we don't use Maven, we use the Maven directory structure.
We've found that it accurately reflects the concepts we need (e.g. separation of deployment code from test code, code from data, installers from code). Also we figure that if someday we switched to Maven, most of our process would remain the same.
I just found a interesting document about Directory structures on Zend website:
http://framework.zend.com/wiki/display/ZFDEV/Choosing+Your+Application%27s+Directory+Layout
A 2011 update:
http://java.sun.com/blueprints/code/projectconventions.html