|
|
Home » Community » Coffee corner » Basic questions about u++
|
|
|
Re: Basic questions about u++ [message #23301 is a reply to message #23298] |
Wed, 07 October 2009 19:14 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
irtech wrote on Wed, 07 October 2009 12:47 |
mrjt wrote on Wed, 07 October 2009 18:14 |
By wrapping the new/delete calls in an object (one that has already been thoughly tested) you are able to utilise C++ inbuilt destruction mechanics and avoid the error-prone call to delete. There isn't any 'magic' going on outside of using templates in a clever way
As far as I'm concerned the Upp memory management philosophy is to never use new/delete. There is almost always a better way .
|
Ok thanks with your explanation and what I've read in overview now I understood the resource management philosophy of U++!
except one thing !
Ok your example is about a simple int but hw about a big object like a class? Then you certainly need copy constructor which seems to be the motive not to use stdlib.
|
Actually, in most cases, you do NOT need copy constructor.
Quote: |
I mean for example I want to specifically copy value of a sibling object when copy constructor is called or I want to increment a variable inside a class inside copy constructor so I know how many times it has been copied.
|
Well, you have 3 kinds of entities:
- "object" (I lack better word) classes like File, Window etc... These usually do not have copy.
- "value" types like int, String, Color etc... These usually have full deep copy semantics
- and, U++ specific "containers". These act as sort of structural glue binding everything together.
And these containers, to workaround possibly missing copy contructors in cointained objects, have so called "pick transfer semantics":
http://www.ultimatepp.org/srcdoc$Core$pick_$en-us.html
which is the most "alien" thing in U++.
In reality, we could probably even live without pick, it is sort of similar in importance to "break" statement in C(++/#)/Java. But it makes live easier.
Mirek
[Updated on: Wed, 07 October 2009 19:14] Report message to a moderator
|
|
|
Re: Basic questions about u++ [message #23302 is a reply to message #23265] |
Wed, 07 October 2009 21:28 |
mr_ped
Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
The C++ compiler does call destructors when the object goes out of scope. The resources used by that object are not freed magically, you have to write the destructor code. Then it is "magically" called whenever that object goes out of scope.
Probably everything you will use from U++ does already have proper destructor, so you can write it as Mirek posted, you just create new object on heap, and when you go out of scope, you know it was destroyed properly.
In case you use "new" in code (and really can't avoid it, which is usually quite easy with U++ way of doing things), you have either to detect it in destructor and call appropriate "delete" (a good idea which keeps your custom classes to behave same as U++ things) or you have to watch out during that scope and call "delete" by hand whenever it is needed (going out of scope) (quite error prone).
C++ of course calls ctors/dtors automagically (inserting those calls at proper places during compilation) just like you would expect it (well, almost) (see C++ standard), so if you manage your resources this way, you can avoid many common bugs which usually arise from new/delete in function code.
But in the end it's yours (and U++) code responsibility to free everything correctly. If you do it in U++ way, you will very rarely have to think about it, it will work almost "alone".
But still you should understand how it works and why, so you don't allocate for example 3 big memory blocks at the same time (same scope), when you need just 1 at a time and then you can release it and allocate another one (but this is also problem for GC languages, if you are way too much careless, you will degrade performance of your code tenfold, and GC will not save you).
|
|
|
Goto Forum:
Current Time: Sat Jun 08 08:31:56 CEST 2024
Total time taken to generate the page: 0.01065 seconds
|
|
|