Nimrod

Как минимум в том, что непонятно, откуда прилетело исключение (стека-то уже нет).

Стек никуда не делся и место повторного исключения известно. Проблема совсем в другом - уничтожение объекта это логически атомарная и необратимая операция. Её нельзя выполнить частично, как, например, конструирование объекта.

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

Каким местом Го наследник С?

Не то, чтобы наследник, но:

Starting point: C, fix some obvious flaws, remove crud, add a few missing features.

просто перечитай предисловие KR

+ http://www.lysator.liu.se/c/pikestyle.html

поймёш надеюсь

что насчет структур с методами?

методы нужны не виртуальные

Зачем нужны методы, если их нельзя сделать виртуальными, мне совершенно не понятно.

Object-Oriented Programming With ANSI-C.

Haskell.

внезапно — freepascal

++ http://www.lysator.liu.se/c/plan9c.html

вот это как раз показывает точнее эволюцию С в го , у Кена Томпсона тоже есть пара текстов о 9с(сишка плановская)

fuf

http://doc.cat-v.org/plan_9/4th_edition/papers/compiler

Ок, ты меня убедил.

Я привык, что наследниками С называют языки, позаимствовавшие сишный синтаксис в той или иной степени. Хотя в действительности, правильнее считать таковыми ЯП, развивающие его идеи.

т.е. ты не осилил кресты и хочешь то же самое но попроще?

Тогда у меня для тебя плохие новости: если хочешь чтобы работало быстро, придется понимать что делаешь.

Пробовал Cello?

+1 - под все требования ТС, вроде, подходит.

d

неготов для продакшена

Паскаль же!

Какие? Из того что ты сказал в нулевом в крестах все есть (кроме последнего пункта).

Objective-C

а в чём проблема использовать Си++ без исключений, без темплейтов, без всего того, что не надо?

Это называется Си.

- компилируемый в быстрый нативный код

- без обязательного сборщика мусора

- умеет сишные либы (возможно, с небольшими допиливаниями)

- структуры с методами

- не С++

ЯННП, при чём тут последний пункт? «Есть ли белый холодильник чёрного цвета?»

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

интересно: какие?

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

Либо сам не знаешь чего хочешь, либо херню несёшь.

++

А как же перегрузка, ссылки, конструкторы/деструкторы/методы, move-семантика, braced-инициализаторы, foreach наконец? Там много же сахарка.

В ОП такого требования не было

перегрузка

Как правило не требуется или запутывает.

ссылки

Лишняя сущность когда есть указатели.

конструкторы/деструкторы/методы

Это нужно.

move-семантика, braced-инициализаторы

Непонятная хрень, что это?

foreach наконец?

Нужно, но не поздновато осилили?

D

Как там отключить сборку и как с этим жить?

Если убрать маргинальщину и не готовые языки, то придётся убрать последний пункт требований(кстати, единственный религиозный пункт у тебя). Т.е. все-таки C++.

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

Или таки немного рискнуть(что за проект делаешь?) и взять D. Но там без сборки жизнь не так проста...

что за проект делаешь?

космосим.

и не делаю, так, на перспективу думаю. другими словами, чисто гипотетические измышления :)

В Cello копипасту заменили на левую либу с тоннами макросов. Выглядит цивильно, но ничего действительно большого(из того, что требует ООП во всей его красе и со всем адом промышленного программирования) я на нём не писал. Так что за что купил, за то и продаю.

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

к сожалению, иначе ошибку из конструктора/деструктора не вернуть никак. можно попробовать вместо них сделать init/done, конечно... надо подумать, спасибо

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

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

Этот подход работает очен плохо. Проверено на практике.

Нихрена себе! А стандарт говорит, что при этом мы полцчаем undefined behavivor.

тогда ладно

передачей исключений из конструкторов, или из деструкторов

Из конструкторов кидать можно. Из деструкторов - не рекомендуется.

Но если _это_ является определяющим при выборе языка, то извините.

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

