Roger Cigol

All C++ compilers (to my (limited) knowledge) mangle names (because it's the obvious way to track arguments and return values). But it is possible (perhaps even "likely") that clang32 and clang64 adopt the SAME mangling scheme. If this was the case, your need for a separate def file for each compiler would disappear.

To make sure we understand what you are trying to do. You are trying to use the DEF file to specify to the linker which functions to export (and the names of the functions you want them exported as). <can you confirm this, please?> Can you confirm that you are using the clang32 compiler for your 32bit code (if not then first thing to try is to use the clang32 compiler - maybe it's name mangling will be the same as the clang64 (I haven't checked this)). I am wondering if another approach might work (as suggested by @David Heffernan)

I would plump for "doesn't exist". BCB6 had very little (no?) support for unicode

I would really want my compiler to give me a warning if I wrote this line of code. It's not at all clear what you want to happen (and as @hansw says it is undefined behaviour - although it is likely to be consistent for any one given compiler (my guess only!)). In the interest of good program practice and to help your self write maintainable code please split this into two lines to make it easy to tell what is intended to be achieved.

Good to mention that you are using Oracle Virtual Box. I see no reason for this to prevent you from installing community edition (I can confirm that the full version of RAD Studio does install and run ok in Oracle Virtual Box). Can you reach the internet from within your virtual box (ie open web sites with a browser) ?

I definitely agree with this (even though I am not quite sure who I am agreeing with !)

I agree with @Attila Kovacs < not! >

I agree with @Attila Kovacs Irony and Sarcasm are rarely helpful in a forum such as this. Good in pubs when discussing over a beer or two perhaps. If I feel a need for a bit of sarcasm I try to remember to add a hint such as < not! > after the sentence. By the way I am in the category of using EBT for "useful" rather than "beautiful" software.

I have now confirmed that with RAD Studio 10.4.2 I can get my COM interface to work correctly when compiled with either "Classic" or Clang32 compiler. And to repeat: neither compiler produces working results when compiled with 11.2.

Yes. I agree exactly with your diagnosis. It looks to me as if something has changed with the TAutoArgs or OleFunciton() handling of the BSTR type with the "jump" from 10.4.2 to 11.2.

Thanks to all for input. SINCERE APOLOGIES : I accidentally created a "red herring" when I quickly replaced the actual test label path (which is long with lots of customer sensitive directory names) with "C:\FullPathToLabelFile.lab" and forgot to use the double \\. The actual label file path is correctly formated (ie includes \\). @Lars Fosdal The 10.4.2 (working code) uses the classic compiler. The 11.2 (patch 1) code does not work with either the classic compiler of the clang32. I am running this on a remote PC (at the customer's premises) and need to interrupt their production to use the PC so testing is a bit tricky (and it also feels like I am hanging out dirty washing for everyone to see, each time I do a test and can't get it to work). I didn't think to try compiling under 10.4.2 using the clang32 compiler. I will try to do this next time I "log in". [ I use Supremo for remote access to the PC ]. @Remy Lebeau By using the IDE debugger I have confirmed that the BSTR inside the call to Open() does indeed contain the correct label path. I accept all your other observations as good programming hints (although constructing a String (aka UnicodeString) by passing a constant array of 8 bit chars can't be a bad thing - as long as the 8 bit chars are all simple ASCII chars). But they are not the cause of my interesting problem. I don't feel a need to check for the [ exceedingly unlikely ] failure of the internal call to the Win32 SysAllocStringLen() function because if this does fail the resulting error of "Can't open the label file" is going to be good enough. The key thing is that when the BSTR passed to Open() is a valid path to the file then it needs to work (as it does under 10.4.2).

We have been chasing this problem. The COM interface we are talking to is for the CodeSoft printer software (supplied by Teklynx). We have this bit of code String LabelName = "C:\FullPathToLabelFile.lab"; ResetFloatingPoint(); // our function to reset FPU flags CodeSoftDocument = CodeSoft->Documents->Open(WideString(LabelName).c_bstr(), 0); if (!CodeSoftDocument) { MostRecentError = LPE_CantOpenLabelFile; } else { MostRecentError = LPE_Ok; } If we compile this under 10.4.2 we get MostRecentError = LPE_Ok. (and the label prints) If we compile this under 11.2 we get MostRecentError = LPE_CantOpenLabelFile (and no label). If trace this down into the wrapper for the type library we find the definition of the Open() function as follows Labelmanager2_tlb::IDocument* __fastcall Open(BSTR strDocName/*[in]*/, VARIANT_BOOL ReadOnly/*[in,def,opt]*/) { TDispID dispid(/ Open / DISPID(7)); TAutoArgs<2> _args; _args[1] = strDocName /*[VT_BSTR:0]*/; _args[2] = ReadOnly /*[VT_BOOL:0]*/; OleFunction(_dispid, _args); return (Labelmanager2_tlb::IDocument* /*[C1]*/)(LPDISPATCH) /*[VT_DISPATCH:1]*/_args.GetRetVariant(); } CodeSoft has a debug mode - and this shows us that under 11.2 the label file name is being interpreted as a NULL BSTR (hence it can't open the label file).

