[Gdal-dev] Re: GDAL Coding Guidelines

Chapman, Martin MChapman at sanz.com
Wed May 31 12:33:48 EDT 2006


I can think of a reason not to use streams.  They're not thread safe.
Printf() is thread safe though, if you properly create your threads.  On
windows you would use _beginthreadex() and _endthreadex().  Please
correct me if I'm wrong.

Martin

-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Frank
Warmerdam
Sent: Wednesday, May 31, 2006 8:24 AM
To: Mateusz Loskot
Cc: gdal-dev
Subject: [Gdal-dev] Re: GDAL Coding Guidelines

Mateusz Loskot wrote:
> Hi Frank,
> 
> 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.

> 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.

> 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.

> 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.

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF,
http://osgeo.org

_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev




More information about the Gdal-dev mailing list