Этот подход работает очен плохо. Проверено на практике.

Хотелось бы подробностей, чем именно плохо? Создаешь объект, смотришь на результат операции и потом принимаешь решение. Альтернатива с отдельным инитом является примерно тем же самым: создаешь объект, вызываешь инит и одновременно смотришь результат. Количество действий такое же, только инициализация происходит не во время работы конструктора, а во время работы init.

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

смотришь на результат операции

This. Практика показывает, что 99% программистов не „смотрят“, что в дальнейшем приводит к очень понятному и предсказуемому поведению ПО.

Врешь. В плюсах нет никакой сборки мусора. Вообще. Есть те или иные библиотеки. У rust есть сборщик, который просто пока реализован не очень круто. Так как его отключить? Как мне выделить память так, чтоб никто не пытался её вернуть?

Врешь.

Зачем так грубо-то? :)

В плюсах нет никакой сборки мусора. Вообще. Есть те или иные библиотеки. У rust есть сборщик, который просто пока реализован не очень круто. Так как его отключить?

Ну так и в Ржавчине сборка мусора в сам язык тоже не вшита. Есть тип Gc<...>, но это не так сильно отличается от того, что есть в плюсах.

Как мне выделить память так, чтоб никто не пытался её вернуть?

«let n = box 1;» - почти то же самое что и плюсовое: «unique_ptr<int> uptr(new int(1));». Т.е. сборщика мусора тут нет, есть просто RAII.

Как мне выделить память так, чтоб никто не пытался её вернуть?

Ну или просто выделить на стеке: «let n = 1;»

Официальная документация с тобой не согласна. И да, а какой аналог weak_ptr? В полюсах это всего лишь библиотека, вообще никак не связанная с самим языком. Кстати, ты не ответил на вопрос о том, как мне не освобождать память.

Официальная документация с тобой не согласна.

Хм. Я почитал-погуглил и теперь хз насчет состояния дел со сборщиком мусора. Я-то думал, что его выпилили к черту и забыли :) . Никогда его не использовал - мне хватает box`ов, ссылок и, если нет единого владельца ресурса, Rc.

Насколько я понимаю, использование std::gc не рекомендуется, да и сделан он сейчас через тот же подсчет ссылок:

/// Immutable garbage-collected pointer type
#[lang="gc"]
#[cfg(not(test))]
#[experimental = "Gc is currently based on reference-counting and will not collect cycles until \
                  task annihilation. For now, cycles need to be broken manually by using `Rc<T>` \
                  with a non-owning `Weak<T>` pointer. A tracing garbage collector is planned."]

Вроде как, есть планы сделать включаемую для отдельных задач-потоков сборку мусора в нескольких реализациях, но я теперь в этом вопросе не уверен. Может tailgunner точнее знает, он как-то где-то писал чего-то про сборку в Ржавчине.

И да, а какой аналог weak_ptr? В полюсах это всего лишь библиотека, вообще никак не связанная с самим языком.

«Box» - аналог unique_ptr, тут weak_ptr ни при чем.

А вот стандартная библиотека подсчета ссылок:

• http://static.rust-lang.org/doc/master/std/rc/index.html
• http://static.rust-lang.org/doc/master/std/rc/struct.Rc.html
• http://static.rust-lang.org/doc/master/std/rc/struct.Weak.html

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

Я не уверен, что понимаю тебя, можешь показать код на Си или С++?

Зачем тебе это вообще? Ну можно гадость какую-нибудь наколдовать в unsafe{} блоке. Без unsafe, вроде, никак.

Сейчас грепнул все библиотеки, которые использую в своем проектике, на наличие Gc\gc - вроде никто не грешит. Только пару раз простой Rc встречается. Но за весь написанный на Ржавчине код (хоть его и не так много) отвечать не могу.

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

План по выносу GC в библиотеку никто не отменял, AFAIK; managed-указатели уже давно за feature gate, если их не использовать, сборщик мусора не активируется.

Объясни последний пункт. Что не так с C++?