Log in

No account? Create an account
Grizzly Weinstein
.:.::.. .:.:.::.:

April 2009
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Grizzly Weinstein [userpic]
Coding standards and beards

Had some good news today with regards to my group's coding standards. Last week I asked for a group consensus with regards to coding practices.
This is always a fun discussion! Religious wars abound.

Anyway, aside from getting my requests of not using NULL and not using Hungarian notation shot down. When I suggested some template practices, I was told not to use templates or the STL. I was miffed; I was told that templates are arcane! And that STL has lots of bugs; although when asked they didn't know what these bugs were.

Today we came to an agreement, we will wrap the STL classes used so if they do present a problem they can be removed. Good thing, I was already preparing an email about stagnation of skills in development groups and suggesting I might be in the wrong group.

Also I shaved my beard off the other day, no more Grizzly Weinstein. It just wasn't me.


Ouch! Hungarian notation - and templates are arcane? Wrapping the STL??? Doh! That's a neat trick. Do you know how you're group is going to do this (I suggest tasking this to the person who brought up the idea, or who opposed the STL in the first place)? What, exactly, is the 'STL'? Are you going to wind up wrapping the entire C++ standard library (it's got 'issues', man)?

I've always advocated 'rolling your own'; what's this 'code re-use' blather I keep hearing about? Besides, re-writing low-level library functions is much more fun than designing some new-fangled application.

This sounds like a C++ progammer's nightmare. I'm sorry, man. Really. IMO, this is the sort of thing that dooms a project from the very beginning.

I'm sorry to come across so negative; but this sounds like a profoundly bad idea (on top of a bad design/programming mentality/methodology). Maybe there's a way to 'wrap' the STL in a way that makes sense; I'd really be interested in hearing how you do it. I have trouble wrapping my brain around it, personally.

Maybe you can make a 'declare namespace std' macro, and if there's ever a 'problem', redefine the macro to nothing, and rewrite the C++ stdlib inside the global namespace. That, anyway, would be my suggestion to your group. :-)

Or, failing that, you can alway switch to the SLPort; it's gotta be better than Microsoft's, right? ;-)

Wrapping STL

This is a quick example of how you might wrap some of the vector functionality. Fortunatly I don't need great use of STL or templates for this project.
Hopefully this will show them templates, and STL work fine and the next project we can move to traits, policy classes, and boost (yeah right).

template <typename ContainedType>
class VectorFacade
      typedef typename std::vector<ContainedType>::size_type size_type;

      VectorFacade() : implementation_() {};
      explicit VectorFacade(size_type reserve) : implementation_(reserve) {};

      ~VectorFacade() {};

      size_type size() { return implementation_.size(); }
      ContainedType& operator[](size_type index) { return implementation_[index]; }
      const ContainedType& operator[](size_type index) const { return implementation_[index]; }

      std::vector<ContainedType> implementation_;

Re: Wrapping STL

Personally, I like wrapping STL strings to add more functionality, such as printf like Format and tchar handling.

inline void FormatText(tchar* buffer, const tchar* text, va_list ArgList)
#ifdef _UNICODE
vswprintf(buffer, text, ArgList);
vsprintf(buffer, text, ArgList);

inline void __cdecl FormatText(tchar* buffer, const tchar* text, ...)
va_list ArgList;
va_start(ArgList, text);
FormatText(buffer, text, ArgList);

typedef std::basic_string<tchar, std::char_traits<tchar> > TEXT_BASE_CLASS;

class String: public TEXT_BASE_CLASS
// Creators
inline String(){};
String(const String& rhs);
explicit String(const TEXT_BASE_CLASS& rhs);
explicit String(tchar c);
String(const tchar *s, ...);

// cast the string directly to a tchar pointer
inline operator const tchar*()const;

// copy data from various source types
String& operator=(const String& rhs);
String& operator=(const TEXT_BASE_CLASS& rhs);
String& operator=(const tchar *s);
String& operator=(tchar c);

