Здравствуйте, Ops, Вы писали:

Ops>Можно пункт стандарта? А то
Ops>

Ops>C ++ is a general purpose programming language based on the C programming language

Ops>совсем о другом говорит.

Вы привели верный пункт и он говорит именно об этом. Вы просто оборвали цитату в удобном вам месте.

Ops>Какие еще 10 отличий, зачем они? Такое впечатление, что не язык учат, а гномиков переворачивать.

Ну только не говорите мне, что не знаете чем malloc/free отличается от new/delete. Понимаю всю вашу боль и всё такое, но это уже как-то неприлично толсто.

Здравствуйте, Tilir, Вы писали:

T>Вы привели верный пункт и он говорит именно об этом. Вы просто оборвали цитату в удобном вам месте.
Там нет в стандарте слов "одно и то же", это разные языки, один основан на другом и включает в себя некоторые его элементы, иногда измененные, но не более.

T>Ну только не говорите мне, что не знаете чем malloc/free отличается от new/delete. Понимаю всю вашу боль и всё такое, но это уже как-то неприлично толсто.
Тем, что это разного рода сущности, а их сравнение между собой некорректно. Даже глобальный new, несмотря на схожий с malloc функционал, с ним не сравним, ибо неявно затрагивает всю программу. Так что 10 отличий, я, пожалуй, не найду, т.к. не сторонник сравнивать ежа с ужом.

Странный тест — весь о том как делать не надо. В первом вопросе очень вольные допущения об архитектуре. И конечно студенты не будут знать как надо делать чтобы все работало везде. Из второго примера — врядли он нужен. Опять пример как не надо. Я с такими crazy определениями не разу не встречался. Можете еще написать определение фу-ии на два экрана — и спросить а что там написано. Все вопросы про то как делать не надо. Я бы задавал вопросы по типу чем printf формат лучше хуже cout. Объясните в каких случаях что лучше использовать. Почему?

Здравствуйте, Ops, Вы писали:

Ops>Там нет в стандарте слов "одно и то же", это разные языки, один основан на другом и включает в себя некоторые его элементы, иногда измененные, но не более.

"Утка++ включает в себя утку, в соответствии со стандартом на утку, а кроме того содержит фасетчатые глаза, рога и пушистый хвост". Это тот же самый язык с некоторыми расширениями именно постольку, поскольку он безоговорочно включает в себя C и дальше пляшет от этого. На самом деле это LSP в действии (отношения подкласс-суперкласс, где суперклассом является C) и мне кажется, что здесь определение в стандарте читается довольно однозначно.

Ops>Тем, что это разного рода сущности, а их сравнение между собой некорректно.

С самой практической точки зрения у вас всегда есть выбор: выделить память для объекта через new или выделить память через malloc и разместить там объект посредством new. В этом смысле пока неясно есть ли разница (см. ниже).

Ops>Даже глобальный new, несмотря на схожий с malloc функционал, с ним не сравним, ибо неявно затрагивает всю программу. Так что 10 отличий, я, пожалуй, не найду, т.к. не сторонник сравнивать ежа с ужом.

Ну вот разговор и приобретает конструктивный оттенок. Давайте посмотрим поближе на фасетчатые глаза и на хвост. В процитированном вами пункте 1.1 есть явное указание (списком!) того, что C++ существенно прибавляет к C:

In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities.

Я выделил интересное. Попробуйте ответить:
1) Где именно выделяет память malloc и где именно выделяет память new?
2) В чём принципиальная фишка этого free store и почему его вдруг внесли отдельной строчкой вместе с классами и шаблонами в список самых существенных отличий, в первый пункт стандарта?
3) Какие ещё принципиальные отличия new от malloc вытекают из ответа на пункт 2?

Здравствуйте, Tilir, Вы писали:

T>Пописав на C в ООП-стиле (GTK и всё такое) можно только возненавидеть ООП, ничего больше. Я в лекциях (уже в разделе ООП) разбираю реализацию виртуальных функций на C, но в этом году я планирую выкинуть это место из лекций. Оно слишком ужасно даже на мой вкус.

T>C++ ради ООП (и я объясняю это своим студентам) приносит две жертвы, и это очень серьёзные жертвы.

T>Во-первых C++ жертвует гарантией сохранности имен в ассемблере целевой архитектуры. Это позволяет делать функции функциями-членами. А кроме того позволяет пространства имён, перегрузку, шаблоны функций и прочие вытребеньки.
T>Во-вторых C++ жертвует гарантиями по расположению полей структуры в памяти. Это позволяет вводить private и protected данные.

T>Обе эти жертвы можно не приносить, если ограничиваться extern "C" функциями и POD-типами.

T>Но если они принесены, мы должны осознавать что именно мы получаем взамен. Мы получаем полноценное ООП.

