public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
* Bare metal C++ with a GNU/Linux toolchain
@ 2022-05-18 11:16 Florian Weimer
  2022-05-18 17:03 ` François Dumont
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2022-05-18 11:16 UTC (permalink / raw)
  To: libstdc++

It seems that it is fairly straightforward to eliminate dependencies on
libstdc++ if only a C++ subset is used (no exception handling, no RTTI,
no operator new, etc.).  But once you use abstract classes, you
necessarily gain a reference to __cxa_pure_virtual.

Would it be possible to document this symbol as interposable, so that
developers can bring their own definition if they want?  If yes, what
would be the appropriate place for this?

Thanks,
Florian


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bare metal C++ with a GNU/Linux toolchain
  2022-05-18 11:16 Bare metal C++ with a GNU/Linux toolchain Florian Weimer
@ 2022-05-18 17:03 ` François Dumont
  2022-05-18 19:13   ` Jonathan Wakely
  0 siblings, 1 reply; 3+ messages in thread
From: François Dumont @ 2022-05-18 17:03 UTC (permalink / raw)
  To: Florian Weimer, libstdc++

On 18/05/22 13:16, Florian Weimer via Libstdc++ wrote:
> It seems that it is fairly straightforward to eliminate dependencies on
> libstdc++ if only a C++ subset is used (no exception handling, no RTTI,
> no operator new, etc.).

Those C++ features are in libsup++, not libstdc++.

You should still be able to use full C++ without libstdc++.

I used to do so when working on STLport but it was such a long time ago 
that the way we were doing it is surely outdated.


>    But once you use abstract classes, you
> necessarily gain a reference to __cxa_pure_virtual.
>
> Would it be possible to document this symbol as interposable, so that
> developers can bring their own definition if they want?  If yes, what
> would be the appropriate place for this?
>
> Thanks,
> Florian
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Bare metal C++ with a GNU/Linux toolchain
  2022-05-18 17:03 ` François Dumont
@ 2022-05-18 19:13   ` Jonathan Wakely
  0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Wakely @ 2022-05-18 19:13 UTC (permalink / raw)
  To: François Dumont; +Cc: Florian Weimer, libstdc++

On Wed, 18 May 2022 at 18:04, François Dumont via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On 18/05/22 13:16, Florian Weimer via Libstdc++ wrote:
> > It seems that it is fairly straightforward to eliminate dependencies on
> > libstdc++ if only a C++ subset is used (no exception handling, no RTTI,
> > no operator new, etc.).
>
> Those C++ features are in libsup++, not libstdc++.

Yes, but that's still part of the libstdc++ project and so documenting
this in the libstdc++ manual is probably the right place (but I'm not
sure where in the manual yet).


>
> You should still be able to use full C++ without libstdc++.
>
> I used to do so when working on STLport but it was such a long time ago
> that the way we were doing it is surely outdated.
>
>
> >    But once you use abstract classes, you
> > necessarily gain a reference to __cxa_pure_virtual.
> >
> > Would it be possible to document this symbol as interposable, so that
> > developers can bring their own definition if they want?  If yes, what
> > would be the appropriate place for this?
> >
> > Thanks,
> > Florian
> >
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-05-18 19:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-18 11:16 Bare metal C++ with a GNU/Linux toolchain Florian Weimer
2022-05-18 17:03 ` François Dumont
2022-05-18 19:13   ` Jonathan Wakely

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