C++ exceptions VS Symbian Leaves :)

[metalim]

Hello.

I don't want to start another "Holy War", but have one question:
does Symbian plan to migrate to C++ exceptions in some future version (Symbian OS 10? 11? 12? 13?) and throw out crappy "leaves"?
(And I don't even ask about automatic resource management and garbage collection - that is just unbelievable in Symbian.)

And why they didn't do this in Symbian 9?
1) It already supports C++ exceptions as "additional feature";
(And don't even try to convince me C++ exceptions require more CPU power or memory than "leaves".)
2) It's not binary-, nor source-compatible with Symbian 8;
3) v9 applications require external testing and moderate modification "to meet Symbian standards" to be signed;
4) And since Symbian 10 will require more testing/changes, I see no obstacles to start using C++ exceptions in the OS itself. (Actually, I do see one: laziness of Symbian programmers)

Why I ask?
Look at your application's source code, and count lines that are there only to support leaves, two-staged constructors, cleanup stack and all related stuff. In my source code it's at least 20%. Some of them can be removed with help of thin templates, that leaves around 15%. They all will be thrown out if OS will start using C++ exceptions.

You opinions?

[ivey]

Hi,

1) are you suggesting to get rid of leaves at all in Symbian v.10? I'm afraid in this case it will be very difficult to port from v.9 to v.10. You will have to fully re-design all apps.
2) Jo Stichbury writes in her book:

Symbian OS was first designed at a time when exceptions were not part
of the C++ standard. Later, exception handling was introduced to the
standard, but was found to add substantially to the size of compiled code
and to run-time RAM overheads, regardless of whether or not exceptions
were actually thrown. For these reasons, standard C++ exception handling
was not considered suitable to add to Symbian OS, with its emphasis on
a compact operating system and client code.

I don't know if it is really true but I think Symbian developers have had very serious reasons to invent another way of exception handling instead of adopting the existing one.

If you want to know my opinion, I like leaves, traps, two-stage construction etc. I don't know why, maybe I just got used to it

[Sorcery-ltd]

Hi metalim,

Are you actually suggesting that Symbian re-write/port the entire OS to the C++ exception mechanism rather than using the cleanup stack and the leave mechanism? They always say you should never say never... but... no chance. Why on earth would they? Because a few people don't like them?

I actually think that the Symbian coding standard with the "L" on the end of the name for functions that leave makes you think much more about where your code could fail and how to handle it gracefully.

One thing that has always bugged me though is two phased construction. When it was first explained to me on a training course the instructor said that they had to have it because there was no way to push the pointer to the constructed object onto the cleanup stack in the default constructor. I said, yes there is, just push the "this" pointer on there. Oh yeah, was the response. I still haven't had a good answer. One of the books said they considered the "this pointer pushing" option but rejected it (although it didn't say why). Think of all the code, and function call overheads that could have been saved without all those NewL's and NewLC's (although we'd need a new name for a great website). OK, so you'd have broken the naming convention but you'd generally call the constructor via new(ELeave) so that tells you it could leave (in case you didn't know) anyway.

I've never thought about trying to implement the whole cleanup system so maybe there's a really good reason. If anyone reading this knows please do tell?

Sorcery

[antonypr]

It's a good discussion.

If you look at Symbian 9.1, check \epoc32\include\e32cmn.h. You can check that basically TRAP/TRAPD on Symbian 9.1 is implemented as try/catch.

So, they have implemented using standard C++ exception starting from Symbian 9.1.

Search for this block in the header file:

#ifndef __LEAVE_EQUALS_THROW__
// This block defines TRAP/TRAPD in "old" fashion.
#else
// This block uses standard C++ exception handling.
#endif


Antony

[mollevp]

I don't know whether it's is a good explanation, but here goes:
Lets say we allowed a constructor to leave. Then we could say that it would be ok to just push the this pointer onto the cleanup stack and avoid all the two-phase construction stuff.. But if we allow the constructor to leave then we would also allow code like this:

CMyObject::CMyObject() : ptrOne(new (ELeave) COne)
{
CleanupStack::PushL(this);

/** do other stuff */

CleanupStack::Pop(this);
}

So this could be a problem, imagine that CleanupStack::PushL leaved? ptrOne would be orphaned..

My point being that we would just have to make a new set of rules about object construction. I'm not sure whether it would be better or worse..

[sysctl]

I actually think that the Symbian coding standard with the "L" on the end of the name for functions that leave makes you think much more about where your code could fail and how to handle it gracefully.

One thing that has always bugged me though is two phased construction. When it was first explained to me on a training course the instructor said that they had to have it because there was no way to push the pointer to the constructed object onto the cleanup stack in the default constructor. I said, yes there is, just push the "this" pointer on there. Oh yeah, was the response. I still haven't had a good answer. One of the books said they considered the "this pointer pushing" option but rejected it (although it didn't say why). Think of all the code, and function call overheads that could have been saved without all those NewL's and NewLC's (although we'd need a new name for a great website). OK, so you'd have broken the naming convention but you'd generally call the constructor via new(ELeave) so that tells you it could leave (in case you didn't know) anyway.

