Eigen is an awesome algebra/matrix computation c++ library and I'm using it in a developing project. But someone told me not to use it because it depends on standard containers, which is doubtful to me. The reason not to use standard containers is complicated and we just ignore it for now. My question is, does eigen's implementation really depends on the standard containers? I've searched on the Eigen homepage but nothing found. Can anyone help me?
I would rather say no as there are only two very marginal use:
The first one is in IncompleteCholesky where std::vector and std::list are used to hold some temporary objects during the computation, not as member. This class is only used if a user explicitly uses it.
The second one is in SuperLUSupport module, which is a module to support a third library. Again, you cannot use accidentally!
The StlSupport module mentioned by Avi is just a helper module to ease the storage of Eigen's matrices within STL containers.
Yes, but a very little bit. You may not even need those parts, depending on your precise use. You can run a quick grep to see exactly what std:: containers are used and where. In 3.3.0, there is a std::vector member as well as a std::list<>::iterator in ./src/IterativeLinearSolvers/IncompleteCholesky.h, std::vectors are typically used as input for sparse matrices (SparseMatrix::setFromTriplets, although it really needs the iterators).
There is also the ./src/StlSupport/ directory, but I'm not sure that's what you don't want.
Hi
Recently in actionscript it has been made possible to create Classes at runtime. Thi seems quite cool, but I am perplexed thinking of a situation in which this might be useful. Anyone have any ideas?
First of all, the uses for this in ActionScript is limited. So start of understanding what it actually is, and how other languages use it.
See Self-modifying code on wiki:
http://en.m.wikipedia.org/wiki/Self-modifying_code
Also see Reflection:
http://en.m.wikipedia.org/wiki/Reflection_(computer_science)
As an example of how it might be useful, I'm currently working with genetic algorithms to modify code at runtime. This way I can test every permutation (varying initial values and methods) without having to create classes for them, with the added bonus of exporting a .swf only containing the winning permutation.
I was looking through someone's code one day and I was annoyed how they declared all their functions first and then later called them below. I guess I'm use to Visual Studio's automatically generated functions, that are made after you call them- and I was wondering, which way do you prefer? Or is there a standard on these kind of things?
I'm not sure what you mean by this. In C and C++, a function must be declared before it is called, otherwise the compiler won't know how to verify your arguments and return values.
I don't think it matters as the functions are all loaded into memory before execution begins. It's mostly a matter of style.
Personally I put miscellaneous functions that aren't part of a class definitions at the bottom of my code so it's easier to read.
That's just my $0.02 though.
Whatever Visual Studio do automatically can be considered a Microsoft standard. Not always the best standard, but a standard anyway =)
I've got a program where a lot of classes have really complicated configuration requirements. I've adopted the pattern of decentralizing the configuration and allowing each class to take and parse the command line/configuration file arguments in its c'tor and do whatever it needs with them. (These are very coarse-grained classes that are only instantiated a few times, so there is absolutely no performance issue here.) This avoids having to do shotgun surgery to plumb new options I add through all the levels they need to be passed through. It also avoids having to specify each configuration option in multiple places (where it's parsed and where it's used).
What are some advantages/disadvantages of this style of programming? It seems to reduce separation of concerns in that every class is now doing configuration stuff, and to make programs less self-documenting because what parameters a class takes becomes less explicit. OTOH, it seems to increase encapsulation in that it makes each class more self-contained because no other part of the program needs to know exactly what configuration parameters a class might need.
Regardless of the way you do it, you have several "modules" which compete for the same sequence of command-line arguments. There must be some cooperation so that the same command-line arguments can be processed by your classes without clashes.
By having each class implements the parsing, you simply make that cooperation implicit. There is no module dedicated to the cooperation between your classes. The problem becomes a matter of documentation rather than a matter of code. It is not bad but it may seductively appear as if the problem has simply "gone away". To be brief, this practice requires more discipline.
Also, it will make major overhauls of command-line argument syntax more difficult.
it seems to increase
encapsulation in that it makes each
class more self-contained because no
other part of the program needs to
know exactly what configuration
parameters a class might need.
If I understand what you're proposing, it really makes each class hide their dependencies.
The dependencies in this case may be simple (primitive), but if a class needs an username and password to function correctly, it should say so in its constructor. Otherwise, the class' callers need to look at the source code or documentation to use it.
In your object-oriented language, what guidelines do you follow for grouping classes into a single file? Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file? Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?
Personally, I suggest one class per file unless the secondary classes are private to the primary class in the file. For example, a nested class in C# would remain in the parent classes file, but utility classes that might be useful elsewhere get broken into their own file or even namespace.
The key is to understand your environment and where people will look for things. If there is an established methodology in place, think carefully before you upset it. If your coworkers expect that related, tightly bound classes will be in a single document, having to search for them could be annoying (although with modern IDEs it shouldn't be a problem).
An additional reason for breaking things into more files rather than less is version control. If you make a small change, it should change only a small file where possible. If you make a sweeping change, it is obvious looking at the logs because of all the files (and indirectly, classes) that were affected are noted.
I think best practices in all OO languages I have ever used is to have one class in one file. I believe some languages may require this but I am not sure of that fact. But I would say that one class per file, and the name of the file matching the name of the class (as well as the directory structure matching the package structure for the most part) is best-practice.
1 class = 2 files. An .h and a .c, you kids are so lucky :)
There is no hard and fast rule that must always be followed (unless a particular language enforces it). There are good reasons for having just one class, or having multiple classes in a file. And it does depend on the language.
In C# and Java people tend to stick to one file per class.
I'd say in C++ though I often put multiple classes in one file. Often those classes are small and very related. Eg. One class for each message in some communications protocol. In this case a file for each would mean a lot of files and actually make maintenance and reading of the code more difficult than if they were in one file.
In C++ the implementation of a class is separate from the class definition, so each class { /body/ } is smaller than in other language and that means classes are more conveniently sized for grouping together in one file.
In C++ if you're writing a library (eg the standard template library) , you can put all the classes in one file. Users only need to include the one header file and they get all the classes then, so its easier for them to work with.
There's a balance. The answer is whatever is most easy to comprehend and maintain. By default it makes sense to have one class per file, but there are plenty of cases when it's more practical to work with a related set of classes if they are defined in one file.
I put classes into the same file if they belong together, either for techinical or aesthetic reasons. For example, in an application that provides a plugin interface, the classes Plugin (base class for plugins) and PluginManager I would usually put together in the same file. However, if the file grows too big for my taste, I would split them into separate file.
I note that I write code mostly in Python at the moment, and this influences my design. Python is very flexible in how I get to divide stuff into modules, and has good tools for managing the name spaces of things. For example, I usually put all the code for an application in a Python module (a directory with __init__.py) and have the module import specific names from sub-modules. The API is then something like applib.PluginManager rather than applib.pluginstuff.PluginManager.
This makes it easy to move things around, which also allows me to not be so fussy when I am creating the design: I can always fix things later.
One class = one file. Always. Apart from when one class = multiple files in C#, or a class contains inner classes etc of course ;)
One per a file is our standard. The only exception is that for a class and it's typed collection we put those together.
Over time I've come to relize, that "small class" always tend to grow. And then you'll want to split them up, confusing everyone else on the team (and your self).
I try to keep one class per file (like most of the above), unless they are small classes. If there are a lot of them, I may split them into subjects otherwise. But usually I just keep them all in one file with code-folding in editors. For my private hacks, it just isn't worth the (minimal) effort to me.
One class per file seems to be the standard. This is the way that I usually do it as well.
There have been a few times where I've strayed away from this. Particularly when a smaller class is a member of another class. For example, when designing a data structure, I would likely implement a "node" class within the same file as the "bigstructure" class.
In your object-oriented language, what guidelines do you follow for grouping classes into a single file?
It depends. In team work I try to follow team standards; in solo work I tend more towards whatever-I-please.
In solo work, then ...
Do you always give each class a seperate file? Do you put tightly coupled classes together? Have you ever specified a couple of implementations of an interface in one file?
No. Sometimes. Yes.
Do you do it based on how many lines of code the implementation might be or how "cluttered" it might look to the user of the class? Or would the user prefer to have everything on one place?
It's mostly based on:
How easy is it to navigate? A huge long source file, with many classes, is more difficult.
How easy is it to edit? When editing multiple, short, related classes, it may be easier if they're all in one source file with a splitter than if they're in several source files, given that I run my text editor maximized showing one source file at a time.
I prefer 1 to 1 for classes unless the inner class will be entirely private.
Even then I usually break it out for ease of finding it and tracking changes in SVN.