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
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
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
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