Hello!

I'm trying to use the shipped boost::signals library (v1.39) with C++ Builder XE4 Update 1 in a 32bit application.

I wrote a minimal test application that does nothing more than starting a thread that periodically emits a signal that triggers a slot that writes a string into a TMemo.
I also added the $(CG_BOOST_ROOT) variable into the include path for 32bit, and $(CG_64_BOOST_ROOT) for 64bit target application.

Building a 64bit application works fine. Unfortunately I have to use external 32bit DLL for my main project. This means that using the 64bit compiler is not an option atm.

To give you an idea, what happens:
MyThread.h
{code}
#ifndef MyThreadH
#define MyThreadH
#include 

// 32-bit boost 1.39
#include "boost/signals.hpp"

// 64-bit boost 1.50
// #include "boost/signals2.hpp"

class myProcess : public TThread
{
private:
protected:
	void __fastcall Execute();

	TCriticalSection *Lock;

public:
	__fastcall myProcess(bool CreateSuspended);
	__fastcall ~myProcess();

	// 32-bit boost 1.39
	boost::signal1sigCounter;

	// 64-bit boost 1.50
	// boost::signals2::signal < void(UnicodeString) > sigCounter;
};
#endif
{code}

MyThread.cpp
{code}
#include 
#pragma hdrstop
#pragma package(smart_init)
#include "GUI.h"
#include "MyThread.h"

__fastcall myProcess::myProcess(bool CreateSuspended) : TThread(CreateSuspended)
{
	sigCounter.connect(MainGUI->MemoWrite);
}

__fastcall myProcess::~myProcess()
{
	sigCounter.disconnect_all_slots();
}

void __fastcall myProcess::Execute()
{
	static __thread int counter;
	UnicodeString text1, text2;

	while (!Terminated)
	{
		for (int i = 0; i < 1000000; i++)
		{
			Application->ProcessMessages();
			if (i == 0)
			{
				counter++;
				text1.sprintf(L"thr MemoWrite: %d", counter);
				MainGUI->MemoWrite(text1);

				text2.sprintf(L"thr Signal: %d", counter);
				sigCounter(text2);
			}
		}
	}
}
{code}

The function that is called in main is very simple:
{code}
void __fastcall TMainGUI::MemoWrite(UnicodeString msg)
{
	Memo->Lines->Add(msg);
}
{code}

Here are the symptoms:
- compiling (32bit) works after a clean-up. Compiling a 2nd time throws warnings:
[ilink32 Warnung] Warning: D:/masc/Projekte/cbuilder_tutorial/SignalThreadMinimal/Win32/Debug/SignalThreadMinimal.ilc: 0x000b0000 / 0x08000000
[ilink32 Warnung] Warning: D:/masc/Projekte/cbuilder_tutorial/SignalThreadMinimal/Win32/Debug/SignalThreadMinimal.ild: 0x00010000 / 0x08000000
[ilink32 Warnung] Warning: D:/masc/Projekte/cbuilder_tutorial/SignalThreadMinimal/Win32/Debug/SignalThreadMinimal.ilf: 0x00290000 / 0x0a000000
[ilink32 Warnung] Warning: D:/masc/Projekte/cbuilder_tutorial/SignalThreadMinimal/Win32/Debug/SignalThreadMinimal.ils: 0x00740000 / 0x08000000
[ilink32 Warnung] Warning: unknown heap name   : 0x08000000 / 0x08000000
[ilink32 Warnung] Warning: error found (LME288)

Running the thread throws debugger-exeption:
- exception in class &C0000005 with access violation 0x00406e1a: read from address 0x00000000

Xe4 highlights line 135 in embarcadero\rad studio\11.0\include\dinkumware\functional, which is in the template "TEMPLATE STRUCT less"

Can anybody give me any hints how to get this working?

Since boost is shipped with XE4 i assume, that boost is tested and known to be working with XE4 compiler.
Are there any option i can change to make boost work?
Do i miss anything else?

