LINUX.ORG.RU

C != C++


0

0

http://david.tribble.com/text/cdiffs.htm

Сравнение Си и Цпп. Примечательно, что Си содержит массу фич, не поддерживаемых C++, например

C99 supports variable-length arrays, which are arrays of automatic storage whose size is determined dynamically at program execution time. For example:

size_t sum(int sz)
{
float arr[sz]; // VLA, dynamically allocated

while (sz-- > 0)
arr[sz] = sz;
return sizeof(arr); // Evaluated at runtime
}

C++ does not support VLAs.

Надеюсь красноглазые фанаты уяснят наконец, что это разные языки. С++ - не улучшеный Си.

★★
Ответ на: комментарий от watashiwa_daredeska

> Про всех не знаю, однако у SBCL и Erlang, как минимум, с многопоточностью все в порядке, чего нельзя сказать об auto/shared_ptr в C++.

btw если не секрет, какие проблемы у boost::shared_ptr с многопоточностью?

Thread Safety

--- boost docs ---
Thread Safety

shared_ptr objects offer the same level of thread safety as built-in types. A shared_ptr instance can be "read" (accessed using only const operations) simultaneously by multiple threads. Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)

Any other simultaneous accesses result in undefined behavior.

Examples:

shared_ptr<int> p(new int(42));

//--- Example 1 ---

// thread A
shared_ptr<int> p2(p); // reads p

// thread B
shared_ptr<int> p3(p); // OK, multiple reads are safe

//--- Example 2 ---

// thread A
p.reset(new int(1912)); // writes p

// thread B
p2.reset(); // OK, writes p2

//--- Example 3 ---

// thread A
p = p3; // reads p3, writes p

// thread B
p3.reset(); // writes p3; undefined, simultaneous read/write

//--- Example 4 ---

// thread A
p3 = p2; // reads p2, writes p3

// thread B
// p2 goes out of scope: undefined, the destructor is considered a "write access"

//--- Example 5 ---

// thread A
p3.reset(new int(1));

// thread B
p3.reset(new int(2)); // undefined, multiple writes

--- boost docs ---

IMHO указанного поведения вполне достаточно для большинства применений.

ну например, кеш каких-то динамических объектов. std::map<key, boost::shared_ptr<foo> >. доступ к самому map-у естественно защищён отдельным мьютексом. цель состоит в том, чтобы получив после поиска по кешу обернутый указатель на объект работать с ним сколько влезет не беспокоясь если кто-то вдруг решит в это время удалить объект из кеша. по крайней мере, это пример вполне работает.

ps: у std::auto_ptr по понятным причинам проблем с многопоточностью нет в принципе как класса.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> btw если не секрет, какие проблемы у boost::shared_ptr с многопоточностью?

Да, неправильно в свое время понял документацию при чтении по диагонали :) Каюсь.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

Кстати, ради спортивного интереса взял тот тест с шутаута, заменил все указатели на boost::shared_ptr<Node> и убрал все delete.

Для моей машины:
Оригинальный тест: 3.7+-0.1с
Тест с shared_ptr: 15.5+-0.1с

Разница в 4 раза, однако. Память не мерял, но shared_ptr делает лишнее выделение на каждый счетчик, по идее. Хотя, может оптимизирует как-то, не проверял.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от klalafuda

> у std::auto_ptr по понятным причинам проблем с многопоточностью нет в принципе как класса.

Потенциально есть. Пусть auto_ptr<int> x является owner'ом объекта, тогда:

Thread A:
auto_ptr<int> y(x);

Thread B:
auto_ptr<int> z(x);

Потенциально, возможна ситуация, когда и y, и z получат ownership.

<5minutes skipped>

Глянул в исходники. Все вертится вокруг метода release:

element_type*
release() throw()
{
  element_type* __tmp = _M_ptr;
  _M_ptr = 0;
  return __tmp;
}

потоконебезопасность очевидна, по-моему.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

>> у std::auto_ptr по понятным причинам проблем с многопоточностью нет в принципе как класса.
> Потенциально есть. Пусть auto_ptr<int> x является owner'ом объекта, тогда:

хм. я имел ввиду, что std::auto_ptr by design потоконезащищенный и использовать его без дополнительных средств синхронизации мягко говоря неразумно.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> я имел ввиду, что std::auto_ptr by design потоконезащищенный и использовать его без дополнительных средств синхронизации мягко говоря неразумно.

Это не называется "отсутствие проблем". Это называется "положили болт". В результате, программист должен отслеживать (пусть и на "рефлекторном" уровне) еще и потокобезопасность, реализуя ее, возможно, самостоятельно.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

> Это не называется "отсутствие проблем". Это называется "положили болт". В результате, программист должен отслеживать (пусть и на "рефлекторном" уровне) еще и потокобезопасность, реализуя ее, возможно, самостоятельно.

ну [пока?] в стандарте C++ в принципе нет ничего, что как-то могло бы касаться распараллеливания и потоков в том числе. так что это общий подход.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>ну [пока?] в стандарте C++ в принципе нет ничего, что как-то могло бы касаться распараллеливания и потоков в том числе. так что это общий подход.

ЕМНИП в 0х какую-то поддержку потоков сделают. В отличии от GC.

anonymous
()
Ответ на: комментарий от klalafuda

> так что это общий подход.

Для стандартного C++ -- да, именно руководствуясь им я неправильно понял документацию по shared_ptr. Однако, насколько я знаю, в 0x включат shared_ptr'ы. Внимание, вопрос: останутся ли shared_ptr по прежнему потокобезопасны, а auto_ptr по прежнему потоконебезопасны?