I've never thought about trying to implement the whole cleanup system so maybe there's a really good reason. If anyone reading this knows please do tell?

Sorcery

I think you have answered your own question in the first sentence. There is no way to append an "L" to the default constructor, and there is no other way to know if after calling the default "new (ELeave) CObj", it will be on the cleanup stack or not. If you adopt one convention for it (e.g. "after calling new, the pointer must be on cleanup stack"), then you'll always have to Pop or PushL after calling operator "new".

[mgroeber9110]

Personally, I think that this is a very good discussion to have, because the Cleanup Stack and Leave mechanism, which are tightly connected, are probably among the thee things that contribute most to the Symbian learning curve (Descriptors and Active Objects being the other two :-)).

Symbian's original argument for not using C++ exceptions was that C++ compilers at the time EPOC32 was designed were not mature enough to rely on the efficiency of their stack unwinding. However, with Symbian 9 this argument seems to have lost weight, as Leaves are now implemented as Exceptions anyway.

So, to me, the question is now whether it makes sense to gradually move towards a new coding style that takes advantage of this, and moves things more closely to standard C++ practice, without giving up the advantages of what Symbian does today (e.g. the "...L" suffix, to indicate whether you can safely assume that a function will never leave/throw, which allows for much more efficient cleanup handling).

And why they didn't do this in Symbian 9?
2) It's not binary-, nor source-compatible with Symbian 8;
[...]
Why I ask?
Look at your application's source code, and count lines that are there only to support leaves, two-staged constructors, cleanup stack and all related stuff. In my source code it's at least 20%. Some of them can be removed with help of thin templates, that leaves around 15%. They all will be thrown out if OS will start using C++ exceptions.

However, I think this particular argument is a bit hasty, because even though Symbian 9 is not binary compatible, there are very different degrees of "not source compatible". It makes a huge difference if you talk about touching 1% or 10% of your code to support an upgrade.

If your source code really contains about 20% of cleanup-related stuff, this suggests that a full move to exceptions and stack unwinding would require you to at least review about 1/5 of your code to take advantage of it. This is certainly much more than the changes I had to make to support Symbian 9 - so it would have meant a lot of extra work, on top of the PlatSec, IPC2 etc. changes.

And some things won't fully go away - you will still need some mechanism to, say, ensure ownership of temporary CBase pointers, so they are not leaked if an exception occurs. But replacing PushL/Pop by auto_ptr might not be such a bad idea after all...

But I bet this is a discussion that Symbian are having internally as well. ;-)

[Sorcery-ltd]

Hi,

Thanks for the replies! There are some very good points there. Here's a thought that I've just had and not considered thoroughly...

How about 2 overloads for operator new - new(ELeave) & new(ELeaveCleanup) or something similar. The first one could allocate the necessary memory and push the pointer to it onto the cleanup stack before calling the default constructor, then pop the pointer after the constructor completes. The second one would be the same except that it doesn't pop the pointer.

Doing it this way could allow existing code to continue working (you just end up pushing the same pointer to the cleanup stack twice and popping it once for a NewLC) and you can remove the inefficiency at your leisure or not at all of you don't need to.

Having not thought this through there could be all sorts of problems with it. It sounds pretty simple though (famous last words?).

Sorcery

[mgroeber9110]

How about 2 overloads for operator new - new(ELeave) & new(ELeaveCleanup) or something similar. The first one could allocate the necessary memory and push the pointer to it onto the cleanup stack before calling the default constructor, then pop the pointer after the constructor completes. The second one would be the same except that it doesn't pop the pointer.

I am wondering if all this is actually necessary in Symbian 9. I may be wrong, but can't we do without the Cleanup Stack in the constructor for this?

My understanding of native C++ exception handling is that you are free to use functions that can "throw" in the constructor without any safeguards, because if your constructor leaves, the necessary destructors for the partially constructed object will be invoked anyway by the compiler, and the memory for the object in the process of creation will be freed by the RTL.

So with native exceptions, the Cleanup Stack wouldn't be needed in the constructor at all, and both phases of construction could be combined into one. For consistency, new(ELeave) would "bubble up" the exception (being equivalent to NewL), while plain new would catch it, and return NULL - now only this last bit may be a bit non-standard, I believe...

[ivey]

Hi,

How about 2 overloads for operator new - new(ELeave) & new(ELeaveCleanup) or something similar. The first one could allocate the necessary memory and push the pointer to it onto the cleanup stack before calling the default constructor, then pop the pointer after the constructor completes. The second one would be the same except that it doesn't pop the pointer.

I do not think it is going to work. operator new will only push on the cleanup stack a pointer to the allocated memory but not the object to be constructed, so in case of a leave the objects destructor will not be invoked.

[saji_iq]

Nice disucssion here, but I do not think there is any need of Exception Handling in Symbian OS instread of leaves.

Let me explain it a bit.

As you people already know mostly emmbeded programming is done using C and Asembly language, So there is no concept of Object Oriented in emmbeded programming.

Now let us talk about symbian, According to my Knowledge "Symbian OS is the one who brings the Object Oriented concept in emmbeded and they have designed and introduced some new things in it.

