C / C++ / MFC

Re: Delayed Single Instance Creation

2-Aug-04 22:34

I'm looking for a generic/convenient solution to the following common pattern:

X * GetX()
{
  static X * x = NULL;
  if (x == NULL)
    x = CreateX(); // soome custom function
  return x;
}

I know hot to make it threadsafe, etc, but would love to find something "well tested", threadsafe, and convenient.

Any links?

we are here to help each other get through this thing, whatever it is Vonnegut jr.

sighist || Agile Programming | doxygen

Ravi Bhavnani3-Aug-04 1:46

Ravi Bhavnani

3-Aug-04 1:46

You could use a static CCriticalSection which you Lock() and Unlock() within the X::GetX() method. That should ensure the singleton nature of your code.

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

Re: Delayed Single Instance Creation

peterchen3-Aug-04 2:02

Re: Delayed Single Instance Creation

3-Aug-04 2:02

yes, I'm using that -
however, with all the gotchas (e.g. this pattern is said to be unsafe with agressive optimizers on multiprocessor boxes, "so turn optimizations off") this is a fairly "dangerous" piece of code, and I was wondering if there was a "proven correct" generic function that does that for any type T and different Initializers.

we are here to help each other get through this thing, whatever it is Vonnegut jr.

sighist || Agile Programming | doxygen

Ravi Bhavnani3-Aug-04 2:11

Ravi Bhavnani

3-Aug-04 2:11

Dare I ~~suspect~~ suggest doing something as primitive as locking a memory mapped file for exclusive access? Would that work across processor boundaries? Just a thought!

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

Windows 98 incompatibility

sirtimid2-Aug-04 22:09

sirtimid

2-Aug-04 22:09

I have an application which is developed in VC++ 6 under a Windows 2000 machine. This application opens an Access database (it works with a class which is derived from CDaoRecordset).
I want to run this app under a windows 98 system which has installed just the Ms Office 2000.
I made a setup with InstallShield for Microsoft Visual C++ 6 and I include in the setup the ADO DB drivers.
I have to say that I convert the database that I want to open to a previous version (Ms Access 97).
During the opening of the database (under windows 98) I get an error saying "Abnormal program termination".
Can anyone please help me with this issue?

Thanks in advance

dimitris

Re: Windows 98 incompatibility

Jaime Stuardo3-Aug-04 8:01

Jaime Stuardo

3-Aug-04 8:01

I think the only solution is to debug your application under Windows 98. The fact is that Windows 98 is less permissive for some bad operations, or some bugs. For example, I will tell you my experience with a problem I had.

I developed an application that uses ADO to connect to a SQL Server database. I had a CWinApp member variable called m_Database which was initialized in InitInstance method.

In order to use ADO, I had to use CoInitialize(NULL) in InitInstance and CoUninitialize in ExitInstance. Note that the m_Database destructor was responsible to close and release ADO objects.

All works perfectly under Windows 2000 and XP, but in Windows 98 application crashed at exit.

The cause of the problem: CDatabase destructor was called at the end of ExitInstance, of course, after CoUninitialize. Since COM was uninitialized when I tried to release COM interfaces, application crashed, but only in Windows 98. In Windows 2000 and XP, application exited the normal way.

The solution: declare the member as * m_pDatabase, and delete it before CoUninitialize.

I could realized of that only by debugging it in Windows 98.

This wasn't the only problem I had when running the application in that platform.

Jaime

Structure of a signed short

Joel Holdsworth2-Aug-04 21:58

Joel Holdsworth

2-Aug-04 21:58

Does anyone know where I can find the bit structure of a 16bit signed short?

Joel Holdsworth

peterchen2-Aug-04 22:52

2-Aug-04 22:52

platform dependent, but on "everything useful I know" it's 2's complement:

0..0x7FFF are nonegative values 0..32767
0xFFFF..0x8000 are negative values -1 .. -32768

(incrementing 0x7FFF == 32767 rolls over to 0x8000 == -32768)

data is stored either least significant byte FIRST or LAST.

Intel x86/pentium platforms use LSB first, so a 0x7FFF is actually stored as
[0xFF] [0x7F] in memory.

