Cудьба Mono

Можно, просто нужно понимать последствия.

С точки зрения стандарта если ты сделаешь lock(), создашь там объект, и вызовешь unlock(), то после следующего lock() объект будет невалиден если окажется по другому адресу. Если надо его как-то подвинуть в памяти, то нужно использовать placement new с конструктором копирования, про которые типовое сишное API ничего не знает.

Неплоскую память типо как в win16 или 32-битовые интерфейсы дающие доступ к памяти сверх 2Гб ты через operator new/delete не заюзаешь.

Такое и имеет.

CouchDB на Эрланге, Cassandra на Яве. Ниша Си++ всё сжимается.

кто-то говорил, что на других ЯП нет СУБД?

Нет. Кто-то говорит, что ниша Си++ уменьшается (за счет проникновения туда managed-языков).

странно делать вид, что новых СУБД на С и/или С++ почти нет

Кроме Mongo, какие?

webkit, например, взяв изначально KHTML, был полностью переписан с нуля

«С нуля» - это значит «выбросили KHTML и написали всё заново», а такого не было. Понятно, что от изначального KHTML осталось мало или вообще ничего, но код переписывался частями.

я конечно исходный код IE/Opera не видел

В About IE 3.0 было сказано «разработано на основе NCSA Mosaic».

Firefox с его XUL тоже не 20 лет

Да блин, причем тут XUL (а так же {Spider,Trace,Ion}Monkey и прочее). Есть кодовая база, она постепенно дорабатывается, модифицируется, чистится и т.д. Но она никогда не выбрасывается полностью, и за счет этого остается написанной на том, на чем была изначально (или, как в случае GCC, может медленно перейти в другой язык).

браузеры вроде Chrome/Safari etc. тоже написаны с чистого листа,

Они оба на webkit, правильно? Странное у тебя понятие о «с нуля».

Если надо его как-то подвинуть в памяти, то нужно использовать placement new с конструктором копирования, про которые типовое сишное API ничего не знает.

про которые типовое сишное API ничего не знает.

Ну началось... давно с тобой не разговаривал, забыл, сколь ты любишь соскакивать с темы.

давно с тобой не разговаривал, забыл, сколь ты любишь соскакивать с темы.

Нету никакого соскока. Разговор шел о возможностях которые дает перегрузка operator new. По стандарту operator new должен возвращать указатель, хендл вернуть он не имеет права. Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян. Следовательно, нужную логику на operator new реализовать невозможно, чтд. Уводом разговора с сторону было твое упоминание смарт-указателей. О смарт-указателях речь не шла, речь в ветке шла о перегрузке operator new. Я ясно выражаюсь?

Нет. Кто-то говорит, что ниша Си++ уменьшается

кто-то говорил «почти нет», ну ок

Кроме Mongo, какие?

из РСУБД отмечу drizzle, который уже лишь формально форк mysql, по факту - новая СУБД с новым кодом на С++, из встраиваемых - конечно sqlite, ну еще всякие redis, virtuoso, memcached, это если говорить про известные на С и С++, менее известных будет конечно побольше, но думаю их вспоминать нет смысла

В About IE 3.0 было сказано «разработано на основе NCSA Mosaic».

что не гарантирует, что в IE9 есть хоть строчка старого кода, и что он вообще на C++

Да блин, причем тут XUL (а так же {Spider,Trace,Ion}Monkey и прочее). Есть кодовая база, она постепенно дорабатывается, модифицируется, чистится и т.д

современные браузеры не монолитны, v8, xulrunner, *Monkey и пр. - вполне себе отдельные проекты, на базе которых написаны не только браузеры, и не только на С и С++

Они оба на webkit, правильно? Странное у тебя понятие о «с нуля».

если что webkit часть safari, а chrome чуть больше чем простая оболочка к нему, но да - «с нуля» некорректная формулировка в общем случае

осталось мало или вообще ничего, но код переписывался частями.

люди вон quake 2 на Java переписывали или sqlite, было бы желание - уйти на другой ЯП не так сложно, особенно, если надо лишь скопировать готовое, Apple и не такое проворачивала, вот только вариантов у них особо и не было, C/Obj-C/C++ - вот пожалуй и все

из РСУБД отмечу drizzle, который уже лишь формально форк mysql

что не гарантирует, что в IE9 есть хоть строчка старого кода

Похоже, ты и в самомо деле не понимаешь простых вещей. Ну и ладно.

redis, memcached

Это Си, не Си++.

virtuoso,

