C / C++ / MFC

12-Jun-02 12:13

Objects will be accessed and removed pretty much at random.

This is a big point here. Straight lists perform very poorly on lookup. The list has to be searched sequentially to find the object.

However, for lists, insertions are very fast. So are removals. But when you compare them to maps, lists insert and removals probably are much faster at all.

IMHO, I see little reason to even bother with a list. Just given that you are doing random lookups, you really need something that is fast.

If available in your STL (i.e. STLPort), you might take a look at a hash map. Since your data set is remaining a constant size, you don't have to worry about the re-hash performance hit. As long as your ID's are well distributed, hash maps should perform very fast.

... IMHO Smile | :)

moredip12-Jun-02 12:15

moredip

12-Jun-02 12:15

>>Since your data set is remaining a constant size, you don't
>>have to worry about the re-hash performance hit.

Is this true, even thought the ID's I'll be hashing on are constantly increasing?

Thinking about it, a list is definately not the way to go. As you rightly say, the lookup times for a random element in a list would /not/ be great, and that's my main priority.

I'm using M$'s STL. I'm not sure about a hash map. Is this similar to a map<obj_id, pObjData>? Forgive my ignorance, I haven't used the STL much.

Thanks,

Pete

Tim Smith12-Jun-02 12:25

Tim Smith

12-Jun-02 12:25

It is hash_map <x,y>. You probably don't have it but no big deal. Map should work just fine.

If you did have have_map, ever increasing IDs wouldn't be a problem since the ID (used as the hash value) would be moduloed by a prime number. Thus as far as the hash is concerned, the values just roll over back to 0. But even that isn't something you have to worry about unless (ID % nHashPrime) is poorly distributed. (Which is probably isn't.)

(FYI: That was my response. Was having cookie problems.)

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

moredip12-Jun-02 12:39

moredip

12-Jun-02 12:39

Ok, well I guess I'll use map, but thanks for the info Smile | :)

Alexandru Savescu13-Jun-02 6:01

Alexandru Savescu

13-Jun-02 6:01

Anonymous wrote:
If available in your STL (i.e. STLPort), you might take a look at a hash map.

hash_map is also available in VS.NET. Also, since you are not storing key and values you may consider a set or a hash_set.

Best regards,
Alexandru Savescu

Is there a way to read a given sector on a harddrive?

soptest12-Jun-02 12:32

soptest

12-Jun-02 12:32

stl::map will work for you.

example for map with GUID* (128 bit) key type and BSTR value:

implement GUIDless to compare GUID's

struct GUIDless : public std::less<GUID*> 
{
	bool operator()(const GUID* _X, const GUID* _Y) const
	{
		if(((__int64*)_X)[0] < ((__int64*)_Y)[0])
			return true;
		
		if(((__int64*)_X)[0] == ((__int64*)_Y)[0])
		{
			if(((__int64*)_X)[1] < ((__int64*)_Y)[1])
				return true;		
			else
				return false;
		}
		return false; 
	}
};

declaration of map with( GUID*, BSTR) pair

std::map< GUID* /*id*/,BSTR /*Msg*/,GUIDless > mapGUID_BSTR;

soptest

redeemer12-Jun-02 10:52

Re: Is there a way to read a given sector on a harddrive?

12-Jun-02 10:52

or do i need to do some assembly programmin gto achieve that?

Thanks

12-Jun-02 11:17

Read on http://codeguru.earthweb.com/system/ReadSector.html

Papa
Murex Co

determination of file type

12-Jun-02 10:29

Hi,

do you know some MFC or Win32 function that could help to determine whether the given file is text or binary?

Thanks

R.

redeemer12-Jun-02 10:48

12-Jun-02 10:48

A text file and a binary file are the same... what exactly do you mean by binary and text?

12-Jun-02 10:53

i have to find some info (words, sentences) in files on the local disk which is meaningless eg for pictures, and executables.
That why I wanna to check beforhand whether it is meaningful to search for my data.

redeemer12-Jun-02 11:00

12-Jun-02 11:00

hmm, you could search for null, i don't think there's null in normal text files.

12-Jun-02 11:05

yeh, but that is not a life insurance.
However your answer implies that there is no such function. That means I have to find another solution like extension checking

Thanx

R.

redeemer12-Jun-02 11:32

12-Jun-02 11:32

there IS no way of telling if a given file is so called 'text' or so called 'binary', therefor you have to guess it.

Roger Wright12-Jun-02 13:25

Roger Wright

12-Jun-02 13:25

You could open in binary mode and read a block, then test for certain characteristics. ASCII doesn't use any bytes larger than 127, and lines are terminated with CRLF. Finding a block of perhaps 1 KB that contains no bytes >127 would be a strong indication that the file is probably text.

Let's Put The Fun Back In Dysfunctional! - My Darts Team T-shirt

Matt Gullett12-Jun-02 13:46

Matt Gullett

12-Jun-02 13:46

I think you're on your own.

Suggestions:

1) Open the file and read first 1-2K and check for ASCII < 20 and ASCII > 127. (By far the simplest.)

2) Open the file and read first 1-2K and look for SPACES and puntuation (,.!?'";). I would expect the length of words on average to be pretty small (<20 letters).

3) Open the file, check first 1-2K for words in a dictionary. If most words found are not in the dictionary, it's probably binary.

10x

12-Jun-02 14:07

10x for the excellent ideas

R.