2006/9/13, Pavel Pervov <[EMAIL PROTECTED]>:
> Not sure C++ "friend"s are good design.
Umm, what is wrong with friends?
It's sort of breaking incapsulation ideology. Nothing more. :)
<SNIP>
For example, private members of Method _parse_exceptions()
_parse_local_vars(), _parse_line_numbers(), _parse_code() actually
should be public members of respective entities.
They should not. Nobody but Method knows nothing about local variable tables
and line numbers stored in it. It is again breaking incapsulation.
Those entities in
turn need not be declared in Class.h, as Method incapsulates pointers
to such members.
Yes, they may be declared inside class Method.
BTW, this would also allow us to economize on size of Method
instances, after we sort out such entities - e.g. instead of keeping
bunch of Code-related members (~10 members) directly, store just 1
pointer and win memory on absract and interface methods, etc. Of
course care should be taken to not incur performance penalty for extra
indirection, but you see the approach.
What do you think?
This approach may be used in struct Class for array classes. Not sure one
level of indirection in memory access is worth saved memory. I'm afraid we
won't save more than 1MB of memory with this trick, but surely will have
performance penalty.
If something should be
improved, ByteReader can be extended to provide more advanced "format
extraction" methods than it has now.
I don't think so - if we follow the selected approach consistently,
ByteReader hardly needs to provide more... Please correct me if you
have concrete ideas.
Yes, you are right here. I looked through ByteReader and found nothing to
improve.
The problem is not parsing code itself, you know - just when someone
does a trivial fix in LocalVarTable parsing procedure, I have to
recompile the whole VM + GC (and maybe even JIT)! Where are you, vm
modularity ;)
No, you don't. If someone change "LocalVarTable parsing procedure" you only
need to recompile Class_File_Loader.cpp. ;)
But if that one happen to change something in Class.h, you'll recompile 97
files in VM. Recompilation of GCV4 is due to erroneous direct inclusion of
Class.h into some of GCV4 headers. GCV41 does not have this peculiarity.
Well, for the parsing code - I do not appreciate that JNI-like coding
pattern "If (troubles) {RAISE_FAILURE(); return false;}" used
everywhere in Class_File_Loader.cpp, would prefer using exceptions -
but that is another story.
Yes, this is absolutely another story. I would not advise using C++
exceptions in VM. We'll have all sorts of compatibility problems and, also,
performance degradation, if we start to.
Best regards,
Pavel.
<SNIP>
