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)

I read this poking around on the Discord site from Ian Barker: 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.

Not to pile on but I am going to pile on since it has been brought up. The search does not work well at all. It is fine for single words but not well for multiple words. At least in my experience.

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?

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.

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.

I have not installed version 12 yet, but I am wondering if the TNumberBox control is still unable to recognize 'e' or 'E' (for exponent) when entering a number in the box when the mode is set to nbmFloat.

Thanks for that Uwe! I will take a look at that.

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.

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.

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

As usual, I can never make these webinars because of commitments. Look forward to the replay though.

I will go with that 🙂

Rad Studio Wiki is up and running for me

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. But if you let the program run, it displays the value on the form as 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.

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.

Thanks no I haven't. There also the Neslib.Multiprecision Library that I haven't checked into either.

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. 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. Yes, that is unfortunate and is what I was referring to in my second post. 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.

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.

Could you expand on that a little bit please? And does that apply to C++Builder as well?

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?

That is true. Where as what I want to see is: 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.00E14 2.00E14 3.00E14 4.00E14 5.00E14 6.00E14 7.00E14 8.00E14 9.00E14 1.00E15 Which, AFAICS, requires an 'if' statement

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.

Thanks for the suggestion. Just tried it but it didn't work. Doesn't change it scientific notation when the numbers are really large.

That works with Format but not FormatFloat which is what AxisValueFormat is (I'm pretty sure).