►
From YouTube: OMR Compiler STL Usage 20180718
Description
A
Okay,
welcome
everyone
to
this
week's
compiler
architecture
meeting.
We
have
one
topic
this
week:
it's
to
discuss
the
current
state
of
the
C++
standard,
template
library
in
the
compiler
technology,
the
sort
of
an
evaluation
of
where
we
are
with
that.
What
kind
of
benefits
and
challenges
that
we're
seeing
with
it
then
perhaps
have
a
discussion
about
where
we
want
to
go
with
it
in
the
future
and
Mark
stutely
is
going
to
lead
us
there's
this
discussion,
I'll
turn
it
over
to
him.
B
B
Even
when
exceptions
can
be
thrown
and
so
forth,
I
guess
I
have
this
sort
of
lingering
feeling
that
we're
trying
to
evolve
the
code
based
words,
a
more
C++
sort
of
friendly
model
of
allocation
and
de-allocation,
whereas
the
historical
origins
of
the
code
base
and
still
a
lot
of
the
code.
That's
in
the
code
base
is
been
created
in
the
context
of
a
bulk
free
model
where
you
don't
expect
objects
to
get
destructive
effect.
You
know
right
disruptors
and
so
I
guess
I
I.
B
Have
this
lingering
feeling
that
we're
we're
spending
a
lot
of
pain
to
move
the
code
base
into
a
model
that
doesn't
really
fit?
What
a
lot
of
the
code
base
is
trying
to
wants
to
do
and
maintaining
the
allocators
is
troublesome.
I
always
have
to
go
and
look
at
other
examples,
trying
to
figure
out
how
I
do
anything
with
the
alligators.
It
never
sticks
in
my
head.
That's
my
problem.
B
We
had
our
own
hash
table,
which
I
believe
are
all
still
there
and
they
work
all
five
of
them
all
five
of
them.
Yes,
all
five
different
versions
of
them
and
they
all
work
and
we're
built
sort
of
under
the
original
memory
management
model
that
Testarossa
has,
but
over
the
last
couple
years
we've
been
extending
with
lots
of
different
density.
B
Let's
actually
try
to
do
this,
meaning
that
I've
been
at
a
time
I
found
basically
500
references,
SP,
:,
:
code
based
I
was
trying
to
break
down
what
those
things
mostly
were,
and
about
half
I
got
to
about
half
with
about
10-ish
things.
So
min
and
Max
are
two
pretty
common
ones.
Find
is
a
pretty
common
one
and
then
kind
of
the
basic
containers
like
vector
list
map,
the
associated
things
like
hair
and
make
pair,
and
so
on.
Adult
kind
of
added
up
to
about
half.
C
B
B
Before
we
push
too
much
further
I
guess
down
this
path,
I
thought
it
would
be
worthwhile
having
a
broader
discussion
on
whether
or
not
STL
is
really
the
thing
that
we
want
to
do
the
code
base
form
or
another.
There
are
some
other
sort
of
annoying.
This
is
about
using
a
CL
that
associated
with
working
with
the
library
where
he
hid
the
library.
From
what
version
does
it
have
those
kinds
of
annoying
to
kind
of
be
things
that
always
seem
to
come
up?
Invite
us
in
various
places.
B
Flying
field
is
have
been
too
strong,
but
you
know
there
are
issues
that
need
to
be
figured
out
there
whenever
you're
trying
to
build
something
into
baseball
or
uses
the
STL,
how
you
should
bet
how
you
ensure
you're,
getting
the
right
version
of
it
along
and
then
I
guess,
there's
another
layer
of
this
which
Charlie's
been
communicating
which
is,
and
all
more
itself
has
another
layer
of
data
structures
that
are
sort
of
doing
largely
similar
things.
Some
of
the
requirements
are
different.
I
know.
B
The
GC,
for
example,
needs
to
have
multiple
threads
atomically
accessing
lists
very
efficiently,
whereas
the
compiler
care
less
formal
skiis
about
multiple
threads,
because
it's
executing
across
the
compilation
on
a
single
thread
right
now
for
now.
Yes,
yes,
that's
true,
and
there
are
non
compilation
uses
where
we
use
the
data
structures,
so
I
guess
that
multiple
threads
could
enter
there.
I.
A
Believe
it
so
just
to
provide
a
bit
of
the
other
side
of
the
story
necessarily
advocating
that
side
of
the
story.
But
one
of
the
reasons
that
we
went
the
route
with
STL
was
because
we
did
have
these
homegrown
data
structures
that
I
grew
up
with
the
early
days
of
from
the
early
days
of
Testarossa
and
we're
really
designed
to
be
fairly
efficient
in
terms
of
memory
usage,
and
you
know
giving
us
exactly
the
operations
that
we
we
wanted.
A
We
thought
that,
when
we're
open
sourcing
this
that
we
didn't
really
necessarily
want
to
be
maintaining
our
own
sort
of
proprietary
set
of
container
classes
when
there
already
is
a
well
tested
and
available
set
of
versions
up
there.
The
other
thing
you'll
find
on
the
code
base
as
well
is
usage
of
cs2,
which
is.
A
B
A
A
We
meet,
we
found
that
we
had
to
make
a
number
of
changes
to
the
code
in
order
to
support
the
difference
of
slightly
different
semantics,
with
STL,
for
example
over
in
about
Oh
TR
I.
Think
we'll
have
the
same
kind
of
situation
with
with
cs2
getting
rid
of
that
and
I'm,
surely
not
going
to
advocate
propping
up
cs2
anymore
I,
think
that
should
be
deprecated
completely
and.
C
A
D
A
Of
the
things
that
we
found
with
the
Testarossa
containers
that
made
them
somewhat
efficient
is
that
they
actually
do
expose
their
inner
workings.
So
it's
not
just
a
everything
is
encapsulated
within,
for
example,
the
list
you
actually
can
get
access
to
the
internal
parts
of
it
where
which
makes
iteration,
in
some
cases,
much
easier
to
do
much
more
efficient
to
do
so.
That
caused
us
a
lot
of
problems.
When
we
move
to
STL,
we
had
to
rewrite
a
lot
of
code
to
handle
that
which
introduced
the
bugs
potentially
some
performance
problems.
A
A
Yeah
so
may
I
guess
if
we
were
talking
about
backing
away
from
STL
back
onto
the
test,
Versalles
I.
Don't
think
that
without
that,
that
implies
that
we
can't
just
take
what
we
occur
using.
It
is
use
it
if
we
actually
do
have
to
do
some
engineering
efforts
there
as
well
just
I'll
mention
a
past
discussion
that
happened
several
months
to
go.
There
has
been
mentions
of
this
I'll
mention
it
again.
A
We
are
not
the
only
project
that
has
run
into
a
situation
like
this,
so
there
are
other
projects
that
I've
implemented
there.
Custom
versions
of
the
ins,
vs,
GL
and
publicize
them.
Ea
has
EA
STL
adobe
has
STL
lab.
So
as
an
idea
if
we
were
to
move
away
from
STL
and
backing
into
something
closer
to
the
TR
containers.
Maybe
one
approach
we
take
is
to
rebuild
the
TR
containers
using
STL
style
interfaces
and
possibly
change
a
lot
of
DN
variants
so
that
they
are
more
suited
to
our
memory,
management
and
yeah.
B
I
believe
Ruth
up
does
I
mean
that
I
guess
I
wasn't
trying
to
propose
that
we
would
go
back
to
the
stock,
see
our
data
structures.
We've
all
encountered
at
least
one
issue
with
in
the
past.
I
guess
I
would
look
at
it
as
any
like
we're
we're
on
a
path
where
we're
going
to
end
up
spending
a
bunch
of
time
reworking
the
code
in
order
so
again
use
more
STL.
B
If
we
want
to
unify
on
a
single
thing,
we
have
to
do
work,
I
guess
the
question
is:
do
we
do
that
work
to
unify
an
STL
to
do
that?
Work
unify
on
a
better
version
of
the
TR
data
structures
like
you're,
proposing
I?
Guess
the
option
is
there
to
choose
another
library
or
even
leverage?
One
of
the
libraries
you
just
talked
about
they're
available,
open
source
and
the
license
is
amenable
right.
You're
not
also
might
be
appropriate,
but
their
needs.
Their
requirements
may
not
match
our
requirements.
A
Do
you
know
anything
about
standing
those
fibers?
Thank
you
know,
for
example,
if
the
memory
allocation
model
that
they
is
it
pretty
much
following
the
delivery
and
of
I,
don't
know
the
details
and
I
believe
ei
STL,
one
of
the
big
issues
they
ran
into
and
that
motivated
them
to
write
their
custom.
Stl
was
memory
management.
It
developing
games
that
run
into
the
problem
of
having
to
constantly
allocate
object
and
move
things
around
in
memory
as
the
game
progressed
and
so
EAS
GL
was
designed
to
make
that
easier
to
do.
B
On
I
guess
one
of
those
one
of
the
things
that
people
always
point
painful
about
people's
plusses
likely
as
a
measure
of
memory,
and
we
seem
to
be
currently
on
a
path
towards
making
people
manage
their
own
memory
more
so
than
the
earlier
programming
normal
I
guess.
Just
because
of
this
connection
to
SQL
over
SPL.
Has
this
assumption,
linear?
B
B
Because
you
you're
not
managing
your
allocation
de-allocation
story
properly,
but
we
were
a
little
bit
too
loose
in
how
we
did
that
in
we
kind
of
allowed
people
to
the
freedom
to
do
whatever
the
hell
they
wanted,
which
means
you
could
put
together
things
that
you
know
if
you
freed
your
region
at
the
wrong
time.
Work
or
if
you
had
some
container
that
was
holding
on,
have
the
right
light,
shines
right.
The
light
problem
we're
talking
about.
You
could
end
up
accessing
skilled
ed
data.
A
B
Well
again,
I
was
just
trying
to
spark
a
discussion
at
this
point.
Does
it
feel
like
we're
in
a
holding
pattern?
I
guess
we're
not
really
actively
doing
more
work
right
now
to
convert
things
to
STL
I
know,
developers
are
feeling
free
to
use
STL
in
places
where
it's.
You
know
the
right
thing
to
use.
That's
fine,
but
the
we
should
have
a
strategy
here.
I
think
it's
actually
even
more
important.
Now
that
I've
realized
that
cs2
is
still
as
prevalent
as
it
is,
and
we've
cut
three
things
alone
in
the
compiler.
B
B
A
B
C
C
Okay,
there's
also
another
side
using
a
scale
which
is
the
algorithms
yep
I
mean
not
to
say
that
we're
taking
full
advantage
of
that
today,
but
he
has
that
potential
as
well.
For
example,
I'd
love
to
be
able
to
iterate
block
with
an
iterator
just
for
incoming
DNA
to
write
everybody
then
calling
god-knows-what
API.
B
You
make
us
something
it,
but
it's
not
really
just
inductive
on
whatever
container
you
have
like
creating
integrator
the
container
it
syntactic
sugar
is.
That
makes
it
that
that
can
avoid
bug.
Yeah
I,
don't
think
we
shouldn't
have
them
under
saying
it's
like.
We
could
create
that
syntactic
trigger
on
top
of
any
container
really.
So
we
could
replicate
that
be
inductive
trigger
score.
C
C
B
Are
the
pieces
that
we
use
in
the
compiler,
where
we
use
an
iterator
as
complicated
as
those
ones
are
designed
to
be
able
to
handle
I
guess
if
you're
gonna,
design,
iterator
framework
that
can
handle
any
kind
of
container
that
anybody
could
write?
That
sounds
to
me
like
a
complicated
problem,
but
we
have
you
know
we
have
not
a
single
data
structure
but
like
ril
is.
C
A
D
D
A
A
Well,
we
also,
though
it
would
do
what
I
was
suggesting,
was
more
something
along
the
lines
of
what
group
companies
like
EA
have
done,
where
they
think
they've,
essentially
reimplemented
the
STL
but
specialized
for
their
own
needs.
So
the
interface
is
almost
identical
to
STL,
but
they
have
different
invariants
that
make
it
easier
to
integrate
with
their
products.
So.
D
B
A
Could
have
that
work
at
that
effort,
I've
gone
if
we
hadn't
done
okay,
so
the
the
TR
data
structure
issue
it
I
wouldn't
say
that
these
are
the
most
generic
data
structures.
I
think
that
the
way
that
they
they
were
there
I
don't
think
they
were
ever
over
engineered
they're,
always
engineered
and
to
use
a
minimal
amount
of
what
we
only
need.
The
last
thing
that
would
call
them
back
and
fall
so
yeah.
So
so
it's
not
like
they
are
trying
to
felt
like
AE.
You
can't
have
multiple
threads
writing
to
them.
C
A
A
A
A
If,
hypothetically,
if
we
were
to
go
and
implement
our
own
interesti
L
containers,
we
could
hide
a
lot
of
the
memory
management
behind
those
interfaces
and
users
don't
have
to
worry
about
passing
custom
allocators
around
or
any
of
that,
and
that
would
be
one
potential
example
if
we
find
some
other
SQL
implementation
that
will
more
closely
follow
what
our
model
of
for
memory
management
is.
I
would
also
work,
but
I
guess
what
I
was
going
to
say
is.
A
D
A
And
for
the
record,
we've
technically
already
have
a
custom
STL
implementation
for
STD
for
word
list,
which
it
only
exists
in
C++
11,
and
that
was
to
accommodate
some
requirements
that
we
could
not
be
with
other
standard
SQL
containers,
but
actually
that's
a
good
point
about
the
build
compiler.
That
is
a
constraint
that
we
have
with
this.
D
B
They
have
rights,
those
types
of
security
structures
and
so
on,
which
are
duplicated
with
Testarossa
because
they
used
to
be
in
completely
separate
places
right.
So
it
was
well
I,
never
developed
completely
independently.
So
it's
not
unexpected
that
they
would
have
two
different
versions
of
things,
but
now
that
everything
is
in
the
same
codebase-
and
you
know
in
principle-
we
could
be
trying
to
unify
on
a
single
step
of
those
things
and
I'm.
B
Not
sure
that
he's
put
words
in
his
mouth
I
guess
is
he's
not
on
the
call
but
I,
don't
think
Charlie's
thinking
that
we
would
have
a
single
linked
list
that
the
compiler
and
the
GC
and
all
the
VM
routines
would
all
use
I
think
what
he's
what
he's
going
after
is.
We
should
have
a
common
set
of
containers
across
the
project
that
are
that
satisfy
the
requirements
of
everything
in
the
project
right.
B
We
should
feel
free
to
move
containers
that
are
useful
for
into
one
place
within
the
project.
I
have
a
problem,
I
think
that's
appropriate
anyway,
that's
like
I,
say
I'm
putting
words
in
his
mouth,
so
bad
I
assume
he'll,
either
listen
to
this
or
read
the
notes
from
the
conversation
and
and
correct
my
words
where
they
shouldn't
be
coming
out
of
his
mouth.
B
And
the
argument
isn't:
I
guess
that
destiel
is
not
useful
question
of
its
trade
offspring,
whether
or
not
says
the
good
things
that
we're
getting
from
STL
those
ones.
You're
mentioning
are
good
enough
to
warrant
fest
we're
getting
work.
I
guess
that
would
probably
reverse
the
question.
Are
the
bad
things
bad
enough
that
we
should
try
to
get
some
of
the
goodness
elsewhere?
Worse
than
some
of
the
way.
A
Aspirationally
we
want
to
have
one,
but
there's
not
really
any
kind
of
drive
to
get
us
to
one.
So
I
think
unless
there
is
some
kind
of
a
plan
with
much
more
refined
steps,
we're
going
to
be
stuck
in
this
state
forever
and
really
realistically,
because
any
and
any
and
any
kind
of
changing.
We
already
know
the
amount
of
turn
that
we
went
through
to
get
to
convert
the
the
TR
lists,
we're
almost
of
the
TR
list
into
the
the
STL
type
and.
B
A
Will
continue
to
happen
to
go
through
and
replace
all
the
other
data
structures
as
well,
that
has
to
be
factored
into
the
planning
so
I
think
perhaps
the
outcome
of
this
is.
Is
it's
going
to
be
the
direction
that
we
want
to
go
into
like?
This
will
be
a
sort
of
artificial
path
that
we
want
to
pee
on
now
that
we
can
have
to
figure
out
how
we're
going
to
how
we're
going
to
get
there.
But
it's
really
time
to
decide
on.
A
We
want
to
stick
with
STL
or
not
so
I
think
what
I'll
do
is
I'll
create
an
issue
with
where
people
can,
especially
those
that
are
not
on
not
on
the
call
right
now
and
certainly
add
their
thoughts
and
then
I
guess
we
can
circle
back
at
a
later
time
and
and
look
at
all
the
opinions
and
ideas
and
those
that
have
come
out
from
that
and
figure
out
some
actions.
From
from
that
that
we
can
move
forward,
yeah.