www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __DIR__ trait (return getcwd at compile time),

reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
__FILE_FULL_PATH__ is broken (doesn't work with optional parameters):
https://issues.dlang.org/show_bug.cgi?id=16640
Although this bug should be fixed, I think there's something better:

How about introduce instead a __DIR__ trait which is equal to the absolute
path of current directory during compilation.

Advantages:

* no need to change function signatures:

void fun(int arg0, string file=__FILE__, int line=__LINE__){
  enum file_full_path=buildPath(__DIR__, file);
  // file_full_path can be used at compile time if needed
}

instead of changing to:
void fun(int arg0, string file= __FILE_FULL_PATH__, int line=__LINE__){ ...}


* more flexible: we can have both __FILE__ and it's absolute version

* smaller binaries (no need to store redundant path information in
__FILE_FULL_PATH__ when __DIR__ + __FILE__ is enough)

__FILE_FULL_PATH__ can be put in deprecation path

NOTE: there is areal use case for having a full path available [see see
associated discussion in pull https://github.com/dlang/dmd/pull/5959], the
one proposed here (__DIR__) is less intrusive: function signature doesn't
change, but implementation can add __DIR__ to get absolute path when needed.
Jan 09 2017
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 9 January 2017 at 17:47:27 UTC, Timothee Cour wrote:

 * smaller binaries (no need to store redundant path information 
 in __FILE_FULL_PATH__ when __DIR__ + __FILE__ is enough)


__DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.

__FILE__ really has no restriction, it could be an absolute 
filename itself, or it could be a relative path and the filename, 
or it could be just the filename by itself.

__FILE_FULL_PATH__ would be equivalent to __DIR__ + 
__FILE__.baseName.

I personally would be OK with adding __DIR__ to the language.  It 
makes some things easier, but __FILE_FULL_PATH__ makes other 
scenarios easier.  However, I don't think you're going to 
convince the current maintainers to add it.  It requires adding 
to the language and implementing the functionality in the 
compiler, which means you need a very good reason.

When __FILE_FULL_PATH__ was initially added, I argued there was a 
very good reason for it because the functionality was nonexistent 
in the language.  There was not way to get this information.  
However, now that we have __FILE_FULL_PATH__, you can easily get 
__DIR__ by using __FILE_FULL_PATH__.dirName.  Sure it would be 
more convenient to have  __DIR__ in some cases, but I don't think 
you're going to convince anyone this convenience is worth 
changing the language and all the compilers.

So to summarize, I agree it's a good idea, but brace yourself 
because I don't think people are going to welcome this idea with 
*open arms* :)
Jan 09 2017
parent reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
 __DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.


Like is said, it's equivalent to buildPath(__DIR__, __FILE_FULL_PATH__).
This works whether __FILE_FULL_PATH__ is absolute file or not (see
buildPath docs)


 __FILE_FULL_PATH__ would be equivalent to __DIR__ + __FILE__.baseName.


not true. __FILE__ can be: foo/bar/baz.d, __DIR__ could be /path/to/import/
(and the file being compiled is under /path/to/import/foo/bar/baz.d). __DIR__
+ __FILE__.baseName would return wrong answer.


 __FILE_FULL_PATH__ makes other scenarios easier


Please name a single one.


__FILE_FULL_PATH__ should be deprecated if __DIR__ is added. It has all the
advantages I listed in original post.


On Mon, Jan 9, 2017 at 10:11 AM, Jonathan Marler via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Monday, 9 January 2017 at 17:47:27 UTC, Timothee Cour wrote:


 * smaller binaries (no need to store redundant path information in
 __FILE_FULL_PATH__ when __DIR__ + __FILE__ is enough)


 __DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.

 __FILE__ really has no restriction, it could be an absolute filename
 itself, or it could be a relative path and the filename, or it could be
 just the filename by itself.

 __FILE_FULL_PATH__ would be equivalent to __DIR__ + __FILE__.baseName.

 I personally would be OK with adding __DIR__ to the language.  It makes
 some things easier, but __FILE_FULL_PATH__ makes other scenarios easier.
 However, I don't think you're going to convince the current maintainers to
 add it.  It requires adding to the language and implementing the
 functionality in the compiler, which means you need a very good reason.

 When __FILE_FULL_PATH__ was initially added, I argued there was a very
 good reason for it because the functionality was nonexistent in the
 language.  There was not way to get this information.  However, now that we
 have __FILE_FULL_PATH__, you can easily get __DIR__ by using
 __FILE_FULL_PATH__.dirName.  Sure it would be more convenient to have
 __DIR__ in some cases, but I don't think you're going to convince anyone
 this convenience is worth changing the language and all the compilers.

 So to summarize, I agree it's a good idea, but brace yourself because I
 don't think people are going to welcome this idea with *open arms* :)
Jan 09 2017
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 9 January 2017 at 21:59:04 UTC, Timothee Cour wrote:

 __DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.


 Like is said, it's equivalent to buildPath(__DIR__, 
 __FILE_FULL_PATH__).
 This works whether __FILE_FULL_PATH__ is absolute file or not 
 (see
 buildPath docs)


 __FILE_FULL_PATH__ would be equivalent to __DIR__ + 
 __FILE__.baseName.


 not true. __FILE__ can be: foo/bar/baz.d, __DIR__ could be 
 /path/to/import/ (and the file being compiled is under 
 /path/to/import/foo/bar/baz.d). __DIR__ + __FILE__.baseName 
 would return wrong answer.


 __FILE_FULL_PATH__ makes other scenarios easier


 Please name a single one.


 __FILE_FULL_PATH__ should be deprecated if __DIR__ is added. It 
 has all the advantages I listed in original post.


 On Mon, Jan 9, 2017 at 10:11 AM, Jonathan Marler via 
 Digitalmars-d < digitalmars-d puremagic.com> wrote:


 On Monday, 9 January 2017 at 17:47:27 UTC, Timothee Cour wrote:


 * smaller binaries (no need to store redundant path 
 information in __FILE_FULL_PATH__ when __DIR__ + __FILE__ is 
 enough)


 __DIR__ + __FILE__ is not equivalent to __FILE_FULL_PATH__.

 __FILE__ really has no restriction, it could be an absolute 
 filename itself, or it could be a relative path and the 
 filename, or it could be just the filename by itself.

 __FILE_FULL_PATH__ would be equivalent to __DIR__ + 
 __FILE__.baseName.

 I personally would be OK with adding __DIR__ to the language.  
 It makes some things easier, but __FILE_FULL_PATH__ makes 
 other scenarios easier. However, I don't think you're going to 
 convince the current maintainers to add it.  It requires 
 adding to the language and implementing the functionality in 
 the compiler, which means you need a very good reason.

 When __FILE_FULL_PATH__ was initially added, I argued there 
 was a very good reason for it because the functionality was 
 nonexistent in the language.  There was not way to get this 
 information.  However, now that we have __FILE_FULL_PATH__, 
 you can easily get __DIR__ by using 
 __FILE_FULL_PATH__.dirName.  Sure it would be more convenient 
 to have __DIR__ in some cases, but I don't think you're going 
 to convince anyone this convenience is worth changing the 
 language and all the compilers.

 So to summarize, I agree it's a good idea, but brace yourself 
 because I don't think people are going to welcome this idea 
 with *open arms* :)