Go for it. If you pass you feel good and you have something to put on your CV. If you fail it is probably more useful as a) it makes you less likely to be arrogant. and b) it gives you areas that you can focus on to learn more and hence stimulate your mind and perhaps become a slightly better more experienced programmer....

Still looking...... (and happy Christmas to all Embarcadero users out there)

I just use an TFDQuery with the SQL statement set to SQL CreateTable statement (created either at design time or at run time as suits your needs) and then call Execute() method of the TFDQuery

Hi Remy, Well that would explain why I can't find it ! But it doesn't explain why I've suddenly had to change a working using MainDLL() project to having to use DllEntryPoint() in order to get it to work. My own notes suggest that the last time I rebuilt this project was 11.1.5 - so I suspect the change has happened just with 11.2 Any way thanks for your help. As I have solved the problem it's probably not worth further chasing !

Certainly not my intention to do that. Of course there are other source control solutions too. My intention was to point out that trying to do version control / source control manually is rarely (if ever) a sensible use of someone's time these days. Sorry if I sent out wrong "messages" here....

Solving all this versioning issues is exactly what git was invented for and exactly what it does so well and so easily (espeically if you install tortoise git into windows). It's all out there for free and takes a day or two (max) to get the hang of.

You can only do this if you have RAD studio - ie the version with both Delphi and C++. It may be possible to build a separate library with a separate build system (eg GCC or MSC++) and then call this from Delphi - but I would expect lots of effort required to get the naming and parameter passing all working ok. I would be wary about going down this route......

You can purchase RAD Studio - which gives you both Delphi and C++ Builder. Be careful with the statement " most c++ libraries do not compile with c++ builder" - Some do, some don't - "most" is an unhelpful adjective here. If the ones you want to use compile that's what you want..... C++ multi-platform is weaker than Delphi - not having Android is a real shame. Going back to your original question "Do you think Embarcadero would let me switch my license from Delphi to C++ builder?" - This is probably a very unusual request (and I am sure they would try to sell you an "upgrade to RAD Studio (ie add C++ builder)" rather than a straight switch. What would happen to all your current delphi projects?

I am grateful to Glenn Dufke for pointing out the following video - long but worthwhile ! I add my youtube comment here as a way of starting a discussion: A great presentation (especially liked a guru like you failing to get the gcc to run!). Very ambitious vision - but it's good to "aim high". Could a compromise be to have a Cpp release that prohibits (not just deprecates!) the "unsafe" historic features (eg union, pointer arrithmetic, new/delete etc etc), forces use of bounds checking and std::span but without introducing the new syntax? Might not be so elegant and would not reduce your "teaching load" so much but might get through the inevitably cumbersome standards committee? Or do you realistically see Cpp2 as a fork away from the standards committee (sorry to be so heretic!)?

I live in that world ! But tell me what GUI you would use with Rust that comes close to VCL or FMX ?

It is true that C++ has evolved greatly. Actually in almost all cases it is backward compatible (and the few cases it isn't are often particularly flakey coding edge cases). There are some serious brains greatly improving the concepts behind writing sound code working on C++. It's fascinating (but time consuming) learning (and understanding) about the thinking behind some of the additions. The thinking behind sticking to C++ is a) access to a lot of third party libraries. b) not tied to one particular vendor's compiler (there are three compilers still very active out there: MSC++, GCC and Clang). c) There are many more C++ programmers out there than delphi. Of course b) is a great self deception: the extensive use of the (still beautiful after all these years) VCL framework does tie me to Embarcadero - although much of my more recent (in the last 10 yrs) code has good separation between the GUI and the "nitty gritty business" code the GUI is still an area that takes a lot of time to get right (ie how the customer likes it) so it would be very painful to swap to one of the competitors <but not impossible>. Of course c) is a great self deception as all the good C++ programmers have good jobs ! and actually a) is true but as yet I don't use a great many 3rd party libraries. ...... so perhaps you are right !

I don't see an Embarcadero Rust VCL/FMX appearing any time soon.....

A very valuable posting has appeared on Stack Overflow regarding using Google Tests with Embarcadero C++ clang compilers. Thank you to T. Herzke for sharing this. More useful info on C++ google tests unit test