Are core bada interfaces built upon improper usage of C++ constructs?

Question

Few years ago I was browsing through the just-released Samsung BADA SDK and related materials, and I was astonished by the amount 'tutorials' and 'guidelines' which tried to clarify various basic aspects of the language and platform through ill-constructed samples with obvious errors at C++ language level (i.e. see page 8 and 9 at http://mobileawards.ir/LinkClick.aspx?fileticket=zf9YxiDILVg=&tabid=937 - presentation published by Samsung, and the code examples are original, I've seen similar somehere within SDK). But it was relatively new, so I thought they'll just cleanup that.

Recently somthing me about one of those things that cannot be just dismissed as a "typo" or "accidentially wrong code example":

BADA IList reference

virtual result Osp::Base::Collection::IList::Add ( const Object & obj ) [pure virtual]
Parameters:
[in] obj The object to add
Remarks:
This method performs a shallow copy. It adds just the pointer; not the element itself.
.....
.....

virtual Object* Osp::Base::Collection::IList::GetAt( int index ) [pure virtual]

For me, from the "classic C++" point of view, this is an obvious error. It is so wrong on many levels:

1. it accepts a generic thing by reference to be stored in the list. In the remarks, there's a note that it will be stored not by copy, not by reference, but by pointer. Taking by-ref instead of pointer will simply probably force the implementor to perform some casts/*/&s, but that's relatively minor issue

2. the accepted reference is const. The item-accessor, GetAt(), returns actually non-const object! So the collection de'const'ifies everything automatically for you..

3. there are lots of warning in various guidelines that tell you to not Add() stackbased nor temporary objects on lists. They explicitely tell you to Add() only heap-based objects, allocated by new..

4. The GetAt actually returns non-const pointer, not reference! Probably to be able to return an magic value as an error (in BADA there's no exception handling..). Now look at some various tutorials on list-handling and observe all those *s and &s scattered around and placed in the most surprising places, like:

   MyObj* x = new MyObj();
   list.Add(*x);           // the '*' is at least mighly misleading..
   

   Which later leads to amazing questions like samsung bada development without using pointers which shows that the poor person was truly confused.. But I start to digress..

The above is a fragment of one of the core interfaces, later be implemented and used by various core collections. Actually all Hashes/Lists/etc have similar hm.. convention.

For me, it looks as if it was designed by a person who was trained in, say, Java or C#, and had very little idea about C++ language. Const is constatly abused, and so are references. And also, I don't see any reason for this*)

Am I wrong with my judgement here? Do you know any reasonable explanation why those interfaces are designed that way, precisely, I look for explanation of:

• why do they use 'const', while it is not really meant nor preserved?
• why do they use references, while they say in the remarks that are not being used?

(*) well, except for the urban myth that "references cannot be NULL", which could indicate that the "Add" cannot accept a null pointer. Still that would be an insane idea, since adding-an-element requires you to dereference Add(*ptr), hence it is quite easy to notice that a reference certainly can be NULL..

edit/question rationale:

After Mike's instant and well-addressed comment, I tried to remove as much as possible of 'rant', which got into the text most probably because I sometimes hit the 'purist' mood. Still, it is hard to present errors without sounding like complaining about them. I'm not a bada developer. I don't have any real reasons to rant. My questions are not meant as rhetorical: I really would like to know the reason for this design. I do not accept simple "because this/that developer(s) was/were bad". This is probable, and I thought of it, but I reject such reasoning because I'm not omniscient and because, well, that's quite unprovable. I'm asking because this bothers me and I'd like to know the reason. I hope that some experienced bada-developer will show up and point me to some article that describes it which I couldn't google up, or that will drop some historical bit of info that will actually prove that that's borrowed from pre-std-C++ Symbian. I don't count on fast response. I actually think this question will linger without response, because there's probably not many people on earth that can provide such information. This however does not make this question rhetorical, and in my view, does not make it non-question. Of course everyone can have different view. If so, it will get closed.

Answer 1

Yes.

There simply is no good engineering reason for this. The standardization of C++ was a typical ISO process, open and well-documented. There are thousands of public documents available, and many experts closely involved with the community. This particular style has been deprecated since the integration of the STL into Standard C++, back in 1996.

Worse, these Bada collections do not add functionality to standard C++, so they're quite redundant.

The business reason is probably that all good Samsung engineers are working on real code instead of Bada. This is, and I'm sorry to be so harsh, amateur level.