Если ты о http://en.wikipedia.org/wiki/Virtuoso_Universal_Server, то «The Virtuoso project was born in 1998 from a merger of the OpenLink data access middleware and Kubl RDBMS».

из встраиваемых - конечно sqlite

2000 год - не сказать, чтобы новая; Си, не Си++.

современные браузеры не монолитны, v8, xulrunner, *Monkey

v8 - это вообще из другого браузера, xulrunner содержит в себе копию Gecko, *Monkey вырос в кодовой базе Mozila и просто не мог быть на чем-то, кроме Си++ (по крайней мере, пока не взлетел Rust).

люди вон quake 2 на Java переписывали или sqlite, было бы желание

Никто и не говорил, что переписать невозможно.

уйти на другой ЯП не так сложно

Гг.

давно с тобой не разговаривал, забыл, сколь ты любишь соскакивать с темы.

Нету никакого соскока.

Еще бы ты признался.

Разговор шел о возможностях которые дает перегрузка operator new.

...после чего ты привел в пример сегментированную модель памяти Win16, которая ломает _абстрактную машину Си_, и по привычке полил Си++.

Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян.

А ты не теряй его.

О смарт-указателях речь не шла, речь в ветке шла о перегрузке operator new. Я ясно выражаюсь?

Распределять память в сегментах Win16 можно с помощью оператора new. Я ясно выражаюсь?

Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян.

А ты не теряй его.

Стандарт требует чтобы operator new возвращал void*. Какие-то обертки вокруг хендлов блока или сами хендлы оттуда возвращать нельзя.

Распределять память в сегментах Win16 можно с помощью оператора new.

Единственный прямой способ - явно выделить блок памяти нужного размера при помощи внешнего API, а потом разместить в ней объект при помощи placement new. Потом вызвать деструктор явно и удалить блок памяти при помощи внешнего API. Прямого способа скрыть эти телодвижения от клиента кода здесь не существует.

Похоже, ты и в самомо деле не понимаешь простых вещей. Ну и ладно.

просто ты придаешь некоторым вещам гипертрофированное значение, вот первый gcc был на паскале и что? а ведь «переезд» состоялся в рамках одного проекта, а не сознательного переписывания в новый продукт, как в drizzle

Это Си, не Си++.

спасибо, К.О., теперь перечитай предыдущие сообщения

2000 год - не сказать, чтобы новая

зато уже родились клоны на других ЯП - не взлетели

v8 - это вообще из другого браузера
xulrunner содержит в себе копию Gecko

К.О. сегодня в ударе

Гг.

относительно конечно, тебе такая задача неподсильна, а Apple вполне бы справилась, если б захотела, благо думать о совместимости и пр. тут не приходилось

вот первый gcc был на паскале и что?

http://gcc.gnu.org/wiki/History

Pastel (если ты о нем) вообще не был написан Столлманом и уж тем более не был «первым gcc»: «I concluded I would have to write a new compiler from scratch. That new compiler is now known as GCC"ю

Это Си, не Си++.

спасибо, К.О., теперь перечитай предыдущие сообщения

Я лучше перечитаю сообщение, на которое ответил изначально:

PlarFox> А С++… популярен примерно по той же причине, что и пхп в вебе.

wota> конечно, всякие компиляторы, кады, фотошопы, топовые игры, браузеры

И после этого ты приводишь мне продукты на Си.

тебе такая задача неподсильна, а Apple вполне бы справилась, если б захотела

Приведешь пример, где Яббл бы переписывал программы с одного языка на другой, да хоть какие-нибудь переписывания больших продуктов (нет, sqlite и quake2 не считаются большими)? Лично я слышал только о фейле Корела.

благо думать о совместимости и пр. тут не приходилось

Переезды Яббла m68k -> ppc и ppc -> x86 смотрят на тебя с непониманием.

Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян.

А ты не теряй его.

Стандарт требует чтобы operator new возвращал void*. Какие-то обертки вокруг хендлов блока или сами хендлы оттуда возвращать нельзя.

Сделай глобальную таблицу, отображающую хэндл в void *, возвращай void *, и в delete находи хэндл и удаляй его. Такая очевидная мысль тебе в голову не приходила?

Единственный прямой способ - явно выделить блок памяти нужного размера при помощи внешнего API, а потом разместить в ней объект при помощи placement new.

И это тоже работа с «неплоской памятью» через new,

Прямого способа скрыть эти телодвижения от клиента кода здесь не существует.

Я привел такой способ. Впрочем, когда сломана абстрактная машина, о прямых способах говорить уже не приходится.

