Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basic support for Unicode file names and some bugfixes #15

Closed
wants to merge 4 commits into from

Conversation

aafemt
Copy link
Contributor

@aafemt aafemt commented Apr 16, 2016

Unicode file names and pathes work at API level. Little glitches can be fixed after Pavel Zotov create test suite.
Much more must be done for unicode support in utilities command lines.

@@ -411,10 +411,10 @@ namespace Firebird
}
void insert(size_type p0, const_pointer s, const size_type n)
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this fix should be done as separate pull request and backported to 2.5 and 3.0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is regression of this branch, problem does not exist in other branches.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On 06/16/2016 07:58 PM, Dimitry Sibiryakov wrote:

@@ -411,10 +411,10 @@ namespace Firebird
}
void insert(size_type p0, const_pointer s, const size_type n)
{
No, this is regression of this branch, problem does not exist in other branches.

OK, in that case no problems.

@egorpugin
Copy link
Contributor

Why just not use boost::filesystem and remove tons of code?
Especially when boost::filesystem was accepted into C++17.

@hvlad
Copy link
Member

hvlad commented Aug 12, 2016

What issue the last commit (2f89d89) solved ? Just for fun ?

@aafemt
Copy link
Contributor Author

aafemt commented Aug 12, 2016

It got rid of magic numbers before Adriano requested that.

@egorpugin
Copy link
Contributor

Size of dllExt string is known at compile time, so it's better to use sizeof() operator.

@aafemt
Copy link
Contributor Author

aafemt commented Aug 12, 2016 via email

@egorpugin
Copy link
Contributor

sizeof for static const char dllExt[] = ".dll";, not for const char *.
Why strlen() is compile time?

@aafemt
Copy link
Contributor Author

aafemt commented Aug 12, 2016 via email

@egorpugin
Copy link
Contributor

It will probably require modern constexpr keyword.
By the way on line 195 of 2f89d89 you can use also dllExt and not ".dll".

String refactoring as requested by Alex.
@@ -565,7 +567,9 @@ int SecurityDatabaseManagement::execute(Firebird::CheckStatusWrapper* st, Firebi
if (!U.PLG$GROUP_NAME.NULL)
a3.printf("GroupName=%s\n", U.PLG$GROUP_NAME);

attr = a1 + a2 + a3;
attr = a1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change has nothing to do with unicode support

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specially strange taken together with introduced by you assignment operator using rvalue reference. With this c++11 feature I see absolutely no sense in this change.

@@ -57,7 +57,7 @@ class IntlUtil
static bool parseSpecificAttributes(Jrd::CharSet* cs, ULONG len, const UCHAR* s,
SpecificAttributesMap* map);

static string convertAsciiToUtf16(const string& ascii);
static string convertAsciiToUtf16(const char* ascii);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's a reason in using here plain char pointer instead class reference?

@aafemt
Copy link
Contributor Author

aafemt commented Oct 18, 2016

This change has nothing to do with unicode support

Yes, this is result of string refactoring which you demanded.

@aafemt
Copy link
Contributor Author

aafemt commented Oct 18, 2016

What's a reason in using here plain char pointer instead class reference?

This routine used to be called using string literal. Creating of temporary class is
unnecessary overhead. In rare cases when it is called with data contained in string, call
of c_str() has no overhead.

@aafemt
Copy link
Contributor Author

aafemt commented Oct 18, 2016

Specially strange taken together with introduced by you assignment operator using rvalue
reference.

This operator has no advantage on short strings which fit into internal buffer. That's why
control of assignments is still important for performance.


AbstractString& append(const AbstractString& str)
void append(const AbstractString& str)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rollback this massive changes from 'AbstractString&' to 'void' return type. Not related with unicode support (and violate syntax of std::basic_string).

Copy link
Contributor Author

@aafemt aafemt Oct 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These routines are private. They cannot be called from outside code and have nothing to do with public interface of std::basic_string except name. Their public envelopes in derived classes return reference to instance of proper class.

@AlexPeshkoff
Copy link
Member

On 10/18/16 14:00, Dimitry Sibiryakov wrote:

Specially strange taken together with introduced by you assignment operator using rvalue
reference.

This operator has no advantage on short strings which fit into internal buffer. That's why
control of assignments is still important for performance.

Anyway rollback that "optimization".

@@ -102,7 +102,7 @@ namespace
if (dladdr((void*) &allClean, &path))
{
name = path.dli_fname;
name += ".memdebug.log";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use of function call instead redefined operator does not make code better.
Rollback such changes too.

@@ -214,7 +215,7 @@ namespace Firebird
T pop()
{
T* pntr = inherited::pop();
T rc = *pntr;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And how is THIS related to unicode support?
May be correct change, but... not here.

@aafemt
Copy link
Contributor Author

aafemt commented Oct 18, 2016

Use of function call instead redefined operator does not make code better.

It makes code working. As was agreed in firebird-devel, the function doesn't add directory
separator before appended string.

@aafemt aafemt changed the title Basic support for Unicode file names Basic support for Unicode file names and a lot of subtle bug fixed Oct 18, 2016
@AlexPeshkoff
Copy link
Member

AlexPeshkoff commented Oct 18, 2016

Dmitry, I stop review.
Please remove yourself changes not related to unicode support.
Some of them may be discussed later in separate pull requests.

If you continue playing with names I will have to close your PR which will be very bad cause in many aspects it is useful.

@AlexPeshkoff
Copy link
Member

On 10/18/16 14:19, Dimitry Sibiryakov wrote:

Use of function call instead redefined operator does not make code better.

It makes code working. As was agreed in firebird-devel, the function doesn't add directory
separator before appended string.

OK, agreed.

@AlexPeshkoff
Copy link
Member

On 10/18/16 15:31, Dimitry Sibiryakov wrote:

aafemt commented on this pull request.

  • AbstractString& append(const AbstractString& str)
    
  • void append(const AbstractString& str)
    

These routines are private.

They are protected. Am I undestand it right that
using AbstractString::append;
in public section of derived class makes it visible from the outside world?

They cannot be called from outside code and have nothing to do with public interface of std::basic_string except name.

Class string was initially designed to be able to serve as a replacement
of basic_string with extended functionality and I see no reasons
to change this ability as long as we have no serious reasons to do it.

I.e. to be precise - not only name but name and functionality.

@aafemt
Copy link
Contributor Author

aafemt commented Oct 18, 2016

in public section of derived class makes it visible from the outside world?

Yes.

I see no reasons to change this ability as long as we have no serious reasons to do it.

Isn't chained code like "a.append("abc").append("def").c_str()" prohibited by project's style guides?..

@AlexPeshkoff
Copy link
Member

On 10/18/16 15:48, Dimitry Sibiryakov wrote:

in public section of derived class makes it visible from the outside world?
Yes.

I see no reasons to change this ability as long as we have no serious reasons to do it.
Isn't chained code like "a.append("abc").append("def").c_str()" prohibited by project's style guides?..

May be - but I do not know about it.
Chains of redefined operators are actively used.

@aafemt
Copy link
Contributor Author

aafemt commented Oct 18, 2016

Chains of redefined operators are actively used.

But Adriano called them "ugly and non-sense", didn't he?..

@AlexPeshkoff
Copy link
Member

On 10/18/16 15:55, Dimitry Sibiryakov wrote:

Chains of redefined operators are actively used.
But Adriano called them "ugly and non-sense", didn't he?..

Do not think so - he is actively them. For example, in SQL builder.
But that all goes offtopic here.

@aafemt aafemt changed the title Basic support for Unicode file names and a lot of subtle bug fixed Basic support for Unicode file names and some bugfixes Oct 21, 2016
@@ -657,7 +658,7 @@ void add_files(BurpGlobals* tdgbl, const char* file_name)

for (burp_fil* file = tdgbl->gbl_sw_files; file; file = file->fil_next)
{
if (file->fil_name != file_name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change?
Are we missing operator!=()?

@aafemt
Copy link
Contributor Author

aafemt commented Oct 25, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants