Re: Typedef and more - C / C++ / MFC Discussion Boards

A typedef allows a new parameter to be created, it's more intelligent than a macro ( I believe ) but does the same sort of thing in effect. In this case, for example, PBEGINTHREADEX_THREADID is the same as an unsigned (int) pointer.

The reason to do this is that the type you use through your code for something specific can be changed just by changing the typedef.

I've never found a use for them, so if anyone else contradicts me, believe them first Smile | :)

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002

so my answer could be wrong? Blush | :O

------------------------------------
Rickard Andersson, Suza Computing
ICQ#: 50302279
I'm from the winter country SWEDEN!

------------------------------------

I thought my answer might be a little more expansive, but I didn't think yours was wrong.

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002

Of course! Roll eyes | :rolleyes:

And I just wanted to know if I was wrong about that point! Smile | :)

------------------------------------
Rickard Andersson, Suza Computing
ICQ#: 50302279
I'm from the winter country SWEDEN!

------------------------------------

I have used this kind of typedef in the past. Usually when I have loaded a DLL dynamically, and you nned to store function pointers to the return calls from GetProcAddress. This allows you to save the pointers in member vars and call them like function of a regular class once the pointers are correctly initialised.

For example:

typedef int		(*DLLINIT)(int x);
typedef void		(*DLLEXIT)() ;

class DLLWrapper
{
	DLLINIT				DLLInit;
	DLLEXIT				DLLExit ;
	HINSTANCE			hInstance ;

	DLLWrapper(CString& filename)
		{
		DLLInit = NULL ;
		DLLExit = NULL ;
		hInstance = NULL ;
		LoadDll(filename) ;
		} ;
	~DLLWrapper()
		{
		if (hInstance)
			FreeLibrary(hIstance) ;
		hInsatnce = NULL ;
		}

	bool		LoadDLL(CString& filename)
	{
	hInstance = LoadLibrary(filename);
	if (!hInstance)
		return false ;

	DLLInit = (DLLINIT)GetProcAddress(RefinementDLL.pDLL, "DLLInit");
	DLLExit = (DLLEXIT)GetProcAddress(RefinementDLL.pDLL, "DLLExit");
	return true ;
	}
} ;


// you can use the object like this
DLLWrapper	fred("Some.DLL") ;

fred.DLLInit(1) ;		// call through typedef pointer

That lot was put together quickly, so it may not all be 100% correct.

Roger Allen
Sonork 100.10016

If I'm not breathing, I'm either dead or holding my breath.
A fool jabbers, while a wise man listens. But is he so wise to listen to the fool?

NicholasCougar wrote:
typedef unsigned (WINAPI *PBEGINTHREADEX_THREADFUNC)(LPVOID lpThreadParameter);

function pointer

NicholasCougar wrote:
typedef unsigned *PBEGINTHREADEX_THREADID;

a typedef of a unsigned! Smile | :)

A typedef is a way to make your own names of types in C++. And sometimes "makeing" your own types...

------------------------------------
Rickard Andersson, Suza Computing
ICQ#: 50302279
I'm from the winter country SWEDEN!

------------------------------------

Hi,
the first defines a pointer to a function that takes a void pointer as parameter and returns an unsigned. The second simply defines PBEGINTHREADEX_THREADID to be a pointer to an unsigned.
You probably got this from the CreateThread API, right? Wink | ;)

You know, for kids!

The codes are from Multithreading Applications in Win32 written by Jim Beveridge & Robert Wiener

First, please study the second and sixth parameters.

unsigned long _beginthreadex(
void *security,
unsigned stack_size,
unsigned (* start_address)(void *),
void *arglist,
unsigned initflag,
unsigned *thrdaddr);

HANDLE CreateThread(
LPSECURITY_ATTRIBUTES lpThreadAttributes,
DWORD dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWROD lpThreadId);

According to Jim Beveridge & Robert Wiener' point of view, the function _beginthreadex() is the coat of CreateThread() and the types of its parameters have been changed for the sake of being adoptable to other operation system. While, as the CloseHandle() must be called at last, programmers can't get rid of "window.h". Another side effect is, though C compiler makes no difference between DWORD and unsigned (in fact unsigned int), C++ compiler doen't think so.

As CreateThread() is inside _beginthreadex(), its parameters are less likely to be modified. Defining parameters according to CreateThread() is smarter. Since the parameters must be accepted by _beginthreadex(), the codes we discussing must appear there. The true meaning of the codes is: force type convertion before calling _beginthreadex().

the following are codes in all:<may jim="" and="" robert="" can="" forgive="" me,just="" for="" discussion="">

//The beginning of codes

#define WIN32_LEAN_AND_MEAN
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <process.h>

typedef unsigned (WINAPI *PBEGINTHREADEX_THREADFUNC)(
LPVOID lpThreadParameter
);
typedef unsigned *PBEGINTHREADEX_THREADID;

