[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2009-02-01, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> I spotted a few (new?) cases where the function names seem to deviate
> from the guidelines:
>
> al_ustr_new (should be al_create_ustr or al_create_ustring?)
> al_ustr_new_from_buffer
> al_ustr_free
> al_cstr (al_convert_to_cstring?)
> al_cstr_dup (what's the difference with the previous function?)
al_cstr returns a const char * which shares space with the ALLEGRO_USTR.
al_cstr_dup makes a copy.
> al_ustr_dup (al_duplicate_ustring?)
>
> etc. for the other string functions. May make sense to wait until they
> are all implemented (the comments in the file indicate some functions
> still need to be added).
Only a few to go.
I like the _ustr prefix, but I don't know if I can justify it, so I
won't argue against renaming them *if* we can come up with a set of
succinct, unambiguous names with the usual scheme.
When designing an API, especially little self-contained ones, I just end
up naming functions with "module qualifiers", as you can see in the
internal vector functions, the internal thread functions, the path
functions and now the string functions. It's *not* al_<object>_<verb>
though. It just happens that the module qualifier is usually a noun :)
> also (from utf8.h),
>
> struct ALLEGRO_USTR_INFO {
> /* This struct needs to be at least as big as struct
> _al_tagbstring. */
> int __pad[4];
> };
>
> might I suggest that in light of that comment this should then be
> struct ALLEGRO_USTR_INFO {
> struct _al_tagbstring __dummy;
> };
> or something similar? Or am I missing something?
The idea is to not expose the definition of struct _al_tagbstring, which
is an implementation detail.
Peter