C++ questions

[Jacques Cooper]

Hello,

I have 3 questions.

Q1. What is the difference between a dynamic cast and a static cast?

Q2. When would you use a virtual destructor?

Q3. What's the difference between a critical section and a mutex?

TIA,
Jacques

[kuphryn]

Programmers control dynamic allocations.

Virtual destructors are use in parent and child classes in
inheritance OOP designs.

A CRITICAL_SECTION is effective under single process
applications. On the other hand, a mutex is a
CRITICAL_SECTION with support for multiprocesses.

Kuphryn

[Yan-Hong Huang[MSFT]]

Hi Jacques,

In general you use static_cast when you want to convert numeric data types
such as enums to ints or ints to floats, and you are certain of the data
types involved in the conversion. static_cast conversions are not as safe
as dynamic_cast conversions, because static_cast does no run-time type
check, while dynamic_cast does. A dynamic_cast to an ambiguous pointer will
fail, while a static_cast returns as if nothing were wrong; this can be
dangerous. Although dynamic_cast conversions are safer, dynamic_cast only
works on pointers or references, and the run-time type check is an overhead.

Using virtual destructors, you can destroy objects without knowing their
type ！ the correct destructor for the object is invoked using the virtual
function mechanism. Note that destructors can also be declared as pure
virtual functions for abstract classes.

Just as Kuphryn said, the area of a critical section is for one process.
And the area of a mutex is for the whole system.

Best regards,
yhhuang
VS.NET, Visual C++
Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.
Got .Net? http://www.gotdotnet.com
--------------------
!From: "Jacques Cooper" <jco...@jcsoftware.net>
!Subject: C++ questions
!Date: Tue, 4 Mar 2003 17:07:17 -0800
!Lines: 14
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
!Message-ID: <u1KFSOr4...@TK2MSFTNGP10.phx.gbl>
!Newsgroups: microsoft.public.vc.mfc
!NNTP-Posting-Host: lsanca1-ar99-077-194.biz.dsl.gtei.net 4.3.77.194
!Path:
cpmsftngxa08.phx.gbl!cpmsftngxa06!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
!Xref: cpmsftngxa08.phx.gbl microsoft.public.vc.mfc:364725
!X-Tomcat-NG: microsoft.public.vc.mfc
!
!Hello,
!
!I have 3 questions.
!
!Q1. What is the difference between a dynamic cast and a static cast?
!
!Q2. When would you use a virtual destructor?
!
!Q3. What's the difference between a critical section and a mutex?
!
!TIA,
!Jacques
!
!
!

[Jacques Cooper]

Hi Yan-Hong,

Thank you for responding to my questions.

> A CRITICAL_SECTION is effective under single process
> applications. On the other hand, a mutex is a
> CRITICAL_SECTION with support for multiprocesses.

[...]
> .. the area of a critical section is for one process.

> And the area of a mutex is for the whole system.

What's the difference between a process and a thread?
I thought a process was a single executable program.
A process can have multiple threads. What's a multiprocess
system? Is this a collection of single executable programs?

Thanks again,
Jacques

[Nishant Sivakumar]

A process is code & data. It needs at least one thread to be active. In fact
every process has minimum one thread (the main thread). A thread is the
smallest unit of execution. On a single processor system only one thread is
executed at any one time. The illusion of multi-processing is created by
fast switching of the processor across multiple threads in multiple
processes.

Nish [VC++ MVP]

"Jacques Cooper" <jco...@jcsoftware.net> wrote in message
news:eXvM#1s4CH...@TK2MSFTNGP10.phx.gbl...

[Joseph M. Newcomer]

dynamic casts use run-time type information to make sure the casting makes sense. Static
casts say "trust me". I don't use either of them, so can't say much more. I just use the
old C-style casts, because I use them so rarely.

You use virtual destructors all the time. It is considered good programming practice to
always make your destructors virtual. This guarantees that the deepest destructor in the
inheritance is always called, even if the delete occurs higher in the inheritance
heirarchy.