T>Именно поэтому, когда меня спрашивают что самое главное Строструп добавил в C, я всегда отвечаю: он не добавил. Он выкинул две важнейшие гарантии этого языка. Остальное после этого получилось само и ООП -- только частный случай того, что получилось.

Вы о чем вообще?
ООП подход во множестве С библиотек и программ вполне хорошо себя зарекомендовал. И чем вам не угодили реализации виртуальных функций? Если делать без наворотов, то в них нет ничего сложного.
С каких это пор в ассемблере сохраняются какие-то имена? Или вы имеете ввиду assembly, то бишь сборки? Но по ним С ничего не говорит. А когда не нужен публичный C интерфейс, то хороший тон выкидывать эти имена или заменять на mangled имена. Но само их наличие — это просто атавизм бородатых времен. Функции-члены, пространства имен, перегрузка, шаблоны и прочее тут ни при чем.
Гарантий по расположению полей структур в памяти отродясь не было. Нет даже гарантий, что эти структуры вообще будут формироваться, если они никуда не экспортируются. Да и откуда взяться таким гарантиям, если размеры базовых типов определены весьма размыто?

Здравствуйте, Tilir, Вы писали:

T>"Утка++ включает в себя утку, в соответствии со стандартом на утку, а кроме того содержит фасетчатые глаза, рога и пушистый хвост". Это тот же самый язык с некоторыми расширениями именно постольку, поскольку он безоговорочно включает в себя C и дальше пляшет от этого.
Annex C на 20 страниц, где в т.ч. принципиальные ломающие отличия — это безоговорочно?

T>С самой практической точки зрения у вас всегда есть выбор: выделить память для объекта через new или выделить память через malloc и разместить там объект посредством new. В этом смысле пока неясно есть ли разница (см. ниже).
Да дело не в памяти, new имеет функционал помимо этого.

T>Я выделил интересное. Попробуйте ответить:
T>1) Где именно выделяет память malloc и где именно выделяет память new?
Абсолютно пофигу.
T>2) В чём принципиальная фишка этого free store и почему его вдруг внесли отдельной строчкой вместе с классами и шаблонами в список самых существенных отличий, в первый пункт стандарта?
Пока устраивает базовое поведение — нет никаких принципиальных фишек, когда перестает устраивать, для new довольно просто описать свое. Как оно там внутри абсолютно не важно и зависит от реализации, мало того, в стандарте есть намек, что реализация new может дергать malloc.
T>3) Какие ещё принципиальные отличия new от malloc вытекают из ответа на пункт 2?
Никакие, принципиальные отличия в другом: bad_alloc, new_handler, в возможности перегрузки и в работе с объектами, а вовсе не в самой памяти.

Здравствуйте, Tilir, Вы писали:

T>У меня был, кстати, вариант теста по языку C, который я передумал давать студентам, потому что получилось действительно на профессионала (с моей точки зрения). Поэтому я могу вам показать как я себе представляю тест для профессионала. Как-то так.

Вот уж не знаю. Этот тест для меня проще

Местами бы больше конкретики. К примеру
"Для двух объектов, аллоцированных в разных местах, но имеющих одинаковое численное значение
указателей на них, при сравнении указателей на равенство"

Вполне может быть, в зависимости от платформы и компилятора
1) Указатели будут считаться равными (avr-gcc, указатели на flash и ram)
3) У двух указателей на объекты в разных местах не может быть одинакового значения (stm32 к примеру)
4) Такое сравнение просто не скомпилируется (iar-avr, разные типы указателей на flash и ram)

Здравствуйте, Tilir, Вы писали:

T>Во-вторых C++ жертвует гарантиями по расположению полей структуры в памяти. Это позволяет вводить private и protected данные.

а какая связь между private и расположением в памяти?

Здравствуйте, Tilir, Вы писали:

T>1) Где именно выделяет память malloc и где именно выделяет память new?

Как в библиотеке написано, там и выделяет. В newlib к примеру дергает malloc.

T>2) В чём принципиальная фишка этого free store и почему его вдруг внесли отдельной строчкой вместе с классами и шаблонами в список самых существенных отличий, в первый пункт стандарта?
И в чем его основная фишка? ИМХО, это просто какая-то казуистика начинается. Возможно есть какая-то архитектура, где new ведет себя как-то очень хитро. Стандарт описан так, что "стандартная" программа будет выполняться и на этой хитрой архитектуре.

T>3) Какие ещё принципиальные отличия new от malloc вытекают из ответа на пункт 2?

Принципиальных отличий, имхо, два
а) вызов new помимо выделения памяти еще и зовет конструктор(ы), если тот есть
б) new можно переопределить для разных типов и хранилищ

Здравствуйте, Tilir, Вы писали:

T>В связи с чем хочу выложить этот тест для местной общественности. Может будут какие-нибудь предложения, замечания, всё такое.

