Home/ Questions/Q 8017525
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T20:52:14+00:00

I have some code that puts a bunch of TNotifyEvents in a vector .

  • 0

I have some code that puts a bunch of TNotifyEvents in a vector.

std::vector<TNotifyEvent> m_availableCallbacks;

This is a member of the main form of the application. In the forms constructor it’s filled with the events.

m_availableCallbacks.push_back(ReadoutLastValue);
m_availableCallbacks.push_back(ReadoutCurrentDay);
m_availableCallbacks.push_back(ReadoutLastDay);
m_availableCallbacks.push_back(Readout7Days);
m_availableCallbacks.push_back(Readout1Month);
m_availableCallbacks.push_back(ReadoutChooseTimeSpan);
m_availableCallbacks.push_back(ReadoutAllData);

This vector is then iterated and used to create a popup menu and assign notification events to the elements in that popup menu.

Compiling this locally poses no problem. When I compiled it on the build server (running TeamCity 6.5) I get an internal compiler error on the row equal to the second push_back call.

I tried disabling smart cache precompiled headers locally on the build agent by editing the cbproj files. This produced a successfull build. So I removed the directive to use smart cache precompiled headers from all cbproj files and committed the changes. I told TeamCity to do a Clean Checkout and once again I got the same internal compiler error, at the same place. The strange thing is that running a new compilation after the failed one succeeds, so this feels extremely random.

What is going on? I’m used to passing around function pointers (crated by myself) in other C++ compilers just fine. Is the internal handling of the TNotifyEvents broken or is the compiler just unstable and easily broken?

Looking at other code taking TNotifyEvents they don’t work on references or pointers, so I didn’t try that. And since the code (when it compiles) works as intended that does not seem to be the problem.

Update:

I can add that the log for TeamCity says that the FrontEnd.cpp file (which contains this code), is skipped when I re-run the compilation and it succeeds.

[10:04:37]: [MakeObjs] CallTarget
[10:04:37]:   [CallTarget] _CppDepCheck
[10:04:44]:     [_CppDepCheck] MessageMap
[10:04:44]:       [MessageMap] Skipping: ..., FrontEnd.cpp, ...

And for that to even work the compilation must have succeeded when the internal compiler error occurred. How could it otherwise skip compiling the file and still have it magically appear and be used in a compiled form? 🙂

Update2

After investigation I can confirm that this ONLY occurs when compiling in release mode. In release it happens even on my local machine in the IDE.
I have tried fiddling with the settings like

  • Disable all optimizations
  • Generate fastest code possible
  • External type files
  • and so on

cleaning the build between each try.
But the ICE does not go away. I did however manage to make it complain about another spot in another file. Setting the settings back to how they were before does NOT make the error go back to the FrontEnd.cpp file. This compiler feels kinda shaky 🙂

In fact I started getting ICE’s all over the code and had to restart the IDE to be able to compile anything at all.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This seems to be connected with the std::vector. Not sure if it’s broken by itself or the way it’s handled by bcc is the problem. But switching to an C-style array as a test instead made the ICE go away and it now works fine in both debug and release mode.

    TNotifyEvent m_availableCallbacks[7];

    I wanted to avoid this since adding new events to the vector would involve almost only one line of code. Now there will be a bit more to remember to change as well. But, better to have the application compile.

    If I’m wrong thinking that this is a bug in BCC, please correct me so I can go back to using a vector asap :)… Otherwise I hope Embarcadero fixes this asap.

    • 0