Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » Basic questions about u++
Re: Basic questions about u++ [message #23296 is a reply to message #23294] Wed, 07 October 2009 18:14 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
irtech wrote on Wed, 07 October 2009 15:18

I'm confused Confused
Mirek said
If the stack frame goes out of scope, object is destryoed via destructor.

Implying it is done automatically.

but mr_ped said
Resources works like in ordinary C++,...If you use some "new", then it's up to you to "delete" of course.


The idea of U++ is to utilize the standard behaviour of C++ to avoid most of the memory management problems that normally plague C++ code. This is done in two main ways:
- Structuring the library so that every object is 'owned' by something. This means declaring objects either on the stack (as local variables) or as member variables. This allows the compiler to clean up by itself when either the owning object is destroyed or the variable goes out of scope.
- Providing the tools (mainly the NTL) necessary to control dynamic memory in a way that fits with the 'everything is owned' style. This means that although new and delete are used internally in the library you rarely, if ever, need them in your application code.

A simple example:
'ordinary' C++ code:
int CalcSomething {
    int *array = new int[256]

    // Do a load of stuff

    delete[] array;
};

U++:
int CalcSomething {
    Buffer<int> array(256); // Buffer is closest to a C array

    // Do a load of stuff
};

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 Smile.
Re: Basic questions about u++ [message #23298 is a reply to message #23296] Wed, 07 October 2009 18:47 Go to previous messageGo to next message
irtech is currently offline  irtech
Messages: 7
Registered: October 2009
Promising Member
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 Smile.


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. but not having control over copy constructor isn't a drawback by itself?
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. How should I implement them? I'm not saying it is a routine task but many times you want to do specialized tasks in copy constructor. Then how you do it?

Regards.


Re: Basic questions about u++ [message #23300 is a reply to message #23298] Wed, 07 October 2009 19:07 Go to previous messageGo to next message
mrjt is currently offline  mrjt
Messages: 705
Registered: March 2007
Location: London
Contributor
Well, here it is a little more complicated and is difficult to explain.

Basically there is a distinction between moveing and object and a deep copy of the object. This allows various memory operations to work more efficiently and nice things like returning a Vector<> object from a function. A detailed explanation is here(also follow the link to 'pick semantics'

I'll give you an example tomorrow if you need it, but I've got to run now or I'll miss my train Smile
Re: Basic questions about u++ [message #23301 is a reply to message #23298] Wed, 07 October 2009 19:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Smile.


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 Go to previous message
mr_ped is currently offline  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).
Previous Topic: Time to sing praises for MinGW and GCC
Next Topic: online Whiteboard
Goto Forum:
  


Current Time: Fri Mar 29 08:09:16 CET 2024

Total time taken to generate the page: 0.01899 seconds