int main()
{
HANDLE hThread;
DWORD dwThreadId;
int i=0;
hThread = (HANDLE) _beginthreadex(NULL,
0,
(PBEGINTHREADEX_THREADFUNC)ThreadFunc, // Attention, Plz
(LPVOID) i,
0,
(PBEGINTHREADEX_THREADID) & dwThreadId // Attention, Plz
);
if(hThread)
{
WaitForSingleObject(hThread, INFINITE);
CloseHandle(hThread);
}
return EXIT_SUCCESS;
}

DWORD WINAPI ThreadFunc(LPVOID n)
{
// Do something...
return 0;
}

//The end of codes

My opinion is, to be a best programmer, one should no only learn how to coding, but methodology inside as well. It's not for kids, its for a true programmer.

Best regard.

I confess that I am a stubborn guy, but why not put things thoroughly, logically and systematically clean. One concrete prolem is worth a thousand unapplied abstractions.

Hi all,
I used Crystal Report object in one of dialogs in my program ...
Now, i wanna make Setup disk for it,
I added CRYSTL32.OCX to my setup disk project.
I also added CRPE32.DLL ...
I registered the CRYSTL32.OCX activex in other computer without any problem ...
But when i open the dialog which has Crystal report object, then i get this error:
"Can not found database DLL"
What is it ?
Can you tell me the list of crystal report dlls that i must copy them in other computer for using crystal report activex ?

Please help me Frown | :(

My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html

Hadi Rezaie

hey hadi

we ship a whole bunch of files to get crystal reports working:

crpaig80.dll
p2sodbc.dll
crpe32.dll

and the whole crystal folder inside your windows folder

hope this helps Smile | :)

---
"all's fair in love and war but in love there is no geneva convention"

Thanks alot for your reply Wink | ;)

My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html

Hadi Rezaie

