Jump to content

Gord P

Members
 View Profile  See their activity

  • Content Count

    65

  • Joined

  • Last visited

Posts posted by Gord P

  1. Posted · Edited by Gord P

    I don't use 64 bit yet and I haven't installed 12 or 12.1 yet, but I thought I recalled from from the webinar below they said that they were moving away from ilink for the linker in 12.1.  So I'm not sure why it is says there is an error with ilink.

     

    While you wait for someone who actually knows what they are talking about to chip in here , I would check the C++ linker options in the Project|Options menu to see if something is set incorrectly there.

    (edit: that wasn't a slight against bdw_nz20 - I was referring to myself)

     

     

     

     

     

  3. Posted

    Yes I recognize asking which is the best way can be tricky and subjective.  I was just trying to make sure I wasn't using something that was generally considered obsolete, and as far as I can tell it isn't.  Thanks for your comment and good point on encoding.

  4. Posted

    I came across this article by Yilmaz Yoru on the Embarcadero C++Builder Community site:

    How To Read And Write Text Files In A Modern C++ App - March 28, 2022

    In the article he only talks about ofstream and ifstream.  No mention of TFileStream.

     

    However, in an article two years earlier (Windows File Operations in Modern C++) he does seem to promote TFileStream.

     

    I guess there is no real must-do way.  I suppose sticking with the fstream methods is more portable.

     

     

  5. Posted

    I am updated an older C++Builder program.  In it I use ifstream and ofstream for reading and writing text files, which then get parsed to extract various pieces of data.

     

    It works well enough but I wonder if I should be using TFileStream going forward.  What are the advantages, if any, of using TFileStream?

  7. Posted · Edited by Gord P

    Thanks Uwe.  I should have put in a request a long time ago for it.  I tried going back in to see if someone else had put a request in for that but couldn't login even though it said the site was in "read only" mode until the migration was completed.

     

    Currently, to ensure the user has entered a proper float value (allowing for 1.0E10 type of input) I simply handle it after the fact (i.e. after some OK button or CALC button or whatever has been clicked) by using TryStrToFloat() on the contents of the Text string from a basic TEdit and displaying a message if it is not a valid float.

     

    I would like to be able to do the checking while the value is being entered similar to what TNumberBox does in how it restricts the user to only using valid characters - except allowing for 'e' or 'E'.  One challenge I see with that is that someone might incorrectly enter an 'e' at the end of the number (eg. "1.234E") which is not a valid float.  Might have to just check OnExit but that might lead to awkward behavior.   Anyway, just thinking out loud.  Thanks again for checking.

     

     

     

  9. Posted

    5 minutes ago, Lars Fosdal said:

    Why would you try to shoehorn 3D graphics into a 2D framework?

    It is obviously doable - eg. GLScene that Shineworld previously quoted.  (Then you might ask why not use that -  but that has its own issues, which is why I think Shineworld specified "Embarcadero managed ... (Sorry if I am putting words in your mouth)).

     

    Also, The pro version of TChart handles 3D fine.  Personally I am looking for 3D chart capabilities but at this point don't want to shell out dollars for a yearly subscription for the pro version.

     

     

  10. Posted · Edited by Gord P

    8 hours ago, shineworld said:

    6. an Embarcadero-managed OpenGL / Vulkan library, like GLScene, for VCL.

    7 hours ago, Lars Fosdal said:

    6. FMX already has that covered?

    He specified for VCL.  And I second that.

    (although I recognize posting wishes here is next to useless - but it is interesting to see what people are looking for).  

  13. Posted

    I read this poking around on the Discord site from Ian Barker:

    Quote

     

    Well, technically, at the moment, C++ Builder 12 only does Windows. Earlier versions of C++ Builder can do more.

    Right now the only way to target Windows, iOS, Android, Mac, and Linux is with Delphi or RAD Studio using Delphi.

    Embarcadero are working on resolving those issues with C++ but it's a long slog with some technical hurdles to climb to get things back to where we'd all like them.

     

     

    That's interesting.  Doesn't affect me at the moment because I currently only target Windows, plus I don't use the latest version until at least one update or a couple patches are out.  But, it does seem like a regression in the feature set of C++Builder nonetheless.

     

  15. Posted

    19 hours ago, David Heffernan said:

    Those libraries will be appallingly slow.

    I suspected that.  That was nice about using the 80 bit doubles.  From what I understood, there wasn't a huge performance hit.  I was about test all that out, but now I think I will stick with the doubles for now.

  17. Posted

    22 hours ago, David Heffernan said:

    Not in IEEE 754 floating point data types that you are using.

    The number I quoted is the actual (true) value for 1/7.  But yes, in a binary system you don't get that.  Which is why I used TExtended80Rec to see what the value in the long double variable equated to.

     

    22 hours ago, David Heffernan said:

    Anyway I'm not actually sure what your actual problem is. Do you feel that there is an issue with the debugger?

    The debugger does not display the value that the variable actually contains to the precision it should be able to (and could if it used something akin to sprintf()) - as per my first post.

     

    22 hours ago, David Heffernan said:

    As for 80 bit floats I don't see any future for them. That idea died and everyone uses 64 bit double now.

    Yes, that is unfortunate and is what I was referring to in my second post.

     

    22 hours ago, David Heffernan said:

    Is double insufficient for your needs? 

    That is a good question, and one I was trying to sort out.  It is not a matter so much of whether it is insufficient, but whether things could be improved with additional precision.  I have been using doubles forever and it has been fine. But there are cases where there is numerical instability and I wonder if more precision would help.  But, there are always ways to get around it and because of the previous point, those will have to suffice.

  18. Posted · Edited by Gord P

    I fooled around a little bit with TExtended80Rec and found that the value held in the double (ld3) equates to: 

    0.14285714285714285712736854039306422........

    I have bolded the part before it goes off the rails.  So sprintf() presents it well.  I don't have Delphi to see if their corresponding function is part of the problem (I think they write Rad Studio in Delphi but I could be wrong about that).

     

    Anyway after having said and done all that I think the bigger issue for using long doubles is the fact that in Win64 they are not supported.  To be more accurate, they are just the same as doubles (8 bytes).  Kind of pointless. At some point I will be migrating over to 64 bits so I would lose the precision then.  

  19. Posted

    Using C++Builder 11.3, 32 bits, VCL.  Problem is same for classic or clang compiler.

     

    Some simple code shows the issue: 

    void __fastcall TForm1::FormShow(TObject *Sender)
{
    long double ld1, ld2, ld3;
    _TCHAR bufStrg[128];

    ld1 = 1.0;
    ld2 = 7.0;
    ld3 = ld1 / ld2;

    swprintf(bufStrg, L"Long Double = %.20LG", ld3);  // better than FormatFloat for displaying long doubles
    Label1->Caption = String(bufStrg);
}

    The true value of 1/7 is 0.142857142857142857..., where 142857 repeats itself forever.

     

    If you set a break somewhere after ld3 is calculated, and look at either the Inspect tool or the Watch window, it shows the value of ld3 as 0.142857142857142864.

    image.png.11b3e8433985d725006a5a660b309768.png

     

    But if you let the program run, it displays the value on the form as

    image.png.6d938d2f2023a4feee44206aeb08c613.png

    Which is as good as you will get for a long double.

     

    After putting the variable through a few calculations and inspecting the results, I concluded that the value displayed on the form is indeed what the variable is holding and not what the debugger says it is holding.

     

    I will put this into QP unless shows me something that I am doing wrong here.

     

    I noticed this issue a fair number of years ago but didn't pursue it because I didn't need to use long doubles.  Now I want to use them and was surprised this issue still persists in a much later version.  I would have thought there would be lots of people using long doubles that would not be happy about this.  There was report on QP about this for the 64 bit compiler but it is closed and says it was fixed in v 10.1.

     

    image.png

  22. Posted

    I ended up implementing a conditional AxisValuesFormat as follows

      

        double aNumber;
    int aExp;
    int order_of_mag = 2;
    
    // get aNumber somewhere (such as MaxXValue())

    aExp = int(fabs(log10(aNumber)));
    if (aExp > order_of_mag) Chart1->->LeftAxis->AxisValuesFormat = "0.00E+0";
    else Chart1->LeftAxis->AxisValuesFormat = "#,##0.###";

     

    It's not the end of the world to have to implement something like this.  Not looking for a ton of performance at this place in the program.  You can change order_of_mag to any order of magitude you want to start using scientific notation.  Haven't tested it thoroughly yet to see if captures every scenario.

     

  25. Posted

    I am using TChart which has property called AxisValueFormat for each axis.  It is the same as FormatFloat from what I can see.  This is somewhat restrictive it seems.

     

    I have numbers that can be rather large (10^8), miniscule (10^-8), or in between (123.45).  With C or C++ this could be handled easily with %G.   However with FormatFloat it appears that you can have either scientific notation all the time (#.###E+00) or regular notation all the time (#.#####) but there is no way to set it up to automatically switch between the two depending on the number.  

     

    If my graph has numbers between 0.1 and 1, I would rather have the axis labels look like 0.1, 0.2, 0.3, etc. as opposed to 1.0E-01, 2.0E-01, etc.

     

    Is there way to do this easily with FormatFloat, or am I going to have to conditionally set the AxisValueFormat string depending on the mantissa that I will have to extract from the values?

×