I am saving a series of floating point numbers in CSV. I heard that under some European locale, the decimal point in floating point is actually a comma, I was wondering if I release this product in a European market, will my library have trouble parsing the floats since my decimal point is a full stop, not a comma.
Does anyone encounter this problem in those locales? How do you handle it?
Any decent CSV library should take care of this by quoting anything containing the field delimiter (in this case, comma).
I just did a simple test with LibreOffice Calc:
* entered 123.45 and 246.80 in the first two cells.
* changed its locale to German
* saved as csv
The result: "123,45","246,80"
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
Thank you for your reply. How about parsing float numbers with full stops in German locale? I am not sure if the C++ stof() handles it since the C++ Reference page states it is determined by the current C locale.
Yes many ways, but you will need more information before you can start. Firstly you need to understand the format of the data in the "hex" file. Then you need to understand the instruction set (and format) of the plc language. Once you understand both those things you can start to design your converter.
Get any HEX editor, like HxD[^], and install it. Now go grab the Notepad.exe file from C:\Windows and open it in the hex editor.
Now you're looking at a whole of bunch of bytes that make up the content of the file, and you need documentation to tell you what every one of those bytes means. You're going to start here[^] to figure that out.
Oh, and when you get to actual executable code, you're going to have to understand the Intel instruction set, all the addressing modes, and the operands each instruction requires. All of that is in the bytes that make up the executable code. Notice, you're not going to get back C/C++ code. You're getting back assembly code.
Once you're brain melts from trying to understand all that, now you have to do that same thing for the .hex file you're looking at for your PLC's. Oh, and you'll need all the relevant documentation similar to this example of disassembling Notepad.
I am trying to add "forms " to my exiting project.
I follow the Qt menus... but I do not know how to modify my constructor.
, ui(new Ui::MainWindow)
isUntitled = true;
Please help me to understand what Qt did and how to modify
my constructor so I can access my "form".
The verbal description / code annotation would be appreciated.
It is a single parameter constructor of the MainWindow class. The constructor accepts a single parameter which is a pointer to a QWidget object. The constructor sets its QMainWindow property to the input parameter - in this case the pointer named parent. It then sets its ui property by calling the Ui::MainWindow constructor, to create a new object of that class. To find out what the latter returns you need to look at the Ui class documentation.
But maybe you don't want to actually implement a terminal application? In which case, either I've misunderstood your query, or you need to reframe your question to better reflect what it is you are trying to do.
Thanks for reply. I am actually looking for "discussion forum" . I am running out of ideas how to fix my problem.
Yes , I did try qterminal - it has no option to run command with options - so I ended up with xterm.
It works OK, but I cannot figure out how to FULLY integrate it with my application.
I am able to display the command output in my app "window" but it is NOT really my app window - some folks call it "xterm native window ".
So I can display it - it is "inside my other window" , I can move it , using my app "wrapper window", but I cannot process anything in it.
I am actually hoping that somebody with good grasp of "windows hierarchy" can shed some light on this.
In not so techie terms - how do I process data in xterm native window ?
I will take a look at xterm man again, maybe the answer is there.