i pushed cleaned code to my fork (https://github.com/jklwn/fbc), "ustring" is still used as a marker, until we can be absolutely sure, that there are no bugs anymore. All my tests show, that there are no more bugs in Windows and Linux - please re-check this.
There is a new repository for "ustring.inc" + "test.bas" here (https://github.com/jklwn/ustring), which contains the latest version of both files and some other files you can ignore.
Ok, I started to look at your previous branch from last week. I have not gone in depth to your latest branch; just saw it a couple hours ago.
I know I am being picky (specific, pedantic, critical) about your branch. So, maybe if I provide some context, you will understand why.
1) For perspective, here is what my local repository looks like:
jayrm-fbc-graph-20190105.png- To switch between branches (git checkout), I don't expect to have to do much.
- My focus currently is 1.06.0 branch because I am creating releases.
- jklwn/JK-USTRING is your most recent push to your public repo
- jk-ustring is my local branch, with edits that cleans up all the meaningless differences, gets rid of the "#compile" directives that are specific to your IDE, etc. As of your previous jklwn/JK-USTRING branch, actual number of files changed, is about 10 files.
2) When I compare origin/master to jklwm/JK-USTRING, here's what I see:
jayrm-jklwn-diff-20190105.png- It shows me differences that I don't care about. Many differences are meaningless and is result of the way you are working with fbc/master and git checkout
- you really need to set your git config core.autocrlf = true. Then all files that are checked out from git will be converted to CRLF line endings and you can get rid of '.gitattributes' file
- eventually, before you create a pull request to fbc/master, you should do a
git rebase so that your end result is concise number of commits. No fault to Marc Pons, because it's only in hindsight, that's what should have been done with
__FB_GUI__ pull request. But it never happened. I'm trying to learn from past experience.
3) And when I look at specific code:
jayrm-jklwn-file-diff-20190105.png, these changes are now meaningless. As you spend more time in the code base, these kinds of comments are not needed since should be obvious just reading the code.
4) Copyright on ustring.inc
' ****************************************************************************************
' This code is copied and adapted from WinFBX with explicit permission of José Roca
' under the condition that the original copyright applies (see below).
' All changes and additions are Copyright (c) 2018 Juergen Kuehlwein
' Freeware. Use at your own risk.
' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
' EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
' MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
' ****************************************************************************************
' ########################################################################################
' Microsoft Windows
' Implements a dynamic data type for null terminated unicode strings.
' Compiler: Free Basic 32 & 64 bit
' Copyright (c) 2016 Paul Squires & José Roca, with the collaboration of Marc Pons.
' Freeware. Use at your own risk.
' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
' EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
' MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
' ########################################################################################
- What is intent here for licensing it's use? Included as part of FreeBASIC releases?
- As FreeBASIC developer, what am I allowed to do? Can I distrubute? You are stating that if I modify it, you still have copyright on it. That don't think that is compatible with FreeBASIC's other licenses.
- This needs to be addressed. For ustring.bi reference implementation, the licensing terms can not be any less restrictive than current rtlib/gfxlib2 licensing. Of course, you can create a full featured, any extensions you like version with any copyright/licensing you choose otherwise. But, for anything that is packaged with FreeBASIC, the developer team needs control over licensing.
- Also, if it's to be included as part of FreeBASIC release, to be use by users, then should look at separate .bi interface + .bas implementation; not all users #include sources from one main file.
So, ustring.inc or some variation of it, eventually needs to get added as reference implementation. As a reference implementation, it does not need to be exactly like DWSTRING, CWSTR, etc. It's only there to test the new feature of UDT => WSTRING implicit casting.
For me, to test your branch, I must edit several files in your branch, create a new branch, and create the automatic tests that I can run on each system. For the current time, I can give you some guidance only. Otherwise, just now, it just takes too much time to switch branches and work with your code.
I hope I explain in a way that is not too discouraging.