Re: [Canorus-devel] "Unresolvabe" design error CAFile / CAExport ?

[Reinhard K. <su...@we...>]

Matevž Jekovec schrieb:
> Hi Reinhard,
> 
> I looked at core/file.h and setStream() should not be "virtual" (I
> forgot to undeclare it as virtual when I wrote it, sorry). Stream stuff
> should be private to CAFile only. Otherwise everything works and seems
> fine to me. Can you be more specific about the problems in
> setStreamToFile() and exportDocument(). I didn't experience any crashes
> in exportDocument() yet...
> 

Hi Matevz,

Thanks for the prompt help. Thursday in train I found one possible reason
of the crashes which I fixed promptly. I haven't yet tried everything out
and also have other problems found but I'm getting forward.
In this case the solution was simply to allocate the temporary variable...
I still have some doubt about the virtual table so I will try out both
the abstract class I created and the base class to see if there is actually
a difference concerning exportDocument. I change setStreamToFile as well
to non-virtual.

One thing I'd have to add when working with an abstract class is all CAFile
methods being used from "outside" of CAExportDocument (and also in the base
class). These methods have call CAFile::setStreamToFile (f.e.) directly to
avoid multiple-inheritance ambiguity (something I hate about C++ - the not
direct support of abstract classes).

When export works I check in but not before as all depends on each other...

Regards,

Reinhard

> Regards.
> -Matevž
> 
> Reinhard Katzmann pravi:
>> Hi,
>>
>> I have several big issues with virtual function on the "abstrace" CAExport
>> class I use for accessing export method. It basically looks like this:
>>
>> CAExport *poExp; // abstract export instance
>> ...
>> if ( uiExportDialog->selectedFilter() == CAFileFormats::MIDI_FILTER ) {
>> 			CAMidiExport me;
>> 			poExp = &me;
>> } else if ( uiExportDialog->selectedFilter() == CAFileFormats::LILYPOND_FILTER) {
>> 			CALilyPondExport le;
>> 			poExp = ≤
>> } else
>> ...
>> poExp->setStreamToFile( s );
>> poExp->exportDocument( document() );
>> poExp->wait();
>>
>> This makes it easily possible to ass new exporters.
>> But I have a big problems with all virtual functions called from 
>> setStreamToFile, exportDocument!
>>
>> Now if I call CAFile::setStream() within setStreamToFile and the other methods
>> the "virtual" keyword makes no sense anymore becaus I don't call setStream 
>> inside an exporter implementing its own setStream.
>>
>> A similar problem seems to be in exportDocument() where start() crashes in
>> QMutex::lock() but I would have to study the source code first to be sure.
>> Here I'm unsure what to do as start() is no virtual function. Maybe calling
>> QThread::start() directly works but I'm not sure if it will work for virtual
>> functions called inside QThread. It might be something completely different
>> but it must be somehow related as it did not crash as long as I didn't use the
>> abstract poExp instance. Any ideas or hints in that direction would be very
>> welcome.
>>
>> Here is a technical article for a related problem but it seems to be a bit
>> different to ours (and the hierarchy is much simpler) but still related:
>> http://cataclysm.cx/2007/12/18/virtual-insanity/
>>
>> I think the main problem is that CAExport being a kind of abstract class is
>> based on CAFile being based on another class. So I decided for now to make
>> the following:
>> - create a real abstract class called CAAbsExport (cannot be initiated)
>> - make CAExport a base class from CAAbsExport
>> - base the exporters on the CAExport (no change here)
>> - use CAAbsExport *poExp; in the code to avoid virtual table problems
>>
>> it might be possible that I'm forced to remove CAFile as base class but
>> that is not yet decided. Anyway at the moment I do not intend to allow
>> setStream f.e. to be called via the abstract interface.
>> I will need probably till sunday until this is tested and rethought. If
>> you are faster on an implementation just write to the list.
>>
>> Regards,
>>
>> Reinhard
>>   
> 
> _______________________________________________
> Canorus-devel mailing list
> Can...@li...
> https://lists.berlios.de/mailman/listinfo/canorus-devel


-- 
Software-Engineer, Developer of User Interfaces
Project: Canorus - the next generation music score editor - 
http://canorus.berlios.de
GnuPG Public Key available on request