Do's and Dont's of Symbian programming

Good effort here, I have a two notes though:

This is should not be a problem:

void CMyRequest::DoSomeThingAsync()
{
  //Some pre-amble operations...
  //
  //
  TRequestStatus status = SendRequest();
  //Some code...
  User::WaitForRequest(status); //This will cause problem
  //some more code...
}

Because since you do "WaitForRequest", your thread will block at this point until this request has completed, so the TRequestStatus will be valid on stack for as long as its needed.
This pattern is not recommended anyhow though, since it makes for an unefficient system if you are a client of more then one asynchronous service (and you always are if you are a UI app)

*

Also, when it comes to memcpy vs Mem::Copy, I'm pretty sure one of them simply calls the other one internally, so there should be close to 0 difference.

It is good of you to attempt to help others, however there are a few things that require clarifying.

1) The TRequestStatus example is so contrived only a lunatic would write code like that.

"A very common bug is TRequestStatus allocated on stack." No its not, there are many many instances where they are allocated on the stack. As mentioned above it
will halt your current thread but there are instances when it is acceptable to do so, you can't simply say doing that is a bug - its not.

2)
for(TInt i=0; i {
//Do some operation
}
Are you going to explain why it can turn into an infinate loop so the dear readers will know what the problem is?

3)
"Two servers S and S'. S is client of S' and S' is client of S.
S sends a synchronous message M to S' and S' sends synchrounous message M' to S and completes M only after completion of M'."

I can't think of a circumstance when two servers are each clients of each other? What's a real world example?
And whats the point of saying don't do something if you don't give the solution?

Here is my take on it. It's related mostly to game and image processing programming.

1. Don't do Symbian programming if you can help it. Practically any other platform (alive I mean) is more easy, more open, better documented and have better market for third party application. (or will have in case of iPhone or Android)

2. If you absolutely must use Symbian writing functional prototype on PC/workstaion would help a lot. I don't mean Nokia/UIQ SDK emulator, I mean normal native PC application which have a block with the same functionality. Debugging will be a lot more easy and faster.

3. Don't use Mem::Copy and Mem::Fill, use memcpy and memset instead. But define them as
#define memcpy(...) Mem::Copy(...)
Use int instead of TInt.
That way porting to and fro other platform would be a lot more easier.
But don't forget - TReal is not float.
Don't use Symbian naming condition for the same reason.

4. Don't use massive floating points calculation if target device don't have FPU. Use fixed point math instead. While using fixed point math always keep in mind overflow and precision loss. However use common sense - several floating point operations wouldn't kill you. Also TReal32(float) is a lot faster than TReal (on the devices without FPU).
There is a lot of fixed point math code on the net. Including FFT. It would be easy to incorporate it into your code if you stick with advice 3.

>> 1) The TRequestStatus example is so contrived only a lunatic would write code like that.

Numpty, You're a star. I'm very much liking your new "zero tolerance" attitude!

>> I can't think of a circumstance when two servers are each clients of each other?

I've seen this happen, although it's not really something you'd encounter on a day to day basis. Certainly you'd have to be doing something fairly advanced or at the OS level to have this happen. The point is that a server is fundamentally just an active object so it can only process one message at a time.

>> Also, when it comes to memcpy vs Mem::Copy, I'm pretty sure one of them simply calls the other one internally, so there should be close to 0 difference.

It really depends on the size of the copy. The overhead of the additional function call could be significant for small copies. I think Raghav has the right idea though: avoid using "libc" on Symbian if possible!

>> 1. Don't do Symbian programming if you can help it. Practically any other platform (alive I mean) is more easy, more open, better documented and have better market for third party application.

I don't agree with this statement at all. For sure there are things that could be so much better (I've ranted on various forums about these from time to time) but fundamentally Symbian programming is not any different than any other platform. If anything it's better on Symbian (which probably explains why I'm still doing it).

>> Don't use Mem::Copy and Mem::Fill, use memcpy and memset instead. But define them as
#define memcpy(...) Mem::Copy(...)
Use int instead of TInt.
That way porting to and fro other platform would be a lot more easier.
But don't forget - TReal is not float.
Don't use Symbian naming condition for the same reason.

This is NOT good advice. The way you make porting easier is that you seperate the engine parts of the application from the UI / OS layers. C/C++ code mostly runs just fine on Symbian, so engine code shouldn't need changing. The UI / OS layers should use the proper coding conventions and OS functions.

>> All the pointers being used should be checked against NULL before dereferencing.

This is mostly good advice but it's not always necessary. For example, I hate seeing code that checks pointers that have been allocated by the NewL(). There's no way those can be NULL, so you are just writing inefficient and harder to follow code. And there is no point in checking a pointer if it has been set by a leaving function, e.g.

somepointer = CreateObjectL();
if (somepointer)
{
// Always true, so the test is pointless.
}

Whether pointers can be NULL should be specified in the design (for example as part of the pre and post conditions for each function). In addition if pointers passed to functions can't be NULL you should be using references instead (although of course that isn't always practical).

"Two servers S and S'. S is client of S' and S' is client of S.
S sends a synchronous message M to S' and S' sends synchrounous message M' to S and completes M only after completion of M'."

Its a weird case, but it can happen, we have had this exact problem in our project, but then again, our project is pretty much "over the top" when it comes to complexity and OS integration...
This is the "simple" case though, much more "fun" is the 3 party deadlock, A calls B, B calls C and C calls A, and with perfect timeing to have all 3 just hang there waiting for reply...

-

Also, 100% agree with fig7, DON'T write null checks everywhere where they are not needed!
Follow symbian conventions and mostly you don't need them.

Also, don't try to write your symbian code with some other coding standard, use the symbian coding standard for any and all symbian specific code, and then keep your platform independent engine part in whatever coding standard you like for it.
Actually just makes it easier to keep engine and platform integration apart properly that way.

There is no way you can find any one coding standard that works perfectly on all platforms anyway...

First example: I've spotted the problem as a signed/unsigned comparison. Infinite loop-ness would depend on the compiler and how it handles signed/unsigned comparisons though (I think).

TRequestStatus examples: I'm surprised no-one else has noticed this yet. There is a problem with all examples given, namely that the examples are passing the TRequestStatus by value rather than reference. This would completely avoid memory leaks, but at the expense of them no longer being the same TRequestStatus objects that the asynchronous objects are using for their status (assuming, of course, that the copy-constructor isn't made private in TRequestStatus, at which point it just wouldn't compile anymore. I can't quite remember if it is or not )

I don't see how in example 1 it can turn into an infinite loop... I would appreciate some explanation. Merci.

4. Don't use massive floating points calculation if target device don't have FPU. ->>

I would say even if it has. Avoiding floating points calculations on a phone save time, power and keeps it easy to port to other terminals.