Hadling the Exceptions using try and catch is not the only way to handle the exceptions, we have to look more new ways ....... cos technology is changing and so we have to adopt some new concepts also.

[Sorcery-ltd]

Hi,

ivey, I am maybe lacking some understanding of the internals but operator new has to know what sort of object it is constructing to allocate the right amount of memory and call the right constructor, so surely it should be possible to push the object to the cleanup stack correctly just before the constructor is called rather than immediately after?? Possibly an issue related to how much of the built-in compiler functionality you replace?

That said it seems unnecessary. If what mgroeber9110 says is true and we can trust the native C++ exception handling to clean up properly during construction then perhaps you can just write standard C++ code (being careful to do your exception handling properly of course) and where you use a native Symbian class you call NewL (realising that it might throw an exception) and either assign it to a member variable to be deleted in the destructor or use an auto_ptr if it's temporary. Perhaps we could also have another smart pointer type for resources that should be closed if they go out of scope?

Would that leave people free to choose to write leak-free code their own way rather than having to do it the Symbian way? Helping to flatten out that learning curve a bit.

I'll probably keep doing things the Symbian way because I'm used to it now but the accessibility of the platform to other developers has got to be a massive issue as it becomes more of a mass market thing.

There seems to be a massive shortage of Symbian developers at the moment and while that can be good for those of us that got in early it can't be good for the long term future of the platform.

Sorcery

[Sorcery-ltd]

Hi saji_iq,

Although an alternative exception handling mechanism is not necessary in Symbian I do think it is important.

Although Symbian is one of the first (if not the first?) to bring C++ and object oriented programming to an embedded platform they are certainly not the only ones.

You will also be able to write code for Windows Mobile (Smartphone/CE etc) and embedded Linux variants in C++. These are likely to be major platforms for developers to choose between. At the moment Symbian is really the only one where you can target serious commercial volumes of devices (IMO) but that may not always be the case. For open platforms developer support is a big factor. The easier you can make it for new developers the better.

Sorcery

[ivey]

operator new has to know what sort of object it is constructing to allocate the right amount of memory and call the right constructor, so surely it should be possible to push the object to the cleanup stack correctly just before the constructor is called rather than immediately after?? Possibly an issue related to how much of the built-in compiler functionality you replace?

operator new knows the size but not the type. If you look at the global operator new implementation in e32std.inl you'll find the following:

// Global leaving operator new
inline TAny* operator new(TUint aSize, TLeave)
	{return User::AllocL(aSize);}

Constructor is called after the memory has been allocated - I checked

you can just write standard C++ code (being careful to do your exception handling properly of course) and where you use a native Symbian class you call NewL (realising that it might throw an exception) and either assign it to a member variable to be deleted in the destructor or use an auto_ptr if it's temporary. Perhaps we could also have another smart pointer type for resources that should be closed if they go out of scope?

You think it is easier than follow a standard Symbian way? Maybe it is, I have not tried but I really doubt about it...

There seems to be a massive shortage of Symbian developers at the moment

Oh my! It's perfect! The less people who possesses professional Symbian programming skills the more chances we have to get a good job )) (This is a joke of course)

it can't be good for the long term future of the platform.

I disagree. Look at the huge FN community! I see new people coming here almost every day and here's a lot of experienced programmers who wants to help them and to share their experience. I think Symbian is going to live long.

BTW, look at hamishw's post at SDN forum:
http://developer.symbian.com/forum/t...a?threadID=444

I think he has answered most of the questions discussed here.

[Sorcery-ltd]

Hi,

My point wasn't whether it was possible to implement my speculative change with a simple addition to the existing code, more just a question of whether it was possible at all - purely in terms of eventual output of the compiler I thought my suggestion seemed reasonable. I have no idea how much work it would be to acheive that.

Thanks for the link to the other thread on the same topic.

I think this comment by hamishw was very relevant:

There is no practical way to mix the old and new exception mechanisms, and porting all our frameworks with consequent required changes to third party and manufacturer code was (and is) considered not worth the cost at this point.

Firstly he says that there is no practical way to mix the old and new mechanisms which is exactly what we've been trying to discuss solutions to here. Probably we've missed something because Symbian will have thought about it a lot more than I have! Second, he says that porting all the frameworks is considered not worth the cost at this point. That's pretty much the end of it then I'd think. The cost is only going to get higher from here and as the potential value is somewhat intangible I don't expect them to re-evaluate anytime soon. Which is what I thought anyway when I said "no chance" in my first post on this thread.

Personally I don't think I'll find any alternative easier than the standard Symbian way because I've already learnt the Symbian way. The issue is one for new developers. There are a lot of developers coming to the platform and you can see from the questions they ask here that they are finding it lot of work to learn. If you make it easier, fewer of those that try will give up.

I have to agree with you that Symbian is very likely to live for a long time. Nokia's support on its own almost guarantees that (although even they are hedging their bets slightly with Linux). I just think that it can't hurt to do as much as possible to ensure that it is the top platform for end users and developers.

Sorcery