C stdlib .h на C ++ и malloc / realloc

Question

Я был действительно обеспокоен включением функций C stdlib в глобальное пространство имен и закончил писать такие вещи, как :: snprintf или :: errno или struct :: stat, и т. Д. , чтобы отличаться от некоторых моих собственных функций во вложенном пространстве имен, где использовались эти функции c stdlib.

Затем я обнаружил, что есть способ объявить каждую функцию C stdlib в пространстве имен std (как STL): просто включите вместо <(lib) .h>, поэтому я отредактировал свой код использование тех новых "c для c ++" включает в себя.

Вкл. Debian / GCC 4.3.4 У меня было 2 проблемы:

1) #error Этот файл требует поддержки компилятора и библиотеки для предстоящего \ Стандарт ISO C ++, C ++ 0x. Эта поддержка в настоящее время является экспериментальной и должна быть включается с помощью параметров компилятора -std = c ++ 0x или -std = gnu ++ 0x.

2) с использованием -std = c ++ 0x моя программа компилируется просто отлично, но я не модифицировал :: snprintf или :: time и т. Д., Каждая функция C stdlib все еще находится в глобальном namespace = (! (нет, я не использую пространство имен std ни разу)

Есть мысли?

Например .. как остановить cddlib от вторжения в мое глобальное пространство имен? является экспериментальной функцией следующего стандарта C ++ или его можно безопасно использовать прямо сейчас?

Тогда у меня есть еще одно сомнение, которое, возможно, заслуживает нового вопроса ... нет cmalloc. Я знаю всю историю о новых заменяющих malloc и почему. но для простых простых байтовых буферов не существует эквивалента c ++ realloc . Я знаю, что блоки памяти и перераспределение зависят от реализации / реализации, но при наличии смежных свободных блоков памяти realloc работает лучше, чем новое выделение буфера и копирование памяти.

Спасибо =)!

Answer 1

Функция malloc() в стандартном C не объявлена ​​в заголовке "<malloc.h>". Объявлено в <stdlib.h>. То же самое для realloc() и free().

Я не знаю о C ++, но вместо

#include <cmalloc>

1011 * попробовать *

#include <cstdlib>

Answer 2

Ваш первый вопрос зависит от того, какие заголовки вы пытаетесь включить. Большинство заголовков C доступны в форме c(lib) в существующей версии C ++. Некоторые нет, и могут быть добавлены в C ++ 0x. Поэтому, если вы попытались включить какой-либо из них, возможно, вы получили эту ошибку.

Во-вторых, все заголовки этой формы гарантируют , что функции будут доступны в пространстве имен std. Но они не обещают оставить глобальное пространство имен в покое. Часто они помещают символы в оба пространства имен.

Я не уверен, почему ::snprintf беспокоит вас больше, чем std::snprintf. Вы должны указать префикс в обоих случаях.

Что касается realloc, эквивалента в C ++ не существует, возможно, потому, что это больше проблем, чем стоит, особенно с более сложной семантикой C ++ для копирования объектов. (В частности, если вы попытаетесь использовать его, не храните в буфере объекты, не относящиеся к POD, поскольку realloc просто memcpy переместит их во вновь выделенный буфер, если необходимо, что приведет к поломке объектов, не являющихся POD. )

Конечно, вы все еще можете использовать старый realloc из C, включив его заголовок. Но я бы сказал, что вам, вероятно, лучше использовать new / delete и просто выяснить разумную стратегию распределения буферов.

Answer 3

Существуют некоторые стандартные заголовки C , которые еще не переведены в . Возможно, вы использовали или что-то подобное.

С текущим стандартом у вас есть библиотеки c, перечисленные здесь . Обратите внимание, что является не его частью.

Я не нашел ссылку, описывающую, будет ли частью c ++, но если я попытаюсь включить ее, я также получаю сообщение об ошибке, говорящее мне, что я должен использовать -std = c ++ 0x поэтому я предполагаю, что планируется включить его в следующий стандарт c ++.

Answer 4

c , который приблизительно включает .h в namespace std { }, является стандартной функцией C ++. См. §17.4.1.2, если у вас есть доступ к любому из стандартов.

Это вообще не экспериментальная функция - какой заголовочный файл вызывает проблемы с совместимостью?

Используя malloc et al. это хорошо, но будьте уверены, никогда не смешивать их с новым / удалить. (например, не delete a malloc() 'ed буфер.)