Printable View
When you say a "public header". if you mean the entry point to a library, I never use std::string an the interface to any library because it is non-portable. Your std::string may have a different representation to mine if we are using different versions of STL.
I have a wrapper class portable_basic_string and the typedef to portable_string with char as its type is in its own header. pstr_cref can also be put in its own header in which case you don't need to search around to see what it means.
Yep, that's what I meant. This brings up a good point though. If a library heavily uses the STL containers -- lists, vectors, etc..., not just std::string -- then making a portable public interface can be difficult. I wish there were standard portable versions of the STL containers.
Hmm, about that one
There may be a reason for preferring the 1st one in some cases. If the object is too large to be placed on the stack... What do you think?Code:{
T *p = new T();
// ...
delete p;
}
instead of just:
{
T t;
// ...
}
One that recentlly caused me grief is completelly avoiding the usage of refferences. All the functions were like:
Code:void Foo::func( TimeExpensiveClass obj)
{
obj.getName();
}
vs
void Foo::func( const TimeExpensiveClass& obj)
{
obj.getName();
}
I will publish my "portable_basic_string" sometime but it relies on a shared-pointer. My shared-pointer is based on boost but is slightly different. In boost's shared-pointer it calls d(p) with your deleter, whereas with mine it calls a virtual function destroy() and doesn't pass the pointer at all. The deleter is given the pointer on its construction, and deletes itself at the same time as it deletes the pointer, thus the deleter and the pointer have the same lifetime.
So my deleter for an array of characters looks like this:
The boost equivalent version would be:Code:template < typename T >
struct self_array_deleter : public deleter_base
{
private:
const T* itsPointer;
public:
void destroy()
{
delete [] itsPointer;
delete this;
}
self_array_deleter( const T* pt ) : itsPointer( pt ) {}
};
With boost you can use shared_array though, which should work here. It defaults to checked_array_deleter() (I think) if you don't specify otherwise.Code:template < typename T >
struct array_deleter
{
void operator()( const T* ptr )
{
delete [] ptr;
}
};
So it's portable only if you are using the same version of boost. (But as I am not using boost in my situation everyone is forced to use the similar smart pointer I have).
(By the way, you can put down companies who don't use boost as a pet-peeve too. I generally rewrite the bits I want on similar lines to how boost have implemented them...).
As a junior developer this thread is great!
Thanks everyone.
polus quietly creeps out of the thread to change his ways - stop doing the if(TRUE == bResult) .. and int nVar = 0; nVar = GetVar().... :D
actually I wouldn't stop from using int nVar = 0; regardless what comes after it. It creates and maintains the good habbit of initializing all the variables as soon as they are defined. Perhaps, later on you will remove the nVar = GetVar(); but you will forget to add the initialization on the line above.Quote:
Originally Posted by polus
Yes, I'm with you on this. In general I find the combination of C style and C++ style in the same program very confusing and difficult to read/maintain.Quote:
Originally Posted by jlou
Quite a lot of stuff here I agree with (in the whole thread) but, as usual, not everything!Quote:
Originally Posted by KevinHall
Also, some things are unavoidably subjective. The problem is in separating out the subjective from the objective. You get the same thing with coding standards. I find that, while I have preferences, there are some practices which I don’t like but which I’m prepared to tolerate and others that I won’t tolerate.
How about the general pet-peeves of:
- Picking up code with no documentation and no specs. Look at the code to see what it does.
- One big directory full of every header file.
which often leads to
- A lot of libraries (DLLs or shared-objects or even static-libs/archives) and you have to link with all of them just to make sure.
- If it ain't broke, don't fix it. i.e. if the program doesn't actually crash it works.
- We can't budget for you to spend 30 minutes modifying this code. Spend the time on codeguru instead.
Reading through this I see you guys are worried about the portability when using STL containers. Why is this? Are the interfaces they use not specified by the standard? Dont they all support the same set interfaces? Surely how they do their thing is irrelevant as long as the functions/algorithms do what the standard specifies. I thought as long as you used the standard functions of these containers and you made no assumptions about how the STL class in questions inner workings work then your code was portable. Am I wrong then?
The source code is portable. However, the data-layout of the STL containers may not be portable. This is a concern if you distribute a library that uses STL containers as part of the interface.
For example, if I write a library using MSVC 8.0 that exposes a function "void Foo(const std::string& str);", but someone uses Digital Mars's compiler to interface with it, then the user's application will pass a reference to Digital Mar's implementation of std::string rather than the expected MSVC 8.0 std::string. Any differences of internal layout will lead to undefined behavior.
Anyway, I hope this makes sense.
- Kevin Hall
This is not just the case for STL. You could say the same thing about the FILE structure from stdio.h.Quote:
Originally Posted by KevinHall
Regards,
Paul McKenzie
Very true.
If the object is too large to be placed on the stack then it should use new/new[] internally to allocate the large array/whatever makes the object so large (just like std::vector - I have yet to come across a scenario where you need to create a vector using new). It is not reasonable to rely on the programmer to use new when creating the object because it might not fit on the stack.Quote:
Originally Posted by panayotisk