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 < [email protected]> 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.
