[Gdal-dev] Re: GDAL Coding Guidelines

[Mateusz Loskot]

Frank Warmerdam wrote:
> Mateusz Loskot wrote:
> 
>> Today, I was talking a bit with Dronk and asking him if using STL 
>> in GADL is recommended or not. I was asking because I'm quite 
>> confused and I don't know how should I move on with some 
>> applications. Here are examples of some of my questions:
>> 
>> Can I use <sstream> library instead of sprintf,strcat, memcpy, 
>> etc.?
> 
> 
> Mateusz,
> 
> Please do not.


Frank,

OK, I won't.
That's why I'm asking. I want to follow conventions used in GDAL exactly.


>> Can I use string instead of C-like strings, when it's applicaple?
> 
> 
> You should use CPLString (a slightly extended std:string with a 
> Printf() method for formatted "printing" into the string.  Try not to
>  go wild using esoteric std:string methods as some day I may 
> restructure CPLString to not derive from std:string, but still to 
> provide similar (if somewhat simplified) services.


OK. A few additional questions:

1. Is this correct to use CPLString for input parameters in public API?

As we talked on IRC, const char* is prefered; I'm asking here to archive
this fact.

2. Can CPLString be returned from public function by value?

3. Can CPLString be used as a class data members (private)?


Currently, when CPLString is implemented with std::string, all answers
are "yes" according to std::string concepts (copyable, assignable,
etc.), but my questions are related more to future plans regarding
CPLString (e.g. can CPLString change in future so answer to 2. or 3.
will be know?).


>> e.g. concatenating strings with <sstream> would take a few line of
>>  code, but with C-like approach, it takes much longer and IMHO is 
>> more bugs prone. This is just an example.
> 
> 
> I am generally anti-streams, and have avoided their use in GDAL.  I 
> would prefer to keep that approach though if you could demonstrate a
>  compelling value I might reconsider.


Hmm, generally I could, especially against C-like strings and operating
on them but I think CPLString is enough, so no further discussion is
needed and no revolution too :-)


>> As you know, C++ is my favourite language but that's not thecase 
>> here. I also can code in C, I'm flexible ;-) I just would like to 
>> suggest the GDAL PCS to develop some coding guidelines or 
>> convention, that developers could follow. You know, C and C++ are 
>> different languages and some guidelines would help developers to 
>> avoid potential confusions.
> 
> 
> I agree that a guidelines RFC would be appropriate.  I'm just not all
>  that keen on writing it.  I'm putting this email out to the gdal-dev
>  list for further input but I will start working on a coding 
> guidelines RFC.


Thank you!
If you need any help (editing, review, formatting, brainstorm), just
give me a note.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net