►
From YouTube: 2019-10-07 C/C++ SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
D
A
G
A
G
A
H
A
I
F
D
I'll
go
hi,
I'm,
Josh
I'm
at
my
staff
working
on
opens
on
the
tree
at
the
moment
and
I
was
at
Google
writing
C++
a
long
time
ago
for
a
good
13
years,
or
so
so.
I
haven't
written
C++
since
then,
but
I
feel
I
know
it
pretty
well
and
I'm
here
to
help
kick
it
off,
so
I've
basically
been
reviewing
code
for
Ryan
for
the
last
couple
years.
Only.
J
Having
some
issues
with
my
network
today,
sorry
I've
done
a
bunch
of
work
on
a
consensus,
C++
and
I
work
on
the
internal
census
of
Google
as
well.
H
A
H
A
Set
it
up
and
never
you
know,
like
you,
feel
the
time
is
too
challenging
for
you.
Please.
Let
me
know
I'll
try
to
make
a
fairer
combination.
Okay,
so
now
down
to
the
real
problems
here,
I'll
start
all
those
real
politics
here
and
guys.
Will
you
take
a
look
at
the
agenda
and
see
I
know
some
folks.
You
might
not
have
enough
time
to
add
your
topic.
So
if
you
remember.
A
Now
is
that
the
agenda
document,
so
we
will
cover
that
quickly
and
I
think
we
have
a
short
meeting.
So
the
goal
is
to
help
people
to
know
each
other
and
quickly
go
through
the
topic.
Instead
of
spending
like
hours
talking
about
which
office
oh
I
was
supposed
to
do
the
time
management.
Every
single
topic
should
not
take
more
than
five
minutes.
A
I'll
do
my
job
so
the
first
topic
should
we
do
C
or
C++
or
both,
or
we
should
separate
that
the
question
is:
there
are
some
scenario
where
people
use
C
and
the
different
answer
could
be:
let's
create
open
climate
receipt
as
past
and
create
yet
another
open
country
C.
So
there
are
two
different
repos
different
group
of
people
and
they
don't
work
together,
so
they
just
do
whatever
they
want,
or
we
have
a
single.
A
Seconds
or
so,
okay-
oh,
oh
all,
right
kid!
So
in
my
opinion
we
have
different
options.
We
can
have
an
open,
telemetry,
see
an
open
chemistry,
c++,
separate
room
or
separate
people
working
on
that
different
product
and
I
think
this
is
a
bad
idea
in
my
personal
opinion,
but
would
like
to
be
convinced.
Another
approach
is
we
only
care
about
C++
now,
which
doesn't
seem
to
be
an
option
for
me,
I
think
about
how
scenario
where
people
you
see
and
they
want
to
see
interface,
so
you
know,
can
you
mention.
A
Not
work,
okay,
so
they're
embedded
the
scenario
where
you
turn
it
like
very
low
power
consumption
devices
and
they
don't
have
a
cross
compilation
story.
So
they
have
a
limited,
compile
panel
environment.
Where
do
you
see
only
the
means,
if
you
jump
any
C++
code,
the
compiled
complain,
I,
don't
know
how
to
compile
this
and
and
I
know
like
there.
There
are
scenarios,
but
we
got
to
pick
what
scenario
we're
trying
to
support
right:
we're
not
going
to
support
like
the
IBM
mainframes
for
now.
A
So
my
proposal
would
be
having
a
C++
library
and
having
a
theory
about
how
that,
in
the
FASTA
pass
class,
we
try
to
be
powerful
what
we
use
and
what
not
to
use
for
them.
How
exceptions
are
TTI,
those
things
we
got
to
be
careful,
Hamlet
might
be
okay,
man,
not
if
you
don't
consider
the
binary
size
bloating,
those
things.
So
those
are
the
things
we
can
explore,
but
the
basic
idea
is
to
have
English.
F
G
We
can
also
do
what
what
G
RPC
does
I
don't
know.
You
should
know
what
they
do.
I
think
that
may
be
a
compromise
as
well.
Can
you
explain
that
reason?
So
there
is
a
there
is
a
core
library
that
is
sure
between
C
and
C++
or
any
other
implementation,
and
that
core
library
has
three
requirements
in
terms
of
what
features
from
C++
you
can
use
and
stock,
and
then
you
have
a
public
C++
API
on
top
of
that,
and
you
have
a
public
C
API
on
top
of
that
core
library.
J
They
that
was
kind
of
a
compromise,
and
it
made
things
very
messy
for
them
and
I
think
like
who
really
uses
the
C
style
bindings
for
G
RPC
and
that's
another
thing
like.
Even
if
we
have
you
know
a
light
library,
how
do
we
get
stats
and
traces
and
things
off
of
the
task
or
off
of
this?
You
know,
embedded
platform
yeah.
F
D
D
A
A
B
Now
you
can
say
you
can
have
some
sort
of
C++
bridge
that
you
statically
link
into
a
C
library.
So
what
I
would
propose?
Is
you
have
a
separate,
C
API
and
then,
if
you
want
to
bridge
that
to
the
C++
tracing
library,
you
can
do
that
and
provide
a
binary
that
statically
links
in
the
standard,
C++
library,
yeah.
B
Variables
like
there's
a
global
tracer
concept,
which
wouldn't
necessarily
work
that
well
with
a
cure
header,
library,
I,
think
you
might
be
able
to
separate
part
of
it
part
of
the
API
and
have
a
pure
header
implementation,
then,
for
global
variables
and
things
and
inside
of
a
static
library.
They
want
to
link
that
I
see.
C
B
I
think
the
way
most
libraries
are
set
up
is
there's
a
global
variable.
You
have
to
register
it
so,
for
example,
there'd
be
a
global
tracer
and
you
could
construct
a
tracer
and
register
that
to
the
global
variable.
So
it
doesn't
necessarily
impose
a
tracer
on
you,
so
you
could
construct
a
tracer
with
whatever
Chancellor
you
want
and
then
register.
That's
it.
Let's
see.
A
A
F
Similarly,
for
stacker,
we've
got
customers
who
have
back-end
services
that
are
running
on
Linux,
like
Schlumberger,
and
presumably
some
of
back-end
services
running
on
Windows
as
well.
They
were
in
in
C++,
I,
think
long
term.
We
envision
support
for
iOS
and
Android
that
doesn't
necessarily
have
to
be
done
through
C++
would
imagine
iOS
support
being
written.
For
example,
Android
know.
M
C
Question
to
you
guys,
the
like
I
generally
agree
that
the
best,
for
example,
for
Android
to
utilize,
Java
HTTP,
where
Java
database
abstraction
layer,
rather
than
linking
to
a
system
sequel
like
library
from
native
code.
But
in
our
scenarios
for
Microsoft
applications.
There
are
large
modules
written
in
C++
and
we
had
sometimes
a
need
to
reverse
j'ni
from
C++
through
compatible
API
surface
up
to
Java
implementation
of
the
telemetry
stack.
D
Is
a
bit
harder,
so
I
suppose
that
we
have
had
customers
ask
us
that
they
want
to
write
Java
code
in
Android
and
C++
code
in
Android
and
have
them
both
traced
and
so
like?
It's.
You
can
imagine
having
two
independent
tracers,
but
you
could
also
prefer
to
Matt
and
I
think
having
Java
make
J&A
calls
into
C++
and
having
one
chaser
and
the
same
has
been
said
for
iOS.
D
A
That
about
it'll
be
great.
If
you
have
a
library
for
people
who
try
to
do
the
foreign
function,
interface
with
native
library,
we
want
to
be
able
to
call
into
the
C++
or
the
C
tracing
library
as
well.
This
will
share
the
tracer
or
it
has
to
be
like
two
pieces
of
code
when
inside
the
same
process
trying
to
use
some
IPC
mechanism
to
communicate,
which
is
Ryan.
A
Okay,
I
see
that
so
go
to
next
question
and
not
the
latest
issues,
and
if
you
have
more
opinions
because
we
can
discuss
there,
this
is
just
trying
to
figure
out
the
scope
of
the
questions.
So
another
hard
question.
So
how
do
we
release
them?
You
release
the
binaries.
That
means
you
have
to
make
matrix
or
you
leave
that
in
a
source
form
with
a
different
make
files
and
for
make
Fowler
like
what
kind
of
the
tooling
that
you're
using
so.
G
For
your
library,
you
don't
have
to
delete
anything,
people
will
just
statically
link,
I
mean
we'll
just
depend
on
the
librarian
will
bring
the
whole
code
and
they
will
build
for
that
platform.
I
think
it's
much
easier
in
that
way,
because
you
don't
have
to
deal
with
all
the
platforms
and
build
on
all
the
possible
platforms.
A
B
Pre-Built
binaries
actually
come
up
a
lot
with
open
tracing,
so
it's
not
necessarily
the
tracer
itself,
but
some
of
the
packages
like
nginx
a
lot
of
people.
You
know
the
build
process
is
kind
of
complicated
and
you
know
there's
a
specific
process
for
building
things
like
nginx
modules
and
stuff,
like
that.
So
what
we
do
that
is,
we
both
provide
both
the
source
and
then
as
part
of
the
CI
process.
We
produce
a
lot
of
Brian
and
burying
binaries
for
different
versions
of
nginx
and
we
statically
link
in
all
the
dependencies.
G
C
I
can
reflect
on
some
of
our
recent
experiences
where
we
used
to
have
a
nugget
package
for
some
of
our
internal
telemetry
at
the
end,
and
we
took
that
away.
That
has
been
an
adoption
blocker
for
many
of
the
smaller
teams.
Smaller
teams
do
not
like
to
build
code.
They
would
just
prefer
to
consume
some
sort
of
a
nougat
package,
or
at
least
maybe
find
a
source
form
than
a
recipe
for
VC
package
or
fo
Linux
than
a
custom
PPA
that
stuff,
because
it
might
be
an
adoption
blocker
for
a
smaller
team.
A
Wasjust
guys
started,
I
still
having
a
source
format
is
something
I
want
to
pursue
very
beginning,
and
later
we
figure
out,
we
won't
had
pre-built
package,
we
always
run
it
as
part
of
the
CI
a--
and
generated
the
binary
it's
more
about
the
responsibility.
So
when
is
your
general
binary?
People
ask
well
this
special
flight
optimized
for
them,
for
the
smallest
binary
size,
I
want
to
optimize
for
the
max
performance
or
I
want
to
maximize
for
like
develop
bility
or
something.
B
Why
would
I
would
suggest,
starting
with
both
basil
and
scenic,
there's
a
to
build
systems,
and
then
you
know
leaving
make
open
if
someone
was,
if
you
want
to
add
it
in
the
future.
So,
like
envoy,
for
example,
is
one
of
the
main
main
projects
we
target
with
instrumentation
in
there
they
use
basil,
so
we
would
want
to
integrate,
be
able
to
integrate
with
them.
Early
ERP
see
also
use
basil.
So
if.
B
C
A
A
B
A
G
Page
where
we
based
on
some
previous
experience,
we
named
maintenance
and
approvals.
Yes,
so
and
that's
how
we
name
the
first
list,
but
if,
if
there
is
a,
if
there
is
another
name
that
we
need
to
add
right
now
in
this
put
bootstrap
phase,
we
can
add
without
having
to
pass
all
the
requirements,
but
most
so
so
the
the
rule
says
in
the
bootstrap.
In
the
bootstrap
phase,
we
can
define
two
or
two
to
three
containers
to
three
approvals,
just
to
bootstrap
the
project
and
then
everything
else.
A
I
G
A
A
G
So
if
you,
if
you
think
you
will
have
time
to
spend
in
the
you
are,
you
can
do
that
you
can
propose
to
become
an
approver
and
yeah
down
some.
Some
reasoning.
Why
I
mean
the
reason
it
should
not
be?
The
fact
that
you
did
XP
is
because
you
say
that
hey
this
is
bootstrapping
phase
and
I
will
want
to
be
part
of
this
approval
because
of
my
previous
experience
with
sheep
as
well
and
whatever
things,
and
that
will
be
evaluated,
I
mean
probably
will
be,
would
be
approved.
No
problem.
G
With
the
source
file,
you
take
a
dependency
on
which
packages
you
want
so
I
think
we
should
have
separate
targets.
For
example,
in
basil,
you
should
have
separate
targets
for
the
API
for
the
SDK,
and
people
can
depend
on
the
target
that
they
need
and
then,
when
it
comes
to
release
that
we
postpone
the
decision
of
what
we're
gonna
release
as
as
final
release.
And
then
when
we
do
that
decision,
we'll
figure
it
out
how
to
speed
things
and
what.
A
On
it
and
I
need
some
help
here,
so
I
I'm
not
very
familiar
with
basil,
I
I
know
how
they
make
works
and
I
need
some
help,
ci
to
cover
all
the
build
environment.
Everyone,
but
I,
probably
can
come
up
with
code
for
trees,
contacts
and
one
build
script
for
sim
make
for
the
different
environment
in
order
to
cover
all
the
Mormon
that
we
want.
I
think
they
can
be
a
separate.
A
B
No,
that's
good
what
I
recommend
is
sort
of
using
on
boy
as
a
template,
so
they
have
a
gif
setup
where
they
have
a
script
and
then
there's
different
targets
you
can
provide
and
I
will
invoke
a
different
build
based
on
the
target
sure
in
our
light
step
project.
We
actually
use
that
as
a
template
and
we
have
a
bunch
of
different
build
tests
or
things
like
Windows
and
C
make
and
basil
mm-hmm.
G
I
think
I
think
I
think
this.
The
next
one
is
actually
part
of
the
Seavers
to
C++
I.
Think
that
Seaver
to
C++,
we
thought
we
discussed
a
bit
about
that.
But
I
think
we
haven't
made
decisions
about,
for
example,
not
using
exceptions
not
using
if
we
do
depend
on
sed
leap
or
not
or
just
on
the
handles
of
the
ACD
leap
like
GRDC
GRDC,
to
tell
everyone
GRDC
in
the
core.
G
J
B
There
are
exceptions.
What
I
would
recommend
is
keeping
most
of
the
API
know,
except
only
those
special
cases
would
be
where
you're
calling
in
API
function.
That
has
a
callback
and
then
your
callback,
you
might
throw
an
exception
and
then,
in
that
case,
I
would
expect
it
to
propagate
out
of
the
API
function.
B
B
J
J
B
J
So
Bolton,
what's
the
with
the
GOP
see
take,
does
I
mean,
like
you,
can't
have
vector.
G
G
J
G
So
the
the
point,
the
the
main
reason
they
said-
hey
se,
D
Lee-
is
different
across
platforms
and
they
have
different
behaviors
across
different
problems
and
it
may
be.
It
may
be
a
problem
for
us
to
use
as
delayed
so
they
said,
but
the
headers,
the
header
files
are
the
same
across
all
the
the
in
from
all
the
systems.
So
everything
that
is
a
template
or
something
like
that
in
the
SD
leap
it's
actually
defined
entirely
in
the
header
files.
G
J
G
C
Though,
are
we
going
to
strive
for
ABI
compatibility
when
suppose
was
API
surface?
It's
just
generally
for
some
of
our
stuff
we've
been
assuming
that
C++
API
surface.
We
do
not
try
to
provide
ABI
compat,
we
may
add
an
internal
private
member
class
definition
may
change
from
version
of
true
version.
If
you
require
version
X
you
could
have
to
use
the
corresponding
is
the
ko
recompile
from
Seoul.
So
generally
it's
been
what
we
are
suggesting
for
microsoft,
c++,
telemetry
consumers.
B
So
we'll
open
tracing
one
popular
uses
scenario:
we
have
as
people
dynamically
load
a
trace
but
use
the
open
tracing
API.
So
in
that
case,
like
some
sort
of
API
stability
is
important.
Obviously,
if
you
compile
your
tracer
with
a
different
standard
library,
then
you
know
we
don't
provide
compatibility,
but
we
try
it
API
breakage,
there's
an
actually
yeah.
What.
C
We
were
doing
Microsoft
is
a
popular
scenario.
For
example,
sdk
uses
german
three
stack
and
the
main
apples
it
uses
that,
and
so
the
plug-in
module
has
two
at
runtime,
discover
and
find
that
instance
of
telemetry
spec.
Right
now
we
agreed
that
CPI
is
the
way
to
go
for
those
guys
for
ABI
stability
and
optionally,
a
header
on
the
implementation
of
a
c++
interface
Cooksey
api
and
for
the
first
party
thing
that
doesn't
require
to
be
loaded
dynamically
at
runtime.
It
goes
full
steam
with
c++.
C
L
C
C
G
B
So
on
board,
provided
so
on
both
envoy
and
nginx
provide
this
dynamic
loading.
So
with
nginx,
for
example,
we
have
a
c++
module
that
you
would
need
to
install,
and
that
would
let
you
load
a
tracer
dynamically
at
runtime,
so
light
step
would
provide
there
dot
s
o,
which
would
be
their
tracers
implementation
of
the
open
tracing
API.
B
We
reuse
them
when
we,
so
the
loading
is
done
through
a
c
function
and
one
of
the
arguments
provides
the
ABI
version,
and
so
I
can
check
that
and
fail.
If
it
there's
a
mismatch,
we
don't
check
things
like
the
standard
C++
version,
so
we
just
assume
that
people
are
compiled
both
of
them
with
a
suitable
version
of
like
Lib
STD
C++.
C
L
B
G
Think
that
this
can
be
deferred
for
for
two
reasons.
First,
during
the
development
phase,
there
is
no
way
you
can
keep
ABI
compatibility,
you'll
still
have
new
things,
and
so
on
so
I
think
I
think
this
can
be
discussed
when
we
reach
one
zero
instability,
because
before
that
is
going
to
be
very
hard
for
us
to
ensure
this
kind
of
thing,
and
it's
going
to
be
a
very
bad
thing
to
start
with
this
right
now,.
C
It
like
folks,
like
I,
cannot
agree
with
Ren
that
fundamentally
for
Microsoft
applications.
It's
a
requirement
to
have
that
ability
to
rent
m'lord
discovered
the
version
and
late
binding
for
the
plugins
that
have
to
discover
the
main
application.
Telemetry
stack,
so
it's
kinda
a
requirement
for
us.
It
would
be
nice
to
have
if
we
have
that
on
the
agenda.
Okay,.
C
A
A
B
B
So
basically,
what
it
is
is
you
make
an
inline
namespace
and
then
that
in
Emily
space
you
use
a
tag
for
your
version
and
all
the
symbol
is
something
you
define
in
a
namespace
automatically
get
exposed.
But
when
you
link
it
has
that
in
my
namespace
is
part
of
the
the
the
name
when
it's
trying
to
do
symbol
resolution.
So
if
you
compile
with
like
the
API
and
then
you
try
to
link
to
a
newer
version
of
the
API
and
they're
no
longer
compatible
you'll
get
a
link
time
error
because
of
the
in
my
namespace.
C
We
had
that
same
practice
in
Skype
and
in
latest
we
kind
of
with
that
by
suggesting
that
people
should
rather
be
building
from
source
to
avoid
any
incompatibilities
and
for
the
ABI
we
just
got
rid
of
that.
We
said
ABI,
so
I
see
only
kinda
soak
this
in
a
way,
but
I
agree
with
you
that
it's
a
good
pattern,
whether
we
want
to
follow
that
or
not
it.
Let's
discuss.
J
B
B
C
Maybe
when
we
get
to
that,
I
mean
I,
understand
that
perhaps
the
applicability
and
boundaries
more
like
in
terms
of
Client
SDK
privacy
has
been
very
irrelevant.
It
was
not
for
the
back-end
services,
where
the
data
is
already
scrubbed
in
Hoschton.
You
know
cleaned
up,
but
what
we
omit
from
a
machine
that
belongs
to
end-user.
G
Also
also,
another
benefit
is
if,
if
we
do
go
with
the
default
implementation
SDK
as
in
open
telemetry,
the
the
API
interface
between
the
SDK
and
the
proprietary
vendor
specific
code
is
very
limited,
because
you
only
just
the
the
exporter
interface,
which
is
super
small,
and
it's
not
going
to
change.
So
that
may
be
another.
Another
reason
why
we
will
not
have
this
problem
API
API
problem,
because
if
we,
if
users
will
compile
with
the
same
a
ekayon,
SDK
version,
they
will
not
have
this
problem,
but
anyway,
I
think
I.
C
A
A
G
A
B
G
I
think
I
think
I'm
fine
Riley,
starting
with
everything
into
one
rifle
and
revisited
this
decision
in
three
months,
because
then
we
can
understand
if
if
the
seed
can
be
outside
and
we
move
it
outside
in
a
different
level,
that's
that's
a
possibility.
I
mean
you
decide.
You
are
part
of
the
sake.
Whoever
is
the
sig
member.
The
maintainer
should
make
a
decision
I'm
not
yet.