[ruby-core:73012] Re: [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each

"Martin J. D端rst" <[e-mail]> wrote:
> On 2016/01/20 11:43, Eric Wong wrote:
> >[e-mail] 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).

I just found some in yahns which I wrote:
   http://yhbt.net/yahns.git/plain/extras/autoindex.rb

Easily fixable, but we also don't know what kinds of code people
have in private.

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

It seems so, we already have static inlines everywhere in Ruby.
I guess AC_C_INLINE takes care of the portability inside configure.in

'//' comments can't be worked around using CPP on old compilers.

Fwiw, git and Linux kernel both reject '//' despite using
static inlines heavily; Linux also uses C99 struct initializers,
but git does not as git targets more compilers than Linux.

> Also, are there C compilers that inline functions as part of
> optimization, even if they aren't marked as such in the source?

Yes, actually I often favor plain 'static' to let the compiler
more make decisions.  In my experience with gcc; single-use
'static' functions always get inlined (but I don't look at giant
functions much).  Usually, smaller icache footprints are
better for overall performance(*).

gcc will also complain about unused 'static', but not 'static inline'
in header files.

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

Yes, space, too.  I prefer to trust the compiler as much as possible
in the hopes they can make better decisions than me (or may eventually
do so, perhaps with things like PGO).

Functions also get type-checked at compile time.  Compile-time
type-checking is nice in C :)

(*) Of course, we default to -O3 in which makes our icache footprint
    huge.  I've tried with -O2 in the past and unfortunately our
    benchmarks got slower.  It seems there's some hotspots in the
    VM core loop that benefit from -O3...

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>