Hello Viktor
Viktor Szakáts wrote: > > I see you've chosen to use a unified release function option. > > This is quite bad IMO. This means that every application, even > the smallest and simplest one will have linked in code for > 59 (!) QT objects whether needed or not. This means you have > to say goodbye to modularity and granularity when using QT in > Harbour. This probably will get worse as QT evolves and get > more objects by time, and every QT apps will just grow > automatically. Not to mention the extra time and memory needs > of the container object you must now use. I understand there > are many objects in a typical QT app, and this way their > number is just doubled. Which means double number of memory > allocations and freeing and an extra structure in memory > for every object. > Just hold on. Your point is valid. For that to happen we need more insght how Qt works. This is first step in that direction. First I have to get rid of memory consumption. Next I will go for modularity. I wll explain why that could not been achieved so far. For sure final result will be far superior. OR can you suggest the skeleton of modularity in this scenario ? Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-12718--trunk-harbour-tp25918755p25921916.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