Hi again lauren,
I copied them, and i registered the crystal report activex ...
But i still get this error: "Cannot find database DLL." Cry | :((

I'm wondering if i copied all crystal report .dll and .ocx and i still get this error Frown | :(

I used DAO in my program without any problem.

What is your idea ?

My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html

Hadi Rezaie

Hi,

It´s possible to add some extra info to a table ( that the user cannot see).

What I do with Ms Word is to insert several tables ( b.g. List of resources, List of Tasks...), and what I would like to do is if the user presses the "Update" button iterate through that tables and ask -> "Hey were you a table generated by ? Ah ! "Task list table" Ok!" ( then delete the table and add a new task list table...

I will need only a single "byte" value to store that... so please Ms Word gimme a byte .... Smile | :)

Thanks in advance, Greetings

Braulio

I have a program where the user creates a list of objects:

class MyObject{
char name[32];
double m_FixedVariables[FIXED_SIZE];
double* m_VarVector1;
duble* m_VarVector2;
};

I have created a separate heap for all these objects using HeapCreate. The two variable vectors have the same size, but the user may add or delete elements. I have created a separate block of memory for the vectors with VirtualAlloc, and a scheme where I expand or shrink this block as needed using MEM_RESERVE, MEM_COMMIT, etc. To me this seems very compact and efficient, but all you gurus will say that I should use std::vector instead. Otherwise, I will sooner or later run into trouble ("Arrays are evil!").But I have no idea how the memory allocation will work with std::vector, will the heap management be as efficient?

Vector impliments a grow policy so that it can limit the number of times it needs to recreate itself. It is unlikely to be as efficient as the custom code you are writing.

If you need this level of efficiency, I'd advise to write your own container so that it exposes random access iterators, so you can copy between it and STL containers, and use the provided algorithms, use it with streams, etc.

A pointer is a random access iterator, so it's not much harder than providing begin() and end() methods.

Christian

The tragedy of cyberspace - that so much can travel so far, and yet mean so little.

"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002

Thank, you Christian. I take your reply as an encouragement, not a warning. I will toddle along the path I have choosen for a little longer and see where it takes me. The vectors will be around as a fallback.

Regards, Haakon.

The containers in STL normally implement a allocation strategie of 2*n elements, so if you request for instance 24 elements the vector will allocate space for 48 elem +/- , this is for performance reasons, since pre-allocating memory it's more cheap than allocating the memory one step at the time. But the normal allocator strategy is slow when you are always allocating small objects on the heap, then if this is your case perhaps you need a custom block allocator, this is tricky business. For a good book explaining custom allocators and their use with STL, I advise you to buy Modern C++ Design by Andrei Alexandrescu , it's a great book and it have a full chapter explaining the allocator philosophy on STL and the implementation of a custom allocator for efficient use with small objects on the heap.
Check his site: http://www.moderncppdesign.com

and the source code of Loki(c++ advanced library), that includes the custom allocator, a note here, VC6++ neither VS. NET fully compiles this library due to lack of support of pts(partial template specialization), The sp1 of VS.net will compile this Smile | :)

loki source code

Cheers,

Joao Vaz

Thank you for your advice, Joao.

Maybe I will buy the book. However, you say that custom block allocators are tricky. It appears to me that if I do my own allocation/reallocation I'm in full control. I don't do very fancy stuff on my variable arrays (e.g. sorting), it is mostly sequential access. But I do a very large number of iterative calculations on them, and I have a vague idea that if I keep my memory compact I keep these calculations run faster. The routine must constantly load new elements into the cache for computing, and the elements should therefore contain no dead meat. (Is this rubbish, or..?)For the same reason I will probably use CString (4 bytes long) instead of char m_name[32], but from where will the memory be allocated for the contents of the CString? My heap created with HeapCreate, or the default process heap? Is <string> any better?

There are certainly a very large number of difficult choises to make for us poor beginners....

Regards, Haakon Confused | :confused:

Haakon, CString is a MFC class , not a STL class, in STL we have the string template class.

The CString class internally will by default allocate the memory by a factor of 2, and internally maintains lists(not sure how many) of memory blocks , it controls the used memory blocks and unused memory blocks,
it guards the size and the nº of slots available for allocating in the used slots due to requests of different sizes, then when we ask to allocate something, it will search for the best size match on the slots, if it finds it uses the slot, if not it will request a unused block from another list and will allocate accordingly. This algorithm is used to prevent to minime memory fragmentation and improve allocattion time. A proper and much more correct and accurate explanation of this is on MFC Internals.

The stl string implememention is faster than the mfc counterpart, and it uses similar(or more complex) algorithms.

For articles talking about allocators check this articles, both from by Matt Austern, the chair of the C++ standardization committee’s library working group.

1º The Standard Librarian: What Are Allocators Good For?

2º
The Standard Librarian: A Debugging Allocator

After reading this, perhaps you will feel the wish for not doing custom allocators ...

A note, implementing a block allocator for vector it's more tricky, because the standars mandates that the elements can be accessed on contiguous memory blocks .

ex:

vector<100> x;
while (...) { doSomething(&v[i++]); }

For other example of custom block allocator see here at CodeProject
A Custom Block Allocator for Speeding Up VC++ STL
By Joaquín M López Muñoz

As a sidenote this allocator don't work with vector neither deque(this containers allocates chunks like I tried to explaining).

Cheers,

Joao Vaz

Damn...

I am a bit shocked that the STL list, map, and sets don't allocate nodes in buckets. Not only do you increase allocation performance, you increase memory performance by reducing the number of page faults. The theory being that when the map nodes are allocated in buckets, you greatly reduce the chance that the nodes are spread out all over the memory address space.

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?

Tim Smith wrote:
you greatly reduce the chance that the nodes are spread out all over the memory address space.

Yeap, it's true, but for that you have hash_map and other hash* that will included on the next standard and normally every STL library that I'm aware provides some sort of hash counterparts.
Of course it's a pitty, because of the lack of time the hash implementations didn't went incorporated on the standard Cry | :((

, but oh well, for this, we have the possibility of breaking our heads with custom allocators. It's a shame that typedef templates don't exist on standard, because it's very ugly to deal with the rebind template hack for simulating a typedef template Mad | :mad:

used in constructing a custom allocator ... Even after reading several times the chapter of Effective STL on allocators and Modern C++ Design, I fell nauseous(spelled correctly ?) ...
Frown | :(

Sometimes I wish the STL could be made more simpler ...

Cheers,

Joao Vaz

Thank you, Joao.

I appreciate your help and will carefully read the articles you refer to, and try to figure out about allocators. Forget the spell checker, it's the content that matters. You come out clear and precise!

(In my previous reply I mentioned stl::string as an alternative to CString, but I enclosed it in brackets - that made it disappear from the text!)

Regards, Haakon.

Smile | :)

Haakon S. wrote:
Forget the spell checker

90% of the time I use it, now the others 10% are a complete disgrace Dead | X|

Sorry for the errors Cry | :((

, sometimes I write so fast and don't check my poor english Mad | :mad:

Damn it, damn it ...

Okay, have fun reading the articles Smile | :)

Joao Vaz

Using buckets in maps really has nothing to do with hash. It is just a standard optimization. It really comes into play more when your maps are stored on disk. But, the same still holds true for memory maps.

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?

Sh*t, sorry Tim , I re-readed again your post and on the 1st try I misunderstanded it.
*Grin*
You are right about this, I don't understand either and I'm not a algorithm boy, the STL guys must had a reason to implement it without buckets ... now, the reason, I liked very much to known Frown | :(

Cheers,

Joao Vaz