CRITICAL_SECTION is a very fast mutex which is used between threads of a single process.
The price you pay is that it is not a waitable object and there is no timeout possible. It
is the recommended mechanism for interthread synchronization if you don't need timeouts or
need to be part of a larger WaitForMultipleObjects (which is almost always the case: you
don't need these capabilities, so there is a fast way to do synchronization). A mutex is
used when you need a timeout, need to be part of a larger wait, or need to do interprocess
synchronization.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

[Joseph M. Newcomer]

The formal definition is "at least one potentially runnable thread". That is, the thread
does not need to be "active" in the sense of running; it could be blocked on a kernel
object, or I/O, but as long as it might run someday, it is considered "active" in the
sense you use the word. It does not need to be the main thread (except in CE). A common
error in multithreaded programming is to block a thread then do a "close". The GUI thread
shuts down, the application "disappears", but in fact it is still "live". Attempts to
recompile the program will fail because the process still has the executable file open.

See my essay on worker threads on my MVP Tips site, where I talk about shutting down
threads.
joe

On Tue, 4 Mar 2003 21:00:32 -0800, "Nishant Sivakumar" <ni...@nospam.asianetindia.com>
wrote:

Joseph M. Newcomer [MVP]

[Bob Moore]

On Tue, 4 Mar 2003 20:12:50 -0800, Jacques Cooper wrote:

>What's the difference between a process and a thread?

Put simplistically, threads are the unit of execution, processes are
the unit of addressability (for the want of a better word). A process
is the (virtual) address space in which one or more threads execute.

--
Bob Moore [WinSDK MVP]
http://www.mooremvp.freeserve.co.uk/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Doug Harrison [MVP]]

Joseph M. Newcomer wrote:

>The formal definition is "at least one potentially runnable thread". That is, the thread
>does not need to be "active" in the sense of running; it could be blocked on a kernel
>object, or I/O, but as long as it might run someday, it is considered "active" in the
>sense you use the word. It does not need to be the main thread (except in CE). A common
>error in multithreaded programming is to block a thread then do a "close". The GUI thread
>shuts down, the application "disappears", but in fact it is still "live". Attempts to
>recompile the program will fail because the process still has the executable file open.
>
>See my essay on worker threads on my MVP Tips site, where I talk about shutting down
>threads.
> joe

It's generally untrue that extant secondary threads keep C and C++ programs
alive once main() or WinMain() has returned. Here's the counter-example I"ve
posted a couple of times in the past:

// Compile with cl -MD a.cpp

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

#include <process.h>
#include <stdio.h>

unsigned __stdcall proc(void*)
{
for (;;)
puts("In thread");
}

int main()
{
unsigned id;
_beginthreadex(0,0,proc,0,0,&id);
// Sleeping here is a non-robust way to address
// the race condition; we want the thread to enter its
// infinite loop.
Sleep(5000);
puts("Exiting");
return 0;
}

It takes about 5 sec to run to completion and prints:

In thread
In thread
In thread
... many more repetitions of "In thread"
Exiting
In thread
In thread
... a few more repetitions of "In thread"

This program does terminate, because main() returns, and the CRT ultimately
calls ExitProcess, which kills any remaining threads. This is just as easy
to demonstrate in an MFC app. Only if the CRT for some reason doesn't get
that far might the app remain loaded. It really sounds like you're
describing an ordinary, user-level deadlock bug.

The real reason to ask the threads to exit and wait on them to do so in a C
or C++ program is so they won't continue to run while the program is being
taken down all around them, not some misplaced fear that the app won't exit.
It probably will exit, but who can say how a thread will behave as it runs
while the heap is going away, static duration variables are being destroyed,
atexit functions are being called, DLLs are being unloaded, etc. It might
cause the app to crash or silently corrupt data.

--
Doug Harrison
Microsoft MVP - Visual C++