К слову, такого мелкого барахла с совместимостью в C++ накопилось уже порядком. Например, пресловутые "for( int i=0; ...". Помнится, в середине 90-х i принадлежала внешнему контексту, теперь -- внутреннему. Плохо то, что нельзя изменить поведение локально для, скажем, legacy-кода. Это означает, что при написании программы на C++ никогда не знаешь, что отвалится лет через 10, когда выйдет очередной стандарт.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

>Это означает, что при написании программы на C++ никогда не знаешь, что отвалится лет через 10, когда выйдет очередной стандарт.

Ну сравните с тем же питоном, в котором в каждой версии что-то ломают :) Язык развивается и имхо обратную совместимость ломают не много и не часто. Поэтому туча костылей и тянется за ним ))

anonymous
()
Ответ на: комментарий от watashiwa_daredeska

> Для стандартного C++ -- да, именно руководствуясь им я неправильно понял документацию по shared_ptr. Однако, насколько я знаю, в 0x включат shared_ptr'ы. Внимание, вопрос: останутся ли shared_ptr по прежнему потокобезопасны, а auto_ptr по прежнему потоконебезопасны?

ну когдааа их включат и когда это ещё расползется по миру и будет ли воспринято общественностью вообще - много вопросов. so я бы не стал уповать на это. тем более, что старый дедовский способ распараллеливания операций в миллионе реинкарнаций на любой вкус и цвет прекрасно работает.

IMHO поздно вносить что-то новое или менять существующее в стандарте C++. разве что явные багфиксы. скажем то, что туда идет из того-же boost уже давно есть в самом boost и все, кому это нужно, им пользуются.

> К слову, такого мелкого барахла с совместимостью в C++ накопилось уже порядком. Например, пресловутые "for( int i=0; ...". Помнится, в середине 90-х i принадлежала внешнему контексту, теперь -- внутреннему. Плохо то, что нельзя изменить поведение локально для, скажем, legacy-кода. Это означает, что при написании программы на C++ никогда не знаешь, что отвалится лет через 10, когда выйдет очередной стандарт.

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

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

Си :-D

mv ★★★★★
()
Ответ на: комментарий от mv

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

> Си :-D

я видел и участвовал в коммерчески успешных проектах, выполненных в большей своей части на C. причем объем кода существенно превышает текущий объем, скажем, ядра Linux. и ни разу не видел разработчиков, которые бы сегодня с уверенностью могли сказать "да, в свое время мы поступили правильно выбрав C". ни-ра-зу. period.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> ни-ра-зу. period.

Вы видели unix? Коммерчески успешный проект, сформировавший современную вычислительную реальность :) Написан на Си большей своей частью

mv ★★★★★
()
Ответ на: комментарий от mv

> Вы видели unix? Коммерчески успешный проект, сформировавший современную вычислительную реальность :) Написан на Си большей своей частью

чтобы ответить на этот вопрос, я бы хотел уточнить: что именно вы понимаете под UNIX?

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> чтобы ответить на этот вопрос, я бы хотел уточнить: что именно вы понимаете под UNIX?

Непосредственно ОС: её ядро и минимальный набор юзерспейс утилит.

mv ★★★★★
()
Ответ на: комментарий от mv

>> чтобы ответить на этот вопрос, я бы хотел уточнить: что именно вы понимаете под UNIX?

> Непосредственно ОС: её ядро и минимальный набор юзерспейс утилит.

какую именно OS? кто вендор? текущая версия? ссылка? etc.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от anonymous

> Ну сравните с тем же питоном, в котором в каждой версии что-то ломают :)

?

> Поэтому туча костылей и тянется за ним ))

За питоном тоже, в 3.0 решили полмать и от них избавиться.

sv75 ★★★★★
()
Ответ на: комментарий от klalafuda

Чего ожидали? Что я буду уверять вас в том, что начиная с первого творения в недрах bell labs, давшее это слово (unix), и заканчивая тем же линуксом (вроде бы и не совсем unix) ядро и binutils пишется на Си? Представьте, не буду, не вижу смысла. Вы сейчас до столба докапываетесь.

mv ★★★★★
()
Ответ на: комментарий от mv

> Вы видели unix? ... Написан на Си большей своей частью

Master Foo and the Ten Thousand Lines ?

sv75 ★★★★★
()
Ответ на: комментарий от mv

> Чего ожидали?

я ожидал, что вы не в состоянии дать определение "OS UNIX" сегодня, ни ссылки на эту "OS" ни тем более результатов её финансового выхлопа для владельцев. пока что мои ожидания подтверждаются.

> Что я буду уверять вас в том, что начиная с первого творения в недрах bell labs, давшее это слово (unix), и заканчивая тем же линуксом (вроде бы и не совсем unix) ядро и binutils пишется на Си? Представьте, не буду, не вижу смысла. Вы сейчас до столба докапываетесь.

в пояснении что "ядро Linux написано на C" действительно смысла не так много.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> я ожидал, что вы не в состоянии дать определение "OS UNIX" сегодня, ни ссылки на эту "OS" ни тем более результатов её финансового выхлопа для владельцев. пока что мои ожидания подтверждаются.

Вы вообще адекватны? Какие финансы, какое текущее состояние?

mv ★★★★★
()
Ответ на: комментарий от klalafuda

>ну [пока?] в стандарте C++ в принципе нет ничего, что как-то могло бы касаться распараллеливания и потоков в том числе. так что это общий подход.

ну вообще есть же уже openmp, чем не стандарт

acefsm
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.