Any help appreciated! Thanks in advance!

Bye, Marc.

> {quote:title=Alex Belo wrote:}{quote}
> Application->ProcessMessages in background thread ?...
> Completely wrong idea. This is straightforward way to crash of
> application.

Thank you Alex for fast replay. 

Of course you're right. Unfortunately this ProcessMessages line is just a copy&paste error, when i was preparing this minimalistic example in a hurry. Does not make any sense here. Sorry for making that example not as simple as possible..
{code}
void __fastcall myProcess::Execute()
{
	UnicodeString text1, text2;

	text1.sprintf(L"thr MemoWrite");
	MainGUI->MemoWrite(text1);

	text2.sprintf(L"thr Signal");
	sigCounter(text2);
}
{code}
raises same exception..

Oh, even to declare a signal in public section of my thread class (without using anything signal related elsewhere) raises an exception..
{code}
class myProcess : public TThread
{
private:
protected:
	void __fastcall Execute();
	TCriticalSection *Lock;
public:
	__fastcall myProcess(bool CreateSuspended);
	__fastcall ~myProcess();
	// 32-bit boost 1.39
	boost::signal1sigCounter; //<- raises exception with bcc32
	// 64-bit boost 1.50
	// boost::signals2::signal < void(UnicodeString) > sigCounter;
};
{code}

Nevertheless the problems stays the same... using boost::signals (1.39) with bcc32 crashes and bcc64 works...

Any hints? Any one who has hused boost::signals (1.39 with XE4, 32bit) before?
Thanks in advance!

Bye, Marc.

> {quote:title=Eike Petersen wrote:}{quote}
> We have been using "signals" rather intensively for many Builder-versions now (current version we are using is with CBXE and Boost 1.39" and it works just fine for us. However there are some potential problems with compiler settings you have to be aware of. For us the "enum-size"-project option was always a potential crash cause, but there are other options that will cause crashes too. Generally you have to make sure that project-settings which affect class layout match those which were used to build th
e Boost-DLLs shipped with the IDE.
> 
> I filed a QC-report about this two years ago (which is still open):
> 
> http://qc.embarcadero.com/wc/qcmain.aspx?d=98214
> 
> "Please note, that to be able to even get this far, you have to modify the default CBXE compiler settings under "C++Compiler/General Compilation/Integer-sized enums" to 'false'.
> By default this setting is 'true', but in the DLL version of Boost shipped with the IDE this setting seems to be 'false'  - so every program dynamically linked against the shipped Boost libraries will probably crash."
 
Thank you very much, Eike!
Your hints were exactly what i was looking for!

What made boost working for me:
- Project/Options/C++ compiler/Common compile options/
	- Enums with integer size: false
	- Data alignment: quad word

Problem solved - thanks to the communiity!

Bye, Marc.

Edited by: Marc Schappeit on Oct 15, 2013 9:31 AM

> {quote:title=Alex Belo wrote:}{quote}
> I do not use boost so this is out of my knowledges, sorry.
> 
> AFAIR there were complaints that bcc32 (probably in earlier versions)
> could not even compile signals. bcc32 is old Borland compiler, bcc64 is
> based on modern CLANG/LLVM...

Thanks, Alex. Unfortunately bcc64 is not an option for this project, because i have to use a dll, which is not available for 64bit..

Any one else? Any help is appreciated!

Bye, Marc.

> {quote:title=Eike Petersen wrote:}{quote}
> You are welcome. I take it then, that this bug is still present in XE4 - that`s really sad. That means that with default-options you cannot build a working application using Boost-DLLs. This is not limited to the "signals"-part of Boost, it will happen in all other libraries, too.
> 
> Maybe someone should create an own QC-entry for this...

I ran into this same problem a while ago and opened a QC entry: http://qc.embarcadero.com/wc/qcmain.aspx?d=91850

If you're willing to edit C++Builder's version of Boost, you can edit Boost's borland_prefix.hpp to fix the problem there without having to update your own project files.