// append data from various sources
String& operator+=(const String& rhs);
String& operator+=(const TEXT_BASE_CLASS& rhs);
String& operator+=(const tchar *s);
String& operator+=(tchar c);

// test equality and inequality (case sensitive)
bool operator==(const String& rhs);
bool operator!=(const String& rhs);

// test without case sensitivity
bool compareWithoutCase(const String& rhs);

// operator that allows String to be used as an STL map key value
bool operator<(const String& rhs);
bool operator>(const String& rhs);

// format the string from optional parameters
void __cdecl format(const tchar* text, ...);
void __cdecl format(const tchar* text, va_list arglist);

void removeFileExtension(String* pExtensionFound=0);

Re: Wrapping STL

And do you keep doing this for iterators? allocators? stream types? or are the latter not considered 'STL'?

Re: Wrapping STL

It is a start.

We do it for what I need. I can most likely get by with just vector and string this time around, my original design did not rely heavily on STL. I will be able to wrap iterators into functions that I need them for within the facacde.

Placing these items together removes the power of generic programming from the STL, but it should be enough for this project. I won't stand for this on the next one however.

Personally, I like Hungarian Notation (somewhat modified), but it somewhat depends on the language. For strongly typed languages like C++ or Java, it doesn't matter so much. For untyped languages like Perl, it can be really helpful.

As for not using STL, well, STL USED to have a lot of bugs and the version that shipped with pre-MSVC 7 was inefficient as hell. However, the MSVC 7+ implementation is actually pretty efficient and unbuggy. So, what they're probably operating off is old information when they shy away from STL.

Why don't you like using NULL?

Why don't they like templates? Damn useful, they are.


I try to avoid #defines whenever possible. I can't see any advantage of NULL over 0 and it lulls you into a false sense of difference between NULL and 0.

Before the standards, NULL would often be defined as (void*)0 or 0, depending on the implementation.

Cool problem caused by #defines
Using windows.h from MS

#include <windows.h>

class WindowManager
      void CreateWindow() { printf("CreateWindow\n"); }
      // and lots of other functions and stuff

int main(void)
   WindowManager wm;

   return 0;

This will not compile. Do you know all the ms functions that take a string parameter (I don't) so you can avoid using those functions in a class?

I think I saw an example once (that wasn't contrived) that compiled and didn't do the right thing.

Keep in mind that I don't work with MS stuff directly that often (though I certainly have to think about it quite a bit to keep things portable) but in the Open Source world STL's have been stable for several years. Whenever I hear anyone mention that they aren't I normally wonder if they are keeping track of the state of the art.


I am pretty sure MS just licenses the Dinkumware STL. In my last group we used it extensively for the last three years, we had zero bugs caused by the STL.

Re: Dinkumware

Yeah, that sounds right.

It has a bit shaky until version 7 or so; with version 7.1, it's as solid as any out there. That goes for their C++ compiler a bit, too - it was problematic until version 7.1, but now I'm pretty happy with it (so far ;-).


It's NOT "NULL" - it's either "null" (pointers) or "NUL" (the character). Those are standards in various languages...

STL isn't archane, but it's a bear (normally) to debug. I despise templates in general because few people create them well.

But not using Hungarian (or at LEAST a local version of it) is just insane.


Sorry, I didn't mention it in the post, but this is C++, so it is not part of the language.

few people create them well I agree, which is why I asked for some coding practices with relation to templates; I didn't want them to say 'no templates'.
a bear (normally) to debug In the last three years of using STL extensively there wasn't a single bug (found) in our code caused by the STL. The one problem I have with Dinkumware STL is the choice of variable names and template argument names. They suck, it is next to impossible by the name what it is supposed to be doing.

C++ is type-safe there is no reason to use hungarian there is no gain and the code is less readable. I would consider it in a non type-safe language, but I am pretty much an exclusive C++ programmer.

Re: C++

I always follow this rule: only use Hungarian notation in the context of generic programming.