Ah I see I misunderstood your definition of __DIR__.  I thought 
it mean "The absolute path to the current file", but you state it 
actually meant "the absolute path of the current directory".

I also see now that your previous comments about calculating 
__FILE_FULL_PATH__ using buildPath(__DIR__, __FILE__) don't 
actually work.  I believe where you went wrong was assuming that 
the __FILE__ macro resolves to a filename that is always relative 
to the current directory, but this isn't the case.  The __FILE__ 
macro could resolve to an absolute path, or a relative path to an 
import directory (different than the current directory) or even 
just a filename with no path.  Furthermore, the language 
definition of the __FILE__ macro does not specify what kind of 
path it uses, so even if you figure out all the cases for DMD, 
they are subject to change and the other compilers are free to 
have their own implementation as well.

That being said, if you defined __DIR__ to mean "The path to the 
directory that contains __FILE__", then your previous comments 
would hold true.  In other words, if you defined __DIR__ as:

buildPath(__DIR__, __FILE__) == __FILE_FULL_PATH__

So now I hope we are on the same page.  That being said, my 
previous comments about having a good reason to change the 
language and all the compilers still apply.  I don't really see 
any big advantages to this.  This would make some use cases 
easier but other not so easy.  If your program wants the full 
path to the source file:

Using __DIR__ macro:             buildPath(__DIR__, __FILE__)
Using __FILE_FULL_PATH__ macro:  __FILE_FULL_PATH__

If you wanted the containing directory of the file, you would do 
this:

Using __DIR__ macro:             buildPath(__DIR__, 
__FILE__.dirName)
Using __FILE_FULL_PATH__ macro:  __FILE_FULL_PATH__.dirName

I suppose I don't really see a reason to ever want the value of 
the __DIR__ macro, but you could calculate it from __FILE__ and 
__FILE_FULL_PATH__.   The reason for not wanting the value of the 
__DIR__ macro is because of what I said before.  It doesn't have 
a strict definition, it can change between compilers, and really 
doesn't provide any useful information.  In my experience, the 
usefull piece that programmers will want will be the path/file to 
the source file.  The __DIR__ will just be an arbitrary directory 
that depends on the compiler implementation.
Jan 10 2017