Будь C++ нормальным языком, в нём не было бы возможности переопределить оператор присваивания. Потому что этот оператор должен действовать единственным образом — скопировать структуру данных справа налево. Если это объект, так пусть просто скопирует все поля этого объекта. Если среди них есть какие-нибудь указатели и хочется скопировать не указатели, а данные по ним, то пусть программист определяет у класса метод Copy(), который будет явно вызываться.

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

И будет две различных операции, каждая для своей цели. a = b ≠ a = b.Copy()

и захрена? лично мне достаточно operator=()

Сделай глобальную таблицу, отображающую хэндл в void *, возвращай void *, и в delete находи хэндл и удаляй его. Такая очевидная мысль тебе в голову не приходила?

Костыль среди океана плюсовых костылей. BTW, я видимо не такой говнокодер как ты, поэтому мне первой на ум пришла мысль как его отыскивать за атомарное время без привлечения глобальных структур. Надо выделить sizeof(HANDLE) + sizeof(T) и разместить этот хендл перед блоком. Вернуть указатель указывающий на первый байт после HANDLE.

Единственный прямой способ - явно выделить блок памяти нужного размера при помощи внешнего API, а потом разместить в ней объект при помощи placement new.

И это тоже работа с «неплоской памятью» через new,

Речь в ветке идет о практической пользе от возможности перегрузки operator new в пользовательском типе. А placement new это глобальный оператор.

Если справа атомарный тип, он копируется. Если справа объект, то копируется ссылка на него. Вот и всё.

a, b = b, a

что слева/справа?

Нет, это обычные (тэгированные?) указатели. gc может их обойти, т. к. в стеке ничего левого не лежит (а если и лежит, то среда об этом знает), так что никаких накладных расходов до запуска gc нет.

дык и в C++ тоже нет.

Может, да. Но как будет выглядеть создание такого объекта, особенно в многопоточной среде?

по разному. От простейшего ObjectType Object; до методов-фабрик. Зависит от выбранного дизайна кода.

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

ошибаешься.

Вообще-то это именно простое копирование, поверь старому Питон-прогеру. Но вопрос был не о копировании, а об операции сравнения:

drBatty> в ООП вообще нет и быть не может операции «равно»

я говорил про операцию копирования, которая в C/C++ называется «равно». Операция сравнения это «==». Её в ООП тоже нет, а есть метод operator==().

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

ошибаешься.

Ошибаюсь насчет чего - консервативного или не-консервативного?

drBatty> в ООП вообще нет и быть не может операции «равно»

я говорил про операцию копирования, которая в C/C++ называется «равно».

Операция копирования в Си++ называется «присвоить».

I concluded I would have to write a new compiler from scratch. That new compiler is now known as GCC

ты «случайно» не заметил такую фразу - «but I managed to adapt and use the C front end that I had written», т.е. имело место именно переписывание, пусть и далеко не всего кода, как и, внезапно, в том же drizzle, где не ставили цель сделать обычный форк вроде mariadb, например, а сели и написали новый код

Я лучше перечитаю сообщение, на которое ответил изначально:

ок, только не забывай читать и другие

И после этого ты приводишь мне продукты на Си.

предварительно написав про С, так бывает - разговор уходит в сторону, особенно если кто-то комментирует со стороны, рад что мы разобрались

Приведешь пример, где Яббл бы переписывал программы с одного языка на другой

ты не поверишь, но у Яббла есть своя ОС, в ней есть программы, и они как ни странно «переписывались с одного языка на другой», почитай про finder, например, это такой file manager, легко нагуглишь

Переезды Яббла m68k -> ppc и ppc -> x86 смотрят на тебя с непониманием.

они смотрят на тебя, переписывание KHTML к ним отношения не имеет

А это и правда так %) На тот момент просто не было ничего лучше и скромнее по ресурсам.

как и сейчас...

Почти все «компиляторы, кады, фотошопы и браузеры» начали писаться 20 лет назад (или больше). А топовые игры - ниша относительно небольшая, да и там уже не чистый Си++.

C++ никогда и не был «чистым». Он всегда был расширяем, причём и вверх и вниз.

а сели и написали новый код

под этим подразумевается и переписывание с С на С++, если вдруг опять будет недопонимание

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

но для решения той же задачи тебе понадобится на два порядка больше ресурсов. Игрушкой на 640х480 пикселей ты никого уже не удивишь. Разве что на Nokia3110.

распиаренное говнище.

