 |
.. (לתיקייה המכילה) | |
The compiler failed to compile the source file you supplied. What should I do? | |
| As of version 9 (asgn5.9.zip) and later, the source code compiles via g++ on T2,TX, CSD |
As I understand 'map' in C++ it's hashtable. Thus I don't understand why you call your solution "Naive": It uses STL and since HashTable works in O(1) (more or less) it is fine. | |
First, as far as I know std::map is usually implemented as a search tree.Second, when speaking about comparing performance, I don't mean complexity. I mean actual running time, so even if my soultion is O(1) there may be other solutions which are faster (I can think of one or two ways for organizing the type information which will beat even the fastest hash-table). You must bear in mind that all the parameters listed on the homework document are equally important. You don't have to foucs on achieving the highest speed: the other factors are just as important. Given that my solution uses hash tables (which are usually quite expensive in terms of memory consumption) it should not be too difficult to come up with a solutions which is at least better with respect to the memory factor. |
The clarifications/suggestions section of homework document states that a good solution is not based on "tricks". We tried to think of a solution which does not involve any tricks, and we could not find anything that is better than NaiveTypeManger. Is it possible that we are missing something? | |
|
Well, it seems that the definition of a trick is not very clear, thus creating some confusion. There is at least one solution which is based on an idea which may seem as a "trick" to some people. Thus, my advice is to completely ignore my recommendation about avoiding tricks. If you can't find a solution that is better than NaiveTypeManager just keep your mind open and try to attack the problem from a new angle . |
I see that your solution has to mapping: name2class and ptr2class. Do we need to have these data structures in our solution? | |
|
No. The data structures used by NaiveTypeManger.h are merely an implementation detail. You don't have to duplicate them in your solution if you find another way to implement the specifictions of ITypeManger |
The STL by SGI (which is refered to by the assignment) offers a hash-table mapping, which is not provided by standard C++ STL. | |
| Yes. when compiling the solutions I will have SGI's STL on the include path (so you don't have to add such files to your submission). |
The documentation of getClassName(), for example, says that "SVM ensures that ptr is a valid pointer". Does this mean that in the body of getClassName() I have to check that ptr is not null? | |
|
No. All the statements about "SVM ensures that..." mean that the code which calls the member functions of ITypeManager, must make sure that several condition are true before the call is carried out. This is in fact a list of pre-conditions that must be valid when the exeuction of the member function begins. Since the code that calls memeber functions of ITypeManager is not developed by you, it is NOT your responsibility to verify these pre-conditions. |
Do I have to use all sorts of advanced design techniques (e.g.: Design patterns, templates, STL, generic-frameworks,...)? | |
| No. This is not an assignment in a software design course. You can write your code in plain C style. |
Is it possible that the inheritance hierarchy in Serjio will have more than one root class? | |
| No. The class tree of Serjio always has a single root |
May we assume that you will write all "#inlude" s and "using namespace std;" in your 'main' file exactly like it was in the supplied files ? | |
| No. the files you are writing should contain all required #include-s |
Should we have an "include-guard" in our .h files (I.e.: start the .h file with: | |
| Yes |
We thouht of a solution that involves some ugly pointer arithmetics as well as c-style casts from void*. Is this acceptable? | |
| Yes. As I said earlier I don't mind if your code relies on plain C techniques. |
I have this line of code in my program | |
Here is the fixed line:typename Name2Class::const_iterator iter = name2class_.find(className);
|
I get warnings when compiling my program. Can I submit it in this status? | |
|
You can submit it, but you will loose some points. I will compile your code with g++ as well as MSVC++ Toolkit 2003. If both compilers will emit warnings then several points will be reduced. |
Quoting the faq, there's only one root for the class hierarchy. Do we have to verify that? | |
|
No. You don't have to verify the singularity of the the root class |
Just to be sure, whatever is under "SVM ensures that" doesn't have to be explicitly checked (including class uniqueness etc.) ? | |
| That's correct. Everything under "SVM ensures that" is checked by OTHER parts of the SVM (the parts that you are not writing) |
Regarding the "number of branches" parameter. Does it count bracnhes in the source code or the number of branches which occur during execution? | |
| This parameter counts the number of branches in the source code. It does not take into account how many times these branches are actually executed when the program runs |
Is it possible that the test program will try to do sophisticated hacks which may cause my code to crash? | |
|
No. The test program will always play by the book |
Are there any restrictions on the number of classes that the SVM can load? | |
|
Given that a computer has a final memory, It is possible to come up with the following bounds: (a) Max. Number of classes: 2^18 (b) Max. number of sub-classes for a class: 2^16 |