Прэлэстно. Поискал глазами правильный вариант «Разборчивый пишет докладную на .удаков директору Жопоразрываеву», но не нашел.

Здравствуйте, enji, Вы писали:

T>>Во-вторых C++ жертвует гарантиями по расположению полей структуры в памяти. Это позволяет вводить private и protected данные.
E>а какая связь между private и расположением в памяти?

Смотри требования POD. В новых стандартах ещё появились standard-layout.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Смотри требования POD. В новых стандартах ещё появились standard-layout.

Не, стоп. private — просто модификатор доступа. При чем тут вообще расположение? На расположение влияют наследование / виртуальные методы, но не квалификаторы доступа же

Здравствуйте, enji, Вы писали:

E>Не, стоп. private — просто модификатор доступа. При чем тут вообще расположение? На расположение влияют наследование / виртуальные методы, но не квалификаторы доступа же

C++98:

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>C++98:
EP>

EP>Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified

хм, а не знаешь, зачем так сделали?

Здравствуйте, Ops, Вы писали:

Ops>Annex C на 20 страниц, где в т.ч. принципиальные ломающие отличия — это безоговорочно?

Конечно. В месте включения никаких оговорок нет. Пункт 1.1 говорит "язык C включен полностью", чего вам сказать яснее? Что до поломок и несовместимостей, то все-таки C++ это очень пересмотренный C. Не могли же они ничего не сломать в процессе. Даже в пределах одного номера стандарта, нет-нет да и сломают что-нибудь.

T>>1) Где именно выделяет память malloc и где именно выделяет память new?
Ops>Абсолютно пофигу.

А ведь это очень важно. Представим, что malloc лезет в некий черный ящик. В стандарте явно указано: it is unspecified, лезет ли new в тот же черный ящик или берет память откуда угодно ещё. Это и только это вообще позволяет вам переопределить new.

T>>3) Какие ещё принципиальные отличия new от malloc вытекают из ответа на пункт 2?
Ops>Никакие, принципиальные отличия в другом: bad_alloc, new_handler, в возможности перегрузки и в работе с объектами, а вовсе не в самой памяти.

Прекрасно. Три отличия вы указали. Ещё одно -- new в отличии от malloc можно перегрузить -- я вам привел выше. Осталось найти ещё шесть =)

Здравствуйте, VTT, Вы писали:

VTT>С каких это пор в ассемблере сохраняются какие-то имена?

В языке C, если вы пишете

int foo (int x)

то в ассемблере вы получите метку

foo:

Вы получите её всегда. Имена функций в C не манглируются. В C++ для этого используется extern "C".

VTT> Функции-члены, пространства имен, перегрузка, шаблоны и прочее тут ни при чем.

Без манглирования имён перечисленное невозможно. Подумайте почему.

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

Здравствуйте, mavrii, Вы писали:

M> Я с такими crazy определениями не разу не встречался

Это характеризует решаемые вами задачи.

Скажем в стандарте POSIX, функция signal имеет следующую сигнатуру:

void ( *signal(int signum, void (*handler)(int)) ) (int);

И это не самый хардкор, какой я встречал.
Я учу студентов писать простой код и читать любой код.

M> Я бы задавал вопросы по типу чем printf формат лучше хуже cout. Объясните в каких случаях что лучше использовать. Почему?

Он лучше =) С вариабельными шаблонами вы можете сделать его безопасным относительно типов. Большинство языков спроектированных позже C++ имеют вывод больше похожий на printf, чем на cout. Вот скажем питон:

print '{0:2d} {1:3d} {2:4d}'.format(x, x*x, x*x*x)

Здравствуйте, Tilir, Вы писали:

T>Конечно. В месте включения никаких оговорок нет. Пункт 1.1 говорит "язык C включен полностью", чего вам сказать яснее?
Можно цитату? Я хоть убей "язык C включен полностью" там не вижу.

T>А ведь это очень важно. Представим, что malloc лезет в некий черный ящик. В стандарте явно указано: it is unspecified, лезет ли new в тот же черный ящик или берет память откуда угодно ещё. Это и только это вообще позволяет вам переопределить new.
В большинстве случаев разработчику абсолютно пофиг откуда память, и так же пофиг на перегрузку new, а уж перегрузка глобального вообще случай довольно редкий, ибо легко отстрелить ногу.

T>Прекрасно. Три отличия вы указали. Ещё одно -- new в отличии от malloc можно перегрузить -- я вам привел выше. Осталось найти ещё шесть =)
Только как эти "отличия" вытекают из п.2?

Здравствуйте, Abyx, Вы писали:

A> есть http://cdecl.org

Ну, наконец-то!

Здравствуйте, enji, Вы писали:

E>хм, а не знаешь, зачем так сделали?

Не знаю. Основное предположение: позволить компиляторам делать какие-нибудь оптимизации, например минимизацию потерь на alignment.