BIT position is a "mu" question in C/C++ and even assembler (i.e. it typically doesn't make sense to discuss if the most or least significant bit is stored first, unless you want to re-wire your motherboard)

Hmm... anythign I forgot?

we are here to help each other get through this thing, whatever it is Vonnegut jr.

sighist || Agile Programming | doxygen

Joel Holdsworth2-Aug-04 23:38

Joel Holdsworth

2-Aug-04 23:38

Thanks; that's very useful!

Joel Holdsworth

Henry miller3-Aug-04 4:30

Henry miller

3-Aug-04 4:30

I have to disagree with that last statement. It is very important to remember bit position whenever you are moving data between systems or to hardware.

As soon as you transfer data you have to prepare to deal with (or make an informed decision not to!) with other byte orders. The Mac uses a different byte order from intel machines, so if you don't deal with it your numbers will be wrong.

Also hardware needs this consideration. If you talk directly to hardware you need to make sure you are using the byte order of that device, which is sometimes different from the machine you are on.

The latter is somewhat a special case, but the former is a big deal. You never know when the boss will tell you that a port to the mac must be done. (or sun or cray or mainframe) and bring these issues forward. Just be aware that it is a problem now, and try to isolate all the areas where data might leave this computer. (either network or by disk)

peterchen3-Aug-04 12:32

3-Aug-04 12:32

I mentrioned that the Byte order is important - what doesn't exist (unless you start to transfer data over a serial protocol) is a BIT order inside the byte (maybe the last three words were missing)

The thought of my discussion was that there are C++ operations that can tell you about the byte oder, but a "bit order" isn't noticable even on the assemblers I know (where bits are always indexed by significance, not posiiton)

we are here to help each other get through this thing, whatever it is Vonnegut jr.

sighist || Agile Programming | doxygen

IE Crashing

Abhi Lahare2-Aug-04 21:51

2-Aug-04 21:51

Hi all,

I am using IE6.0 and its crashing many times, When i debug iexplore.exe it using MSVS.

I am getting assembly code as below

77F82D5D je 77F82D70
77F82D5F or ecx,0FFFFFFFFh
77F82D62 xor eax,eax
77F82D64 repne scas byte ptr [edi] <- cursor is at this point
77F82D66 not ecx
77F82D68 mov word ptr [edx+2],cx
77F82D6C dec ecx
77F82D6D mov word ptr [edx],cx
77F82D70 pop edi

and the stack window shows
NTDLL! 77f82d64()
// other stuff.

Can someone help me in tracing the problem. and how to extract information from this

Thanks in advance
Abhishake

jmkhael2-Aug-04 22:21

jmkhael

2-Aug-04 22:21

Up the stack,Who is calling NTDLL ?

Papa

while (TRUE)
Papa.WillLove ( Bebe ) ;

Abhi Lahare2-Aug-04 23:53

2-Aug-04 23:53

Thanks Papa,

Since i am not sure what i going wrong here is all the information

NTDLL
**********
77F82D5F or ecx,0FFFFFFFFh
77F82D62 xor eax,eax
77F82D64 repne scas byte ptr [edi] <- cursor is at this point
77F82D66 not ecx
77F82D68 mov word ptr [edx+2],cx
77F82D6C dec ecx

KERNEL32! 77ea069f()
**********

77EA0693 ret 4
77EA0696 push dword ptr [esp+4]
77EA069A call 77E86F4C
77EA069F test eax,eax <- cursor is at this point
77EA06A1 je 77EA06AB

F3HTMLMU! 020c99e3()
**********

020C99DE call 020C9A48
020C99E3 lea ecx,[ebp-74h]
020C99E6 call 020CBDDC
020C99EB lea ecx,[ebp-18h] <- cursor is at this point
020C99EE mov dword ptr [ebp-18h],esi

F3HTMLMU! 020c97c7()
**********

020C97C2 call 020C9882
020C97C7 test al,al <- cursor is at this point
020C97C9 je 020C97CE
020C97CB push 1
020C97CD pop esi

jmkhael3-Aug-04 0:17

jmkhael

3-Aug-04 0:17

F3HTMLMU is causing u all the grief and trouble.
This is related to the mwsbar BHO.
In other terms its a toolbar that you have in IE explorer that is crashing it.

You can uncheck it from the toolbars or unregister the BHO, or remove it from the registry

Papa

while (TRUE)
Papa.WillLove ( Bebe ) ;

Abhi Lahare3-Aug-04 1:08

3-Aug-04 1:08

Thanks Papa,

There are many toolbars (BHOs) loaded in IE, how to know which BHO is causing problem, can we extract that infromation from the assembly code, for temporary fix i have removed all the toolbar, Is there any way i can learn how to extract the information for assembly code?.

Thanks for you help again

With Regards
Abhishake

jmkhael3-Aug-04 1:22

jmkhael

3-Aug-04 1:22

F3HTMLMU is the BHO causing the trouble.

You can search on your hard disk for F3HTMLMU.dll and remove/rename it (i guess programfilesdir+\mywebsearch\bar\1.bin\

Or
Looking in the registry under LocalMachine\software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\ You'll see all the BHO u have.

The F3HTMLMU is the faulty one, so you can search now between these class IDs listed at the registry

eg: {A6A49249-57AE-4295-8D4D-18A9502C7D8E}
wich one reference F3HTMLMU.DLL and remove it.

Todo so search in the whole registry for the key for instance {A6A49249-57AE-4295-8D4D-18A9502C7D8E} you'll see a key, and a key under it named InprocServer32, in its default value you'll find the dll name.
Hope this helps

Papa

while (TRUE)
Papa.WillLove ( Bebe ) ;

Abhi Lahare3-Aug-04 1:33