Jump to content

Roger Cigol

Members
  • Content Count

    303
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Roger Cigol


  1. 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)


  2. 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.


  3. 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.

    • Thanks 1

  4. 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).


  5. 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).


  6. I have a working class to interface to a COM interface (created by a 3rd party). My working class is a wrapper around the type library functions I generated using C++ Builder. This code works 100% when compiled under C++ Builder 10.4. I have just used the same class in a new application running on the same machine as the working system but this time compiled using 11.2 patch 1. This doesn't work. The problem seems to be in passing pointers to BSTR. I use WideString.c_bstr() to get the pointer to the BSTR to pass to the COM interface. 

    QUESTION: can anyone confirm that this approach works ok using 11.2 ? (or should I be looking into this at a lower level with a view to creating an Embarcadero RSP bug report?)


  7. 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 !


  8. I have a C++ Builder application that is in two parts - a dll and a main exe. This has all been working fine with version XEn ... 10.0... 10.1... 10.4.... etc (and maybe 11.1 too).

    But when I compiled it with 11.2 patch 1 I found it compiled without errors but didn't run. I traced the problem to DllMain() not being called when the dll is "attached" as the exe

    file loads. When I changed this from DllMain() to DllEntryPoint() it all started working again. (Phew!).

    This page:

     

    https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Creating_DLLs_in_C%2B%2BBuilder

     

    Suggests that there is an option (check box) called VC++ which selects either DllMain() or DllEntryPoint(). 

     

    But I can't find this option ! anyone know where this is for version 11.2 patch 1 ?


  9. 1 hour ago, Der schöne Günther said:

    Why do you need to convert them to another language? Can't you build the C++ stuff as a separate library or process and then use that from your Delphi application?

    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......


  10. 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? 


  11. 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 !


  12. 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!)?

     

     

     

×