https://developer.symbian.com/main/documentation/symbian_cpp/symbian_cpp/LCL.jsp

that deals with the duplicate symbols issue and documentation updates.
Another minor release with improvements can be expected soon.

-Subhasis

why when I installing EUserHL.sis on my N95 i get warning message “application not compatible with the phone”? I can user EUserHL if end users will also see that message.

>the docs make reference to a method “EnsureCapacity” on the LString[8|16] classes that is not defined

Hmm, it looks like the documentation did not keep up with some changes in the design of the APIs.

Most users of LString will be happy to accept the automated buffer allocation and re-allocation that takes place behind the scenes of this class. The EnsureCapacityL function was one approach to allow users to override this behaviour. In the final design, however, the function ReserveFreeCapacityL takes over this use case (though with slightly different semantics).

Here’s the description of ReserveFreeCapacityL:

/**

Ensures that the remaining unused space is more than the supplied value.

May reallocate a larger storage space to meet the requirement.

As a result MaxLength() and Ptr() may return different values afterwards, and any existing raw pointers to into the descriptor data may be invalidated.

Typically, you use this method to reserve a known amount of required space in one go instead of relying on the automatic growth pattern.

@param aExtraSpaceLength The extra space required.

@leave KErrNoMemory if the the buffer needs to be reallocated and there are insufficient resources to do so.

@panic USER 11 if aLength is negative

*/

// David W.

// Alex Garbutt

>Another area of improvement could be, for example, creation of a new Client-Server architecture sub-classes that implement “sub-sessioning” automatically

It looks like you’ve been reading the specs for the Core Idioms 2 project!

Or maybe this is a case of “great minds think alike”.

// David W.

Anyway, again, keep bringing this kind of stuff to the table.

Thanks for bug report. Software engineers from the Symbian Base Services team are looking at it now.

>I don’t know where the right place to post this is…

The best place will be the Symbian Foundation Bugzilla tracker, which will shortly become available via one of the symbian.org sites

// David W.

There appears to be a bug within “emanaged.h”.

The function void ManagedPopCleanupStackItem(bool aIsManaged) is defined directly within the header, but is neither marked inline nor static.

The problem occurs when there are several source files that include this header file (even with the header guard). Each resultant object file will export the ManagedPopCleanupStackItem symbol and cause linker errors for multiply defined symbols.

Three possible solutions…
a. Declare the function inline:
Symbol won’t be created as the code is inline. Increase the size of each class that calls it. (The five LCleanupXXX classes).
b. Declare the function static:
Symbol won’t be exported outside the object file. Increase the size of each object file that includes the header file.
c. Leave the function prototype (declare it extern) and move the function definition:
Symbol only defined once, not as readily patched by end users.