View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0038274 | FPC | RTL | public | 2020-12-29 15:04 | 2020-12-30 17:13 |
| Reporter | ravi dion | Assigned To | Michael Van Canneyt | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 3.3.1 | ||||
| Summary | 0038274: Add IOUtils routines for convient file access | ||||
| Description | For instance, IOUtils.TFile.ReadAllLines to read content from a file see http://docwiki.embarcadero.com/Libraries/Sydney/en/System.IOUtils | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| FPCOldBugId | |||||
| FPCTarget | |||||
| Attached Files |
| ||||
|
|
We have a bounty out for the complete implementation of this unit. |
|
|
Does that mean it'll come soonish? Where is the bounty? |
|
|
I took at quick look at those classes and most of all those functions already exist in other common units fpc has, but I would suggest making a wrapper class around the existing ones instead of recreating more bloat on the libs.. Of course for members that have no equal you would then need to implement it fully in this wrapper. But I have doubts about the fitness of the compiler's ability to inline this code properly to alias the calls to a already existing RTL call without it simply recreating a complete function. |
|
|
The bounty is handled by the Free Pascal & Lazarus foundation. Normally Mattias Gaertner will do the implementation, but I have no timeframe. |
|
|
@Jamie: this unit is there for Delphi compatibility. As such, 'bloat' is inevitable. |
|
|
have you looked at what is already in Lazarus? The FileUtil for example, which brings in a boat load of code from the LazUtils and so on.. There are too many redundant units.Code as it is, I think its time to start consolidating. |
|
|
The contents of Lazarus' fileutil can maybe be reused, but that does not solve Delphi compatibility. Some amount of duplication is inevitable, but where possible, we'll try to adhere to DRY, obviously. If Mattias feels like adding 'missing' things in IOUtils in order to be able to abandon lazarus' FileUtil, then so much the better... |
|
|
> But I have doubts about the fitness of the compiler's ability to inline this code properly to alias the calls to a already existing RTL call without it simply recreating a complete function. FPC does not have any problems with inlining a simple forwarding call (at least as long as it doesn't fall into the usual restrictions, for example no open array arguments). But even if it does not inline it, it's only a simple call that consists of the prologue, the call itself and the epilogue which all in all should be around 20 instructions. There is more important “bloat” to worry about than that. |
|
|
I don't want to turn this into a battle of wits however, I took a good look at the LazFileUtil unit the other night and that needs some serious rework. It's loaded with redundant code and has little regard to follow the rtl for path delimiters and the like and lots of repeat code.. It even has a "IsDirectoryWriteable" that actually creates a fixed file name and just writes to it? What if there were a file there of the same and what if you were doing this in a loop and specially to a SSD or Flash stick where recent concerns have been risen lately and the speed of this taking place each time, etc.. Also Delphi has a lot of jumping around where it can condense this issue and speed things up. I know the compiler has smart units but frankly speaking I have not yet seen it actually work, it always brings in the whole payload. |
|
|
> I know the compiler has smart units but frankly speaking I have not yet seen it actually work, it always brings in the whole payload. Smart linking does work cause otherwise the binaries would be much larger. If the compiler does not drop something then there is a reason for it (for example the widgetset interface of the LCL can't be easily smartlinked due to its design). |
|
|
@jamie: LazFileUtils has lots of duplicate code because it wa meant to handel UTF8 at a time that fpc did not have appropriate UnicodeString versions of their IO functions. And it has code that later (in somewhat altered version or name) made it into fpc. Feel free to supply patches for that (in the Lazarus pasrt of this bugtracker of course) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-12-29 15:04 | ravi dion | New Issue | |
| 2020-12-29 15:58 | Michael Van Canneyt | Assigned To | => Michael Van Canneyt |
| 2020-12-29 15:58 | Michael Van Canneyt | Status | new => assigned |
| 2020-12-29 15:58 | Michael Van Canneyt | Note Added: 0127894 | |
| 2020-12-29 16:27 | ravi dion | Note Added: 0127895 | |
| 2020-12-29 17:04 | jamie philbrook | Note Added: 0127903 | |
| 2020-12-29 17:05 | Michael Van Canneyt | Note Added: 0127904 | |
| 2020-12-29 17:06 | Michael Van Canneyt | Note Added: 0127905 | |
| 2020-12-29 18:52 | jamie philbrook | Note Added: 0127912 | |
| 2020-12-29 19:00 | Michael Van Canneyt | Note Added: 0127913 | |
| 2020-12-30 11:55 | Sven Barth | Note Added: 0127931 | |
| 2020-12-30 13:09 | jamie philbrook | Note Added: 0127938 | |
| 2020-12-30 16:54 | Sven Barth | Note Added: 0127943 | |
| 2020-12-30 17:13 | Bart Broersma | Note Added: 0127944 |
