Mam mieszany program C / C ++. Zawiera parser flex / bison, który celuje w C, podczas gdy reszta to C ++.

Będąc C, wygenerowany parser i skaner zarządzają swoją pamięciąmalloc, realloc ifree. Są wystarczająco dobre, aby ujawnić haczyki, dzięki czemu mogę przedstawić własne implementacje tych funkcji. Jak można się spodziewać, reszta programu (C ++) „chce” korzystaćnew, deleteitd.

Przeprowadzenie niewielkich badań wydaje się wskazywać, że odpowiednie normy nie gwarantują, że takie mieszanie powinno działać. Szczególnie „sterta” C niekoniecznie jest „wolnym obszarem” C ++. Wygląda na to, że te dwa schematy mogą się wzajemnie deptać.

Ponadto, pewnego dnia (wkrótce) ten program prawdopodobnie będzie chciał zintegrować niestandardową implementację sterty, taką jaktcmalloc, używane przez C i C ++.

Jaka jest tutaj „właściwa” rzecz?

Biorąc pod uwagę chęć zintegrowania tcmalloc (co wyjaśnia, jak łączyć się z programami C), kusi mnie, aby znaleźć jakiś sposób na zarządzanie przeciążeniem pamięci w C ++, typu cross-thread, cross-everything, cross-everything. Dzięki temu mogłem skierować wszystkie wywołania / zwolnienia C ++ z powrotem do ich odpowiedników C (które z kolei lądują na tcmalloc).

Czy istnieje taki pan-galaktyczny globalny hak C ++? Może już robi to, co chcę, podobnie jakios_base::sync_with_stdio domyślnie potajemnie poślubia iostream i stdio?

Nie jestem zainteresowany rozmawianiem o stdio vs. iostreams, ani o przełączaniu generatorów parsera ani o użyciu szkieletów C ++ flex / bison (wprowadzają niezależne bóle głowy).

EDYTOWAĆ: Proszę podać nazwy tych sekcji standardu C ++, które obsługują odpowiedź.