From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
To: Ruby developers <ruby-core@ruby-lang.org>
Subject: [ruby-core:73008] Re: [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each
Date: Thu, 21 Jan 2016 12:26:57 +0900 [thread overview]
Message-ID: <56A05001.9090605@it.aoyama.ac.jp> (raw)
In-Reply-To: <20160120024308.GA5484@dcvr.yhbt.net>
Hello Eric,
On 2016/01/20 11:43, Eric Wong wrote:
> naruse@airemix.jp wrote:
>> Dir#each and Dir#read) (including Dir.entries, Dir.foreach and other methods) return "." and ".." at first.
>> But through the all real use case "." and ".." are useless.
>> How about excluding them?
>
> If Ruby were a new language, yes. But I think it is too risky, now.
Can somebody do a code search for this? I know AKR is good at that (but
I don't want to ask him to do this).
>> +#define DIR_IS_DOT_OR_DOTDOT(dp) ((dp)->d_name[0] == '.' && \
>> + ((dp)->d_name[1] == '\0' || ((dp)->d_name[1] == '.' && (dp)->d_name[2] == '\0')))
>
> Anyways, I prefer we reduce macro usage and use static inline functions
> to avoid potential side effects, extra '\' and parentheses.
Are inline functions now an accepted concept in C? It seems they are
available from C99, but then so are // comments, and they are not yet
accepted in Ruby because of some old compilers.
Also, are there C compilers that inline functions as part of
optimization, even if they aren't marked as such in the source?
While I very much understand your point re. potential side effects,
using inline functions also may save space at the cost of time, in
particular for long macros. Is that also one of the reasons you favor them?
Regards, Martin.
next prev parent reply other threads:[~2016-01-21 3:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-12010.20160120021716@ruby-lang.org>
2016-01-20 2:17 ` [ruby-core:72954] [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each naruse
2016-01-20 2:43 ` [ruby-core:72959] " Eric Wong
2016-01-21 3:26 ` Martin J. Dürst [this message]
2016-01-21 4:57 ` [ruby-core:73012] " Eric Wong
2016-01-20 2:25 ` [ruby-core:72957] [Ruby trunk - Feature #12010] " naruse
2016-01-20 3:11 ` [ruby-core:72960] " nobu
2016-01-20 10:26 ` [ruby-core:72975] " naruse
2016-01-20 12:34 ` [ruby-core:72978] " eregontp
2016-01-21 2:10 ` [ruby-core:73003] " nobu
2016-01-21 2:28 ` [ruby-core:73005] " naruse
2016-01-21 4:25 ` [ruby-core:73011] " akr
2016-01-21 7:47 ` [ruby-core:73014] " naruse
2016-01-21 7:58 ` [ruby-core:73015] " naruse
2016-01-22 3:38 ` [ruby-core:73102] " kevin.deisz
2016-01-23 8:42 ` [ruby-core:73308] " shevegen
2018-03-01 1:13 ` [ruby-core:85871] [Ruby trunk Feature#12010] " nobu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A05001.9090605@it.aoyama.ac.jp \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).