Your first problem is that you are not storing valid pointers in your list. Try replacing the load code with, details * driver = new details ; driver->enter_driver_name(); output.DisplayDriverName(driver->get_name()); list.add_driver(driver); And to print the contents try, details* pDriver = list.getFirstDriver(); while ( pDriver ) { cout << "name: " << pDriver->get_name() << "\n" << endl; pDriver = list.getNextDriver () ; } Note I haven't suggested changed anything in your details or list classes which are basically working... Although you haven't made any attempt to manage memory, a 'package' should probably be able to delete a 'details' and a 'driver_list' should probably have a destructor that deletes all the packages. Paul

You will have to try various optimisations and measure the effect. In general optimisation is to be left well alone until you have a problem, it's good advice to optimise for space rather than speed because that helps to keep your code in the cache, and code in the cache always runs faster than code that has to be fetched from main memory. Paul

register is a hint to the optimiser that has no relevance to modern compilers. Don't worry about it. Write your code and generate an assembly listing. Examine that to look at the optimisers register allocation strategy. You can look at "project properties-C/C++-Optimization/Optimize for processor" in VS.Net and choose P4. Or /G7 on a command line. Paul

I think it's related to your use of virtual inheritance. What's your reason for making the inheritance relationship 'virtual'? Paul

Your question implies that you are doing,

for (int ii = 0; ii < a_vector.size (); ++ii )
{
a_vector [ ii ].DoSomething () ;
}

You may find that operator [] on vector is more expensive than size. Especially given that in many cases an interator resolves to a plain old pointer, so both the dereference and the increment are cheap. Perhaps you could measure your way and also,

A_VECTOR::iterator it ;
A_VECTOR::iterator itE = a_vector.end () ;
for ( it = a_vector.begin () ; it != itE; ++it )
{
(*it).DoSomething () ;
}

But it's cleanest by far to write,

class A_TYPE { ... } ;
vector a_vector ;
for_each ( a_vector.begin (), a_vector.end (), mem_fun_ref ( &A_TYPE::DoSomething )) ;

or some variant of function, functor etc that suits your code. I think this is probably potentially the fastest since the compiler has all the information to inline everything. Paul

It's a design decison, it depends how finely you want to control your locking. In principle each resource should have a CS (or other synchronisation). So in your class Test it's appropriate to have a CS in each instance of the class since the resources being protected (function and x, y, z) are unique to each instance of the class. But be careful about copying classes that contain CRITICAL_SECTIONS, I think each instance needs a new one, not a copy of an old one, so you need to write copy constructors etc. I suggest a helper class. Paul

(1)The FPU can perform the basic sin/cos/ln functions in 'hardware' and therefore presumably quite quickly, more quickly than an integer based hand coded approach. So I suggest you convert your incoming fixed point data to floating, process it, then convert it back, examine the generated machine code and measure the performance. Only then explore the options. If you use the C library functions 'double sin( double )' etc then the compiler should generate inline FPU code. (2)I don't think you'll see a significant performance difference for or against with the STL algorithms, but their use should make the code cleaner. Paul

How about this?

#include <iostream>
#include <map>
#include <iterator>
#include <numeric>

template <typename I> class Pair2ndIterator : public I
{
public :
Pair2ndIterator ( I i ) : I ( i )
{
}
typename I::value_type::second_type& operator* ()
{
return (I::operator*()).second ;
}
} ;

template <typename I> Pair2ndIterator<I> MakePair2ndIterator ( I it )
{
return Pair2ndIterator<I> ( it ) ;
}

int main()
{
std::map<char, int> mymap ;
mymap.insert ( std::make_pair ( 'a', 10 )) ;
mymap.insert ( std::make_pair ( 'b', 11 )) ;
mymap.insert ( std::make_pair ( 'c', 12 )) ;
mymap.insert ( std::make_pair ( 'd', 13 )) ;
mymap.insert ( std::make_pair ( 'e', 14 )) ;

std::cout << "Accumulate ( mymap ) = " <<
    std::accumulate ( MakePair2ndIterator ( mymap.begin ()),
    MakePair2ndIterator ( mymap.end ()), 0 ) ;

return 0;

}

Paul

Your best bet is to relay through an existing mail server, just like Outlook Express does. But if you really need to do it directly, and expect to run on Windows 2000 onwards, then checkout the DNS API, DnsQuery specifically. Otherwise you'll have to look up the DNS spec, find out how to locate your local DNS server and do the query manually. Paul

I converted your code into a small test program,

#include <map>
#include <string>

struct heapHeader
{
std::string name_ ;
int id_ ;
void * p_ ;
} ;

struct heap
{
std::map<std::string, std::map<int, heapHeader *> > s_heaps ;

bool insert ( heapHeader \*header)
{
    std::map<int, heapHeader \*> tmpMap;
    std::pair< std::map<std::string, std::map<int, heapHeader \*> >::iterator, bool> p;

    tmpMap.insert(std::pair<int, heapHeader \*>(header->id\_, header));
    p = s\_heaps.insert(std::pair<std::string, std::map<int, heapHeader \*> >(header->name\_, tmpMap));
    
    return p.second ;
}

} ;

int main( )
{
heap h ;
heapHeader * ph = new heapHeader ;
ph->id_ = 0 ;

h.insert ( ph ) ;

return 0;

}

