Jump to content

Roger Cigol

Members
  • Content Count

    412
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by Roger Cigol


  1.  I changed one line of code and suddenly one of my important (ie live development for customer) projects won't link: giving "out of memory". It's a clang64 windows VCL building on 11.2.  I normally have to fiddle with the heap settings when this happens. But this time the "Tools | Options | Compiling and Running | Verbosity -> set to "diagnostic" doesn't seem to give me any different output from the normal (just "out of memory") so I can't see which heap values are causing the problem. Is this a known regression? It seems as if this Verbosity setting doesn't have any effect on the output given by the linker. I have tried with and without TwineCompile enabled. 

    I am still on 11.2 (patch 1). There seems little to gain by changing to 11.3 for us C++ users. Unless someone can tell me that this "Verbosity" setting does work on 11.3.......


  2. I find the same with the clang code completion - it sometimes works and sometimes doesn't. I know Embarcadero are aware of this and are trying to make it better. However I think the new approach that is coming (as per David Milington's recent blog) promises to get this properly sorted. It's an essential feature in the world of modern C++ IDEs. If you haven't read David's blog - here's the link:

    David's c++ the future blog


  3. My experience is that for legacy projects, unless you have a really good reason to change (ie a major new requirement where you'd like to use modern C++ code constructs) then stick with Classic. I still use Classic for significant (to my customers) projects. It does build much faster than the clang compiler. I most definitely wouldn't dream of using clang without the benefit of TwineCompile because the build times would become unmanagable. I wonder why you can't get TwineCompile to work with your classic compiler? I use TwineCompile for all projects and wouldn't want to be without it. I've never had a problem with a classic compiled project working/not working with TwineCompile. {too many negatives: I mean: Classic compiler projects always work with TwineCompile for me).


  4. Working with Alexandria 11.2 - I am using a C++ builder Win 32 "classic" VCL project. If I use project options and specify a "custom" windows manifest file it allows me to specify a full path to a manifest file that I can manually create (and the IDE encourages me to use an extension *.manifest). If I enter a full path to a custom manifest file but (owing to my mistake) this manifest file does not exist the project still builds my *.exe target file without reporting an error. But (obivously) the resulting *.exe file cannot include the custom manifest information that I intended. I would have expected a linker error "can't find manifest file xxxxMyCustomFileNameHerexxx.manifest" rather than letting my mistake pass through unnoticed.

     

    Can anyone else confirm that they get the same behaviour (also with a Delphi VCL 32 bit project ?)....


  5. 
     
    
     

    The EditCharacterEntry->Text is a Unicode string (remember it would be possible for someone to enter several characters (including characters that can't be represented as C++ char type). So the first thing you need to do is to convert this to an 8 bit char string. Any easy way to do this is to construct and AnsiString from the Unicode String. So you use AnsiString(EditCharacterEntry->Text). This will lose (ie corrupt) characters that are Unicode and can't be represented in Ansi. Next you need to get the first character of the AnsiString. In a VCL framework application the first character has an index of 1. So you use     char ch = AnsiString(EditCharacterEntry->Text)[1];

     

     


  6. Hi Remy, Thanks for your valuable input. I am aware I haven't offered a "minimum reproduceable error" set of code for my posting. This is my next step - just two threads - one passing a number to the other using my interface class. I will do this later this week and post it up here (assuming I get the same error). The code I do have which is showing the problem is a googletest framework unit test which seems to run ok on gnu/linux but not on Embarcadero - but I agree this could still be a bug in my code.....


  7. template<class A>class TThreadDataInterface_TS
    {
    private:
       std::mutex DataMutex;
       A ThreadSafeCopyOfData;
       A &operator=(A RHS); // declared private - not defined - prevents use of = operator
    public:
       void Read_TS(A &Data) // read (copy) Data out, thread safe, no handshake of data
          {
             try {
                const std::lock_guard<std::mutex> Lock(DataMutex);
                Data = ThreadSafeCopyOfData;
             } catch (...) {
                A UninitialisedData;
                Data = UninitialisedData;
             }
          }
       void Write_TS(const A &Data) // write (copy) Data in, thread safe, no handshake of data
          {
             try {
                const std::lock_guard<std::mutex> Lock(DataMutex);
                ThreadSafeCopyOfData = Data;
             } catch (...) {
             }
          }
       TThreadDataInterface_TS(void){}
       TThreadDataInterface_TS(const A &InitialValue){
          ThreadSafeCopyOfData = InitialValue;}
    }

    I have ported the above template class from a GNU / Linux working code base to an Emabarcadero Clang 64 bit Windows console program. It's a template class for use communicating data (type A) between two threads. The GNU/Linux code did not have any try / catch statements in and worked fine. When I ran this code using Embarcadero Clang64 I found that most of the time the locking worked fine but sometimes the line "const std::lock_guard<std::mutex> Lock(DataMutex);" caused an exception to be thrown (and since this was not caught anywhere the program abnormally terminated). I added the try /catch that you see above and now the program runs without aborting - but as you can see from the code on the rare times that an exception is caught the data transfer doesn't work smoothly. The bottom of this page:

    CPP ref lock_guard constructor seems to state that "if m is not currently locked by the calling thread, the constructor never throws exceptions (no-throw guarantee)." I am sure that my thread has not previously locked the mutex so I am puzzled as to why I am sometimes (1 in a 100?) getting this exception. Has anyone got any thoughts on this ?


  8. You can use TEdit or TLabelledEdit for basic user input, along with a myriad of other visual components to get input from a user. Similarly for output. The basic "Message Box" is not a C++ Builder feature but part of the operating system (assumed to be Windows since you don't say otherwise). C++ builder VCL does provide a convenient "wrapper" for the operating system message box: 

    https://docwiki.embarcadero.com/Libraries/Alexandria/en/Vcl.Forms.TApplication.MessageBox

     


  9. What C++ compiler are you using?

    Can you post the contents of form file (*.dfm) that corresponds to the two components TGridLayout and HorzScrollBox1. (or create a complete form that is a minimum not-working example) and paste the entire *.dfm file).


  10. I am a professional developer (for industrial control systems) and use Embarcadero C++ (mostly using the VCL framework) extensively. Yes, Microsoft dominate the Windows C++ arena, but Embarcadero C++ with VCL is a great tool.

    Post questions in the C++ sub forum here on Praxis and (provided you clearly explain your challenge) there is a good chance you will get an answer.


  11. I've seen this happen  if you have two copies of a c++ *.h header file open in the IDE (in two separate windows). You edit one copy and then later save the other uneditied copy and overwrite the changes. Not sure if it's possible to have two copies of the same pascal + *.dfm unit open or not. Just something to check though....

    I've also had a multiple projects issue where different projects refer to the same file. If you at some point move the directory in which the file is in and then only update some of the projects you accidentally introduce two copies of what should be only one file. This has happened to me a couple of times and caused great confusion ! Just another thing to check - make sure full path of the file is the same in all the projects.....


  12. Hi Gunther, The only interest I have had on here is fully visible on here ! I have an issue in that I have no time and no inclination to sift through large numbers of hopeful "straight from college" type of applicants that I would expect to get were I to post somewhere more obvious (and all of the candidates would be decent folk who deserve decent consideration and courtesy and respect). So I figure by posting here at least anyone who expresses an interest will know the Embarcadero IDE and will at least be a "distinctly possible" - ie using this site acts as a first level filter. But it does seem that very few C++ folk are using Embarcadero.

×