> PS: Theoretical limit of path on Windows is 32k unicode characters.
It's actually 32767. Maybe less, depending what `\\?\` resolves to.
--
Mgr. Jiří Činčura
Independent IT Specialist
--
Find and fix application pe
09.05.2016 19:00, Adriano dos Santos Fernandes wrote:
> The PathName should not automatically transform paths to full (absolute)
> paths when combining or assigning.
But currently this is exactly what it does everywhere across Firebird code.
Here and
there separate routines combine different
On 09/05/2016 13:37, Dimitry Sibiryakov wrote:
> 09.05.2016 18:33, Adriano dos Santos Fernandes wrote:
>> The drive of current directory.
>>
>> If you want to transform a relative path to absolute, you will use the
>> current drive and directory.
>In this case current directory should be in lef
09.05.2016 18:33, Adriano dos Santos Fernandes wrote:
> The drive of current directory.
>
> If you want to transform a relative path to absolute, you will use the
> current drive and directory.
In this case current directory should be in left part of concatenation,
shouldn't it?
--
WBR, S
On 09/05/2016 13:27, Dimitry Sibiryakov wrote:
> 09.05.2016 18:22, Adriano dos Santos Fernandes wrote:
>> This should be as the rule above. Second argument is absolute (relative
>> to current drive, but still absolute), so if we want this logic, should
>> be = \qwe\uio\ which you may later interpre
09.05.2016 18:22, Adriano dos Santos Fernandes wrote:
> This should be as the rule above. Second argument is absolute (relative
> to current drive, but still absolute), so if we want this logic, should
> be = \qwe\uio\ which you may later interpret relative to current drive.
What is "current dr
On 09/05/2016 12:36, Dimitry Sibiryakov wrote:
> 06.05.2016 20:20, Alex Peshkoff wrote:
>> Why file name should be represented as a string, not PathName? It does
>> not follow from what you say before. Moreover, if we need to correctly
>> compare that file name with another one we must "use PathNam
06.05.2016 20:20, Alex Peshkoff wrote:
> Why file name should be represented as a string, not PathName? It does
> not follow from what you say before. Moreover, if we need to correctly
> compare that file name with another one we must "use PathName ... to
> solve". I.e. to correctly work with file
08.05.2016 23:52, Adriano dos Santos Fernandes wrote:
> It needs to create and destroy a temporary B.
You are right.
But it doesn't make returning by value better, because
a) it guaranteed overhead
b) it is enough to forget to define explicit assignment operator in any
descendant of
AutoS
Em 07/05/2016 15:17, Dimitry Sibiryakov escreveu:
> 07.05.2016 20:00, Adriano dos Santos Fernandes wrote:
>> No, just no! It will not do this!
>>
>> You're free to write minimal test case compiling with maximum
>> optimization to demonstrate this.
>>
>> You will fail, I know.
>
> Try attached te
07.05.2016 20:00, Adriano dos Santos Fernandes wrote:
No, just no! It will not do this!
You're free to write minimal test case compiling with maximum
optimization to demonstrate this.
You will fail, I know.
Try attached test and notice "B destructed" in the middle of output.
--
WBR, SD.
Em 07/05/2016 13:13, Dimitry Sibiryakov escreveu:
> 07.05.2016 18:03, Adriano dos Santos Fernandes wrote:
>> Optimizations are not allowed to broke conforming code.
>
>Compiler is free to destroy old instance of object and create a new one
> when its
> content is overwritten by assignment op
07.05.2016 18:03, Adriano dos Santos Fernandes wrote:
> Optimizations are not allowed to broke conforming code.
Compiler is free to destroy old instance of object and create a new one when
its
content is overwritten by assignment operator using appropriate copy or move
constructor.
For th
Em 07/05/2016 12:51, Dimitry Sibiryakov escreveu:
> 07.05.2016 17:47, Adriano dos Santos Fernandes wrote:
>> There is no problem
>
>How can you be so sure? Did you inspected exact way copy elision works for
> every used
> compiler?
>
Optimizations are not allowed to broke conforming code.
07.05.2016 17:47, Adriano dos Santos Fernandes wrote:
> There is no problem
How can you be so sure? Did you inspected exact way copy elision works for
every used
compiler?
--
WBR, SD.
--
Find and fix application
There is no problem, you seem to use wrong things in your private code
and are assuming there is bugs in the pubic code.
Adriano
Em 07/05/2016 05:36, Dimitry Sibiryakov escreveu:
> 07.05.2016 0:17, Adriano dos Santos Fernandes wrote:
>> Define the problem.
>>
>> I do not see this unpredictable
07.05.2016 0:17, Adriano dos Santos Fernandes wrote:
> Define the problem.
>
> I do not see this unpredictable behavior.
Usual code for such methods are:
XXX YYY:toXXX()
{
return XXX(*this);
}
Note that constructor here uses default pool.
Now look at calling code:
XXX a(anyPool);
a
Em 06/05/2016 17:07, Dimitry Sibiryakov escreveu:
> 06.05.2016 21:53, Adriano dos Santos Fernandes wrote:
>> - Put a "const string& getAsString()" or a "string toString()" method.
>
>No way. Returning AutoStorage descendant by value is an unpredictable
> behavior.
>
Define the problem.
I d
06.05.2016 21:53, Adriano dos Santos Fernandes wrote:
> - Put a "const string& getAsString()" or a "string toString()" method.
No way. Returning AutoStorage descendant by value is an unpredictable
behavior.
--
WBR, SD.
-
06.05.2016 21:56, Dmitry Yemanov wrote:
> Speaking about storage, would it make sense to define PathName
> statically allocated (MAX_PATH limited)? We have just a few of these
> objects stored persistently, most dynamic operations are local -- having
> them on stack would save us costly reallocatio
06.05.2016 22:47, Dimitry Sibiryakov wrote:
>
> Then you should define "not to be a string". What does it mean? Not to be
> AutoStorage
> descendant? To have different storage model?
Speaking about storage, would it make sense to define PathName
statically allocated (MAX_PATH limited)? We have j
On 06/05/2016 16:47, Dimitry Sibiryakov wrote:
>Then you should define "not to be a string". What does it mean? Not to be
> AutoStorage
> descendant? To have different storage model? To reinvent wheel of cropping,
> inserting and
> appending pieces?
>
- Use AutoStorage as string uses.
- U
06.05.2016 20:36, Adriano dos Santos Fernandes wrote:
> Will PathName continue to be inherited by BaseString?
In my local branch it is inherited from AbstractString which handle storage
and has
almost all methods protected.
> I think it's wrong. It should be an standalone class, or if you wa
On 06/05/2016 15:20, Alex Peshkoff wrote:
> On 05/06/2016 08:41 PM, Adriano dos Santos Fernandes wrote:
>> On 06/05/2016 14:16, Dimitry Sibiryakov wrote:
>>> 06.05.2016 19:03, Adriano dos Santos Fernandes wrote:
Yes, PathName may represent a relative path, but generally (always?) you
know
On 05/06/2016 08:41 PM, Adriano dos Santos Fernandes wrote:
> On 06/05/2016 14:16, Dimitry Sibiryakov wrote:
>> 06.05.2016 19:03, Adriano dos Santos Fernandes wrote:
>>> Yes, PathName may represent a relative path, but generally (always?) you
>>> know that a path read from somewhere will or not goi
On 06/05/2016 14:16, Dimitry Sibiryakov wrote:
> 06.05.2016 19:03, Adriano dos Santos Fernandes wrote:
>> Yes, PathName may represent a relative path, but generally (always?) you
>> know that a path read from somewhere will or not going to be appended
>> with a parent path.
>No, on contrary in
06.05.2016 19:03, Adriano dos Santos Fernandes wrote:
> Yes, PathName may represent a relative path, but generally (always?) you
> know that a path read from somewhere will or not going to be appended
> with a parent path.
No, on contrary in current code they are always split or combined with
On 06/05/2016 14:04, Alex Peshkoff wrote:
> On 05/06/2016 07:56 PM, Adriano dos Santos Fernandes wrote:
>> On 06/05/2016 13:50, Alex Peshkoff wrote:
>>> On 05/06/2016 07:39 PM, Dimitry Sibiryakov wrote:
06.05.2016 18:19, Adriano dos Santos Fernandes wrote:
> Also constructor PathName(const
06.05.2016 18:56, Adriano dos Santos Fernandes wrote:
>> >PathName(const PathName&, const PathName&) // dirsep between
>> >
> Should not exist IMO. Potentially wrong operation.
It looks like you assumed from class name that it contain only paths. That's
not true.
It is class for any FS ob
On 06/05/2016 13:47, Dimitry Sibiryakov wrote:
> 06.05.2016 18:40, Adriano dos Santos Fernandes wrote:
>> Use cases for this?
>Look at TempFile::init(), for example. File name there is combined from
> several parts.
>
That's why strings exists. Build strings then convert to PathName.
And no,
On 05/06/2016 07:56 PM, Adriano dos Santos Fernandes wrote:
> On 06/05/2016 13:50, Alex Peshkoff wrote:
>> On 05/06/2016 07:39 PM, Dimitry Sibiryakov wrote:
>>> 06.05.2016 18:19, Adriano dos Santos Fernandes wrote:
Also constructor PathName(const PathName&, const string&) would be good.
>>>
On 06/05/2016 13:56, Dimitry Sibiryakov wrote:
> 06.05.2016 18:45, Adriano dos Santos Fernandes wrote:
>> There is no ambiguity.
>>
>> You can see similar operations in any file/path API you look for: qt,
>> Java, C#, etc. A good source to not reinvent the wheel with bad semantics.
>I see that
On 06/05/2016 13:50, Alex Peshkoff wrote:
> On 05/06/2016 07:39 PM, Dimitry Sibiryakov wrote:
>> 06.05.2016 18:19, Adriano dos Santos Fernandes wrote:
>>> Also constructor PathName(const PathName&, const string&) would be good.
>> Why? It has the same ambiguity: whether to put dir separator in
06.05.2016 18:45, Adriano dos Santos Fernandes wrote:
> There is no ambiguity.
>
> You can see similar operations in any file/path API you look for: qt,
> Java, C#, etc. A good source to not reinvent the wheel with bad semantics.
I see that QFile and File in Java indeed have constructors with t
On 05/06/2016 07:39 PM, Dimitry Sibiryakov wrote:
> 06.05.2016 18:19, Adriano dos Santos Fernandes wrote:
>> Also constructor PathName(const PathName&, const string&) would be good.
> Why? It has the same ambiguity: whether to put dir separator in between
> or not.
>
If we talk about ctors -
On 05/06/2016 07:40 PM, Adriano dos Santos Fernandes wrote:
> On 06/05/2016 13:20, Dimitry Sibiryakov wrote:
>> 2) Methods appendPath() and appendString() to be introduced to allow append
>> a path (file
>> name) with proper separator and append "just a string" without any check for
>> a separato
06.05.2016 18:40, Adriano dos Santos Fernandes wrote:
> Use cases for this?
Look at TempFile::init(), for example. File name there is combined from
several parts.
--
WBR, SD.
--
Find and fix application performan
On 06/05/2016 13:39, Dimitry Sibiryakov wrote:
> 06.05.2016 18:19, Adriano dos Santos Fernandes wrote:
>> Also constructor PathName(const PathName&, const string&) would be good.
>Why? It has the same ambiguity: whether to put dir separator in between or
> not.
>
There is no ambiguity.
You c
On 06/05/2016 13:20, Dimitry Sibiryakov wrote:
> 2) Methods appendPath() and appendString() to be introduced to allow append a
> path (file
> name) with proper separator and append "just a string" without any check for
> a separator
> respectively.
>
Use cases for this?
Something like doctorM
06.05.2016 18:19, Adriano dos Santos Fernandes wrote:
> Also constructor PathName(const PathName&, const string&) would be good.
Why? It has the same ambiguity: whether to put dir separator in between or
not.
--
WBR, SD.
---
On 06/05/2016 13:15, Alex Peshkoff wrote:
> On 05/06/2016 07:12 PM, Dimitry Sibiryakov wrote:
>> 06.05.2016 18:04, Adriano dos Santos Fernandes wrote:
>>> We already have PathUtils::concatPath doing this correctly (putting an
>>> separator between the parts).
>> I know. But because I'm refactor
06.05.2016 18:15, Alex Peshkoff wrote:
> Looking at this discussion - methods.
So, we have an agreement that:
1) Operators '+' and '+=' must be prohibited for PathName;
2) Methods appendPath() and appendString() to be introduced to allow append a
path (file
name) with proper separator and ap
On 05/06/2016 07:12 PM, Dimitry Sibiryakov wrote:
> 06.05.2016 18:04, Adriano dos Santos Fernandes wrote:
>> We already have PathUtils::concatPath doing this correctly (putting an
>> separator between the parts).
> I know. But because I'm refactoring PathName class, Alex suggested to
> move mo
06.05.2016 18:04, Adriano dos Santos Fernandes wrote:
> We already have PathUtils::concatPath doing this correctly (putting an
> separator between the parts).
I know. But because I'm refactoring PathName class, Alex suggested to move
most of
PathUtils' functionality into it.
That's why I c
On 06/05/2016 12:56, Dimitry Sibiryakov wrote:
> 06.05.2016 17:44, Adriano dos Santos Fernandes wrote:
>> It should throw an error if the string is an absolute path.
>Ok, but what it must to do if appended path is relative? For example, what
> should be
> result of "/usr/bin/firebird" += "plu
06.05.2016 17:44, Adriano dos Santos Fernandes wrote:
> It should throw an error if the string is an absolute path.
Ok, but what it must to do if appended path is relative? For example, what
should be
result of "/usr/bin/firebird" += "plugins/" ?
"/usr/bin/firebirdplugins/" or "/usr/bin/fi
On 06/05/2016 12:46, Michal Kubecek wrote:
> On Fri, May 06, 2016 at 05:34:10PM +0200, Dimitry Sibiryakov wrote:
>> 06.05.2016 17:27, Adriano dos Santos Fernandes wrote:
>>> You can have a PathName += string
>> Ok, must this operation ensure dir separator between the parts?
> Not necessarily, I wou
On Fri, May 06, 2016 at 05:34:10PM +0200, Dimitry Sibiryakov wrote:
> 06.05.2016 17:27, Adriano dos Santos Fernandes wrote:
> > You can have a PathName += string
>
> Ok, must this operation ensure dir separator between the parts?
Not necessarily, I would say, e.g. you may want to add an extension
On 06/05/2016 12:34, Dimitry Sibiryakov wrote:
> 06.05.2016 17:27, Adriano dos Santos Fernandes wrote:
>> You can have a PathName += string
>Ok, must this operation ensure dir separator between the parts?
>Should be here an operator or function that can be used to append a
> relative path
06.05.2016 17:27, Adriano dos Santos Fernandes wrote:
> You can have a PathName += string
Ok, must this operation ensure dir separator between the parts?
Should be here an operator or function that can be used to append a relative
path to a
root directory path, for example?
--
WBR, SD
On 06/05/2016 12:22, Dimitry Sibiryakov wrote:
> 06.05.2016 17:17, Adriano dos Santos Fernandes wrote:
>> There is no sense in concatenate /x with /y, and even more c:\a with d:\b
>Do you suggest to prohibit concatenation of PathName at all?
>
With an operator, definitively yes, should not be a
06.05.2016 17:17, Adriano dos Santos Fernandes wrote:
> There is no sense in concatenate /x with /y, and even more c:\a with d:\b
Do you suggest to prohibit concatenation of PathName at all?
--
WBR, SD.
--
Find an
On 06/05/2016 11:34, Dimitry Sibiryakov wrote:
>Is there anybody who find this behavior counterintuitive?
>
Yes!
There is no sense in concatenate /x with /y, and even more c:\a with d:\b
Adriano
--
Find and fix ap
Hello, All.
PathName class is intended to keep paths and file names. For me it is
natural, that
operator "PathName += PathName" must combine two paths ensuring right separator
between them.
Is there anybody who find this behavior counterintuitive?
--
WBR, SD.
54 matches
Mail list logo