ты «случайно» не заметил такую фразу - «but I managed to adapt and use the C front end that I had written»

И тем не менее, никакой «первой версии GCC на Pascal» не существовало.

И после этого ты приводишь мне продукты на Си.

предварительно написав про С

Из продуктов на Си++, написанных после 2000 года, имеем Монго. И игры, да.

ты не поверишь, но у Яббла есть своя ОС, в ней есть программы, и они как ни странно «переписывались с одного языка на другой», почитай про finder, например

Finder - это, конечно, мощно. Уровня серьезного CAD, не меньше. А под «переписывались» имеется в виду «Finder was rewritten using the Cocoa API» или переписывание на Си++ 1991 года?

думать о совместимости и пр. тут не приходилось

Переезды Яббла m68k -> ppc и ppc -> x86 смотрят на тебя с непониманием.

они смотрят на тебя, переписывание KHTML к ним отношения не имеет

А, то есть переписанный KHTML мог быть несовместимым. Okay.

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

но

Что «но»? Было сказано, что насчет ресурсов ничего не поменялось.

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

Какой «той же»? Ядро стало использовать в 100 раз больше памяти? Компиляторы? X? xterm и mc? Emacs?

А вот fullhd видео «раньше» просто не было.

А топовые игры - ниша относительно небольшая, да и там уже не чистый Си++.

C++ никогда и не был «чистым».

Мне было бы интересно услышать твое определение «чистого» Си++. Сам я говорил о том, что в движках используется несколько языков.

И тем не менее, никакой «первой версии GCC на Pascal» не существовало.

ок, но как видишь «форки» вполне допускают смену ЯП

Из продуктов на Си++, написанных после 2000 года, имеем Монго. И игры, да.
Finder - это, конечно, мощно. Уровня серьезного CAD, не меньше.
А, то есть переписанный KHTML мог быть несовместимым. Okay.

твои аргументы слишком серьезны и достоверны, как и логические цепочки, не вижу смысла с ними спорить

никакой «первой версии GCC на Pascal» не существовало.

ок, но как видишь «форки» вполне допускают смену ЯП

GCC является форком Pastel? Okay.

твои аргументы слишком серьезны и достоверны

Это очищенная версия твоих аргументов.

man кавычки, ну и не pastel напрямую, а промежуточного форка pastel, кода от pastel в результате в gcc нет, но для тебя это же не аргумент - тебе важней «кодовая база» и ее развитие

Это очищенная версия твоих аргументов.

а мои - твоих, итого ты получил свои «дистиллированные» аргументы

тебе важней «кодовая база» и ее развитие

Ее инерция.

Нету никакого соскока. Разговор шел о возможностях которые дает перегрузка operator new. По стандарту operator new должен возвращать указатель, хендл вернуть он не имеет права. Если же он получит хендл, залочит кусок памяти по хендлу и вернет указатель, то хендл будет потерян. Следовательно, нужную логику на operator new реализовать невозможно, чтд. Уводом разговора с сторону было твое упоминание смарт-указателей. О смарт-указателях речь не шла, речь в ветке шла о перегрузке operator new. Я ясно выражаюсь?

не ври. Изначально речь шла о смарт-указателях И презагрузке new.

одно без другого не имеет смысла в C++.

Ошибаюсь насчет чего - консервативного или не-консервативного?

у тебя взаимоисключающие параграфы в одном предложении:

Для консервативного сборщика, единственно возможного в Си/Си++, ничего подобного не нужно. Для не-консервативного... думаю, тоже не обязательно.

как можно такой бред оспаривать?

Операция копирования в Си++ называется «присвоить».

операция копирования в C++ называется копированием. Есть также operator=() и конструктор копирования. Но это не совсем то.

Какой «той же»? Ядро стало использовать в 100 раз больше памяти? Компиляторы? X? xterm и mc? Emacs?

для задачи вывода на экран изображения. Хотя бы. Экран стал несколько больше, чем 640х480. xterm, mc, и даже emacs никогда не тормозили, да и сейчас не тормозят. Да только никому они не нужны.

Такие дела.

А вот fullhd видео «раньше» просто не было.

ага. было не full и не hd.

C++ никогда и не был «чистым».

Мне было бы интересно услышать твое определение «чистого» Си++. Сам я говорил о том, что в движках используется несколько языков.

учись читать - как я могу дать определение того, чего (по моим же словам) никогда не было? Свои фантазии объясняй сам, пожалуйста.

Ошибаюсь насчет чего - консервативного или не-консервативного?

у тебя взаимоисключающие параграфы в одном предложении:

От человека, который не понял фразу «stop'n'copy gc», это звучит особенно веско.

xterm, mc, и даже emacs никогда не тормозили, да и сейчас не тормозят.

Ну слава ТНБ, хоть какие-то задачи не требуют в 100 раз больше.

Да только никому они не нужны.

Говори за себя.

как я могу дать определение того, чего (по моим же словам) никогда не было?

То есть определение дать не можешь, но знаешь, что не было. Бывает.

От человека, который не понял фразу «stop'n'copy gc», это звучит особенно веско.

откуда мне знать, как очередная школота называет алгоритм Бейкера? Он, кстати, не относится напрямую к сборке мусора.

Говори за себя.

за себя и говорю - юзаю VIM... Такие дела...

То есть определение дать не можешь, но знаешь, что не было. Бывает.

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

что слева/справа?

Тьюплы. Но это не отменяет того факта, что a просто присвоится значение b и b просто присвоится значение а.

Тьюплы. Но это не отменяет того факта, что a просто присвоится значение b и b просто присвоится значение а.

ну тогда расскажи, во что это «просто» скомпиллируется.

одно без другого не имеет смысла в C++.

Обычно в качестве достоинства выставляют ортогональность. А у плюсофагов вон оно как.

одно без другого не имеет смысла в C++.

Обычно в качестве достоинства выставляют ортогональность. А у плюсофагов вон оно как.

как «так»? В других ЯП дополнительная функциональность гвоздями прибита к операции «равно» (копирование), а в C++ этого нет. И это хорошо, ибо нет оверхеда в большинстве случаев, когда никакие сборщики мусора не нужны. А когда нужны - можно это реализовать.

Обычно в качестве достоинства выставляют ортогональность. А у плюсофагов вон оно как.

В других ЯП дополнительная функциональность гвоздями прибита к операции «равно» (копирование), а в C++ этого нет.

А что там в operator= можно такого сделать? Сконструировать временный объект, а потом обменять pimpl-ы? Дык в других языках объекты и являются своими pimpl-ами.

А что там в operator= можно такого сделать? Сконструировать временный объект

зачем? Например мне тут доказывали, что gc в рамках C++ невозможен, доказательство сводилось к коду, в котором как раз и вызывалась функция копирования «равно». При этом, для доказывающего было очевидным, что = просто тупо копирует, а значит сборщик мусора не знает, что у объекта появилась копия. И таким образом, gc не сможет этот мусор собрать. Но на самом деле вызывался конструктор копирования, который и имеет возможность сообщить сборщику о факте появления новой копии. В самом примитивном варианте можно увеличить счётчик ссылок на 1, и вообще ничего не копировать, а просто использовать старый объект.

В самом примитивном варианте можно увеличить счётчик ссылок на 1, и вообще ничего не копировать, а просто использовать старый объект.

Инфраструктурного кода который не относится к решаемой программистом проблеме существовать не должно.

Инфраструктурного кода который не относится к решаемой программистом проблеме существовать не должно.

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

А код он всё равно _будет_, и мне проще иметь возможность его менять.

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

Когда дело дойдет до того что заказчик пожалуется на то что твой сервер падает в среднем раз в два часа, заинтересоваться таки придется.

А код он всё равно _будет_, и мне проще иметь возможность его менять.

Ты просто лентяй и тебе влом разбираться в больших сложных фреймворках.

Когда дело дойдет до того что заказчик пожалуется на то что твой сервер падает в среднем раз в два часа, заинтересоваться таки придется.

с чего он будет падать-то? пойми, в C++ технологию сборки мусора можно применять _локально_, в пределах одного какого-то класса, которому это _действительно_ нужно. В большинстве случаев необходимости в gc нет никакой. Вот в C++ её и не применяют (в 95% классов). Потому, если уж обнаружился какой-то глюк gc, то его можно с лёгкостью локализовать и исправить. В отличие от...

Ты просто лентяй и тебе влом разбираться в больших сложных фреймворках.

...и это тоже.

с чего он будет падать-то? пойми, в C++ технологию сборки мусора можно применять _локально_, в пределах одного какого-то класса, которому это _действительно_ нужно.

Данный подход поощряет написание чисто синхронного кода, где ресурсы всегда чистит вызывающий после того как вызываемый отработал.

Ты просто лентяй и тебе влом разбираться в больших сложных фреймворках.

...и это тоже.

Ну я конечно понимаю что легче заниматься решением уже решенных проблем чем нерешенных.