02-11-2014 12:27 PM - edited 02-11-2014 12:37 PM
Okay I don't want to get in to a 'mines bigger then yours' argument or in this case smaller.
All I will say is that as someone who worked on the first ARM compilers, assemblers and linker I would probably take that bet.
[Edit] Oh I see you are comparing QML and C++ not our coding.
But as a case in point why in C++ add a function when you have already subclassed Container which has those functions in already?
Surely you can see it's unnecessarily adding code and therefore increasing memory use?
Also your class won't work in QML you're effectively saying you must use C++ at all times.
02-11-2014 12:44 PM - edited 02-11-2014 12:49 PM
Im comparing both.
Your suggestion is a good "quick and easy" solution for someone happy to use qml.
Even better would be to create a reusable component in qml, since something like a divider is likely to be needed again ad again.
Mine is good c++ solution. Its cleaner more robust, and reusable, but obviously only feasible if one wants to write in c++.
It certainly uses more (source) code than yours, but thats just one consideration when writing a project.
That certainly has nothing (simple) to do with memory usage. Im surprised that you think so. It can very easily happen that more (source) code uses less memory when compiled and executed. Qml is always comes with extra baggage that slows down and increases memory usage of an app. It one of the prices one pays for being able to do simple things "quickly and easily".
02-11-2014 12:48 PM
> But as a case in point why in C++ add a function when you have already subclassed Container which has those functions in already?
You mean "setColor" ?
Thats abstracting client code from the fact that Container is subclassed.
I could change my implementation to not subclassing Container, or eg containing a Container, and client code would not need to be changed
02-11-2014 12:59 PM
Sorry I don't want to drag this out but I disagree, what does your class have over the Container class apart from;
- Can't be used in QML
- Unnecessarily duplicates functions already present in the Container class
- Increases memory size from unnecessarily substituting Container class
Sorry IMHO even in a C++ only environment this class makes no sense.
Any way this is going way off topic so I'll leave it at that.
No doubt your C++ experience is far superior to mine so I'm probably missing something obvious.
02-11-2014 01:17 PM - edited 02-11-2014 01:23 PM
Yes I think its just best to summarise with saying that your suggestion should be preferred if using Qml (ideally modified by puttng the code into a custom component :
And mine is good suggestion if writing in C++.
There are good arguments for/against C++/Qml that would be more appropriate in a separate thread.
Memory consumption and execution speed speak clearly for c++ however.
> - Can't be used in QML
Agreed (well actually it can...C++ classes can be made available to Qml, but I wont go into that now. For this example it would be better to create a custom component in Qml as you suggested..unless one wanted it to be available to client code in both C++ and qml .. then this would be the way to go)
> Unnecessarily duplicates functions already present in the Container class
If you mean setColor, I think I explained this clearly. It protectes client code from changes in the implementation.
> - Increases memory size from unnecessarily substituting Container class
It doesnt increase memory (any more than using c++ inceases memory consumption over using c)
> Sorry IMHO even in a C++ only environment this class makes no sense.
It certainly does.
It makes client code simple and robust:
new tRpSep(Cont); // simple as that, anywhere client code needs a separator in any project
>> I bet the memory footprint is a lot smaller than yours ;-)
Id like to take this back. Ive no idea what your code in general looks like or how it behaves and I should have expressed myself more carefully. Sorry.
02-11-2014 04:15 PM
02-11-2014 05:49 PM
02-12-2014 05:21 AM - edited 02-12-2014 05:24 AM
Good point and thanks for mentioning it.
I had read this too and its better to play it safe as you do by not subclasing Container.
(1) I find the documentation unclear here. It could be saying "you shouldnt subclass Control directly (but its ok to subclass its descendents (eg Container)"
(2) I think its very unlikely that Blackberry will change anything that will cause code that has subclassed something like Container to then break (but still work when you contain/use it in eg a CustomControl). The only thing that springs to mind that would do this would be if they changed (signatures of) protected/private members. They would mess up their own code by doing so, so its much more likely theyd create new and/or overload functions instead. Even then theyd have to be careful not to break binary compatibility (which could happen even if you were only subclassing CustomControl). Most classes like Container dont define any private/protected members anywas so this is a non-isssue in this case.
I personaly feel its overly restrictive to ask (if thats waht this piece of documentation is actually saying..and if it is it should be unambiguous!) developers not to subclass most of the controls. Sure it leaves the library designers more room to change things later..but at a price.. there are some things that cant be done, or done as well at least, without subclassing, and can be quite a bit more effort..all members in the control you want to access from outside need to be proxied through the interface of the CustomControl.
Gererally however I just subclass Page (which is not a Control) and Container (which doesnt have new private/protected members), so like I said it doesnt matter. But in general I suppose your right to be safe and try to just subclass CustomControl. Maybe I should too.
BBSJdev : Thats exactly the kind of thing functions like setColor() in my class protect the client from..If I decided I did in fact want to subclass CustomControl instead, which then contained a Container * instead of being one, then the fact that clients had been written to access tRpSep::setColor (rather than Container:setBackground), would mean theyd be unaffected. Only my implementation of setColor would need to be modified
02-12-2014 06:04 AM
@p8 Sorry but I just see a number of problems with your implementation and a few statements you've made on C++ and memory footprint are just plain wrong. However if you are happy with it then let's just leave it at that as this is getting way off-topic.
02-12-2014 08:08 AM
curious to read this thread ;-)
from my POV:
using a Container, fill it with color, use height and padding, add some properties
and you have a perfect Divider you can re-use in all your apps
doesn't matter if you're doing this from C++ or QML
my 2 cts