ATL / WTL / STL

Samy_Ibraheem_Mo wrote:

HRESULT get_Value(VARIANT* pVal)

HRESULT get_Value(VARIANT* pVal) {
   if(!pVal) return E_POINTER;
   return ::VariantCopy(pVal, &m_Value);
}

vector<char> charVec;
// fill it somewhere
cout << &charVec[0] << endl;

Zac Howland wrote:

If you are using the container as a pool of objects, then deque is a better choice.

CArray<int> blah;
// Populate it
std::random_shuffle(blah.GetData(), blah.GetData() + blah.GetSize());

Michael Dunn wrote:

The VC 6 STL docs blow so I haven't read them much and don't know what algorithm functions exist

Michael Dunn wrote:

The STL naming scheme sucks so it's hard to figure out what some functions are for from just their name (and the docs aren't much help, see 1. I mean, seriously, WTF does "bind2nd" do??)

Michael Dunn wrote:

Most of the time when I do use algorithms, it involves writing a special-case functor for just that usage, which is workable but just feels sloppy

Michael Dunn wrote:

Instead of fighting with the docs, I'll just write a for loop and be done with it

Michael Dunn wrote:

The VC 6 STL docs blow

Michael Dunn wrote:

t involves writing a special-case functor for just that usage

Michael Dunn wrote:

The VC 6 STL docs blow so I haven't read them much and don't know what algorithm functions exist

Michael Dunn wrote:

The STL naming scheme sucks so it's hard to figure out what some functions are for from just their name (and the docs aren't much help, see 1. I mean, seriously, WTF does "bind2nd" do??)

Michael Dunn wrote:

Most of the time when I do use algorithms, it involves writing a special-case functor for just that usage, which is workable but just feels sloppy. I know about mem_fun_ref and the like, but I haven't taken the time to figure out how they work.

Michael Dunn wrote:

Instead of fighting with the docs, I'll just write a for loop and be done with it

Michael Dunn wrote:

The VC 6 STL docs blow so I haven't read them much and don't know what algorithm functions exist

typedef std::vector<whatever> collection_t;
 
collection_t coll;
// Fill 'coll' here...
for (collection_t::iterator i=vec.begin(); i!=vec.end(); ++i)
{
    // Do stuff here...
}

typedef std::list<whatever> collection_t;

Stephen Hewitt wrote:

typedef std::vector<whatever> collection_t;

collection_t coll;
// Fill 'coll' here...
for (collection_t::iterator i=vec.begin(); i!=vec.end(); ++i)
{
// Do stuff here...
}

Stephen Hewitt wrote:

This is an expression of the general design principle that one design decision should be expressed in only one place, if possible. In this case the choice of collection type only requires a change in one location and not scattered places throughout the code. STL and iterators don't make this happen automatically but they provide the abstractions to make this sort of thing possible.

Zac Howland wrote:

That still doesn't use STL's algorithms. Granted, it is reimplementing a for_each or a transform (depending on what you do in the loop), but the fact is it is still reimplementing it needlessly.

template <typename T>
struct square_plus_one : std::unary_function<T, T>
{
    T operator()(const T &v) const
    {
       return (v*v)+1;
    }
};
 
int main(int argc, char* argv[])
{
    typedef std::vector<int> collection_t;
 
    collection_t coll;
    // Fill 'coll' here...
    std::for_each(coll.begin(), coll.end(), square_plus_one<collection_t::value_type>());
 
    return 0;
}

typedef std::vector<int> collection_t;
 
collection_t coll;
// Fill 'coll' here...
for (collection_t::iterator i=vec.begin(); i!=vec.end(); ++i)
{
    *i = ((*i)*(*1))+1;
}

Zac Howland wrote:

Take a look at Scott Meyer's "Effective STL" for why this isn't really true.

Stephen Hewitt wrote:

Michael Dunn's objection to STL: having to write a "one off" functor.

template<class T> T square_plus_one(const T& i)
{
	return (i * i + 1);
}

int main()
{
	vector<int> intVec;
	// fill vector here
	transform(intVec.begin(), intVec.end(), intVec.begin(), square_plus_one<int> ) ;

	return 0;
}

Stephen Hewitt wrote:

What's not true? If I want to see if I get better performance or use less memory using a std::list I simply change one line - this is a fact. Not many people will think it's better to have to make multiple scattered changes and run the risk of introducing an error somewhere along the way. If you've got a specific point make it here as opposed to referring to a book but giving no clue to what to mean.