and it compiles and runs as expected. So I don't know what your problem is. However I think your code is wrong. In the first place I wouldn't use a map where the key is embedded in the type, a set would be more efficient, you can create specific predicates to allow the object to be sorted according to its id or name. Secondly what if you insert a subsequent heapHeader with the same name? I assume this is legal? This way your maps of id-heapheader would have more than one member. Anyway I would consider rewriting 'insert' along these lines,

void insert ( heapHeader \*header)

{
std::pair< std::mapname_, std::map<int, heapHeader *> ()));
(*p.first).second.insert ( std::make_pair ( header->id_, header )) ;
}

Although perhaps the syntax could be tidied. The point is that std::map::insert never fails (other than through memory exhaution, in which case it throws an exception), it either inserts a new entry and returns 'true' in the second part of the pair, or returns false. In either case the first part of the return is an iterator to the appropriate entry. Hope that made some sense. Paul

With the MS C/C++ library running on W2K etc then I think you'll find that all those end up at the API 'HeapAlloc'. So if you're really after most efficiency then consider going direct. In general though 'new'/'delete' for C++. And create your own allocators for special cases. For instance if you're allocating large numbers of small constant sized objects then a specialised allocator based on a number of larger allocations from the system is worth looking at. As in all optimisation the big win is to get the high level aspects of the program efficient before micro optimising. Say you make all your allocations run in 95% of the time, and I tweak my app to do half the number of allocations. Who's won? Who's kept their app maintainable and simple? Etc etc. Paul

Does this help?

#include <iostream>
#include <map>

class ClassOne
{
public :
int age;
int sal;
} ;

typedef std::map<int, ClassOne> Map ;

int main()
{
Map theMap;
Map::iterator theIterator;

for ( int i = 0; i < 1000; ++i )
{
    ClassOne one ;
    one.age = 40 ;
    one.sal = 1000 ;
    theMap.insert ( Map::value\_type ( i, one )) ;
}

theIterator = theMap.find(0);

if ( theIterator != theMap.end ())
{
    std::cout << "The index " << (\*theIterator).first << std::endl ;
    std::cout << "The class, age = " << (\*theIterator).second.age << ", sal = " << (\*theIterator).second.sal << std::endl ;
}

return 0;

}

There are other ways to manage insertion, for instance,

>#include <iostream>
#include <map>

class ClassTwo
{
private :
int age;
int sal;
public :
ClassTwo () : age ( 0 ), sal ( 0 )
{
}
void Set ( int a, int s )
{
age = a ;
sal = s ;
}
int Age () const
{
return age ;
}
int Sal () const
{
return sal ;
}
} ;

typedef std::map<int, ClassTwo> Map ;

int _tmain(int argc, _TCHAR* argv[])
{
Map theMap;
Map::iterator theIterator;

for ( int i = 0; i < 1000; ++i )
{
    std::pair<Map::iterator,bool> itp = theMap.insert ( Map::value\_type ( i, ClassTwo ())) ;
    if ( itp.second )
    {
        theIterator = itp.first ;
        (\*theIterator).second.Set ( 40, 1000 ) ;
    }            
}

theIterator = theMap.find(0);

if ( theIterator != theMap.end ())
{
    std::cout << "The index " << (\*theIterator).first << std::endl ;
    std::cout << "The class, age = " << (\*theIterator).second.age << ", sal = " << (\*theIterator).second.sal << std::endl ;
}

return 0;

}

Paul

You seem to have a confusion between Map1 and Map, between one1 and one, or are these just typos in the post? What are your errors? Paul

Your syntax is wrong. You need to make convertString a static member of CRex and call it like CRex::convertString. But why is convertString a member in the first place? IMO it's worth answering that question. Paul

In the dim and distant past when I was creating Novell Netware NLMs I did something like,

struct SerialNumber
{
char sentinel [ 33 ] ;
char serialno [ 33 ] ;
} ;

SerialNumber TheSerialNumber = { "That'll be the day, when you mak",
"00000000000000000000000000000000" } ;

Put that somewhere in static space, then write a separate application that searches the exe for the sentinel string (ensure there's only one instance if you're paranoid....) and sets the serial no to whatever is desired. I'd suggest encoding the serial on the way in and way out, this can be something fairly trivial, and perhaps using a likely looking error message as the 'sentinel'. Paul

I think your GPF is a consequence of the compiler rather than the code. But I don't think you're going to learn anything interesting about vector per se from this type of test. The dominant factor will be allocation and reallocation. Any real usage where you know how big you want the vector would call reserve first. And if you want to get to very large arrays of ordinary types then reverting to new/delete and manual management of length is probably going to be notably more efficient. Paul

Do you have a complete compilable example to post? Your function as it exists is obviously pointless, and even if it weren't is equivalent to calling resize on the vector, which seems rather more direct. Paul

I can't understand what your code is supposed to be doing. Why not describe your basic data structures and what this collection is supposed to be used for? You obviously cannot make a map or a set of a type and then store things that are not actually instances of that type in the map or set. FWIW when you reply with code if you check the little box after the text box it will display the template definitions directly and not require us to 'view source' and generally mess about. Paul

Your question has been answered twice now. Paul

Why do you think you need to use overlapped IO? IMO it only makes sense to consider overlapped IO with serial ports if you plan to operate multiple ports on a single thread. What sort of protocol are you implementing? Paul