C>>>>>

C>>>>>int mode;
C>>>>>chmod("/some/file", mode); //Are you feeling lucky today?
C>>>>>

E>>>>1. Глобальная переменная в С и С++ инициализируется нулем. Балбес.
CC>>>А с чего ты взял что это глобальная переменная?
E>>А с чего бы ей не быть глобальной переменной ?
CC>Ты не можешь написать вызов функции рядом с определением глобальной переменной
А с чего ты взял что что вызов функции ?
Может это какое-то хитрое макроопределение, вида:

#define chmod(n, m) \
    static struct {
        .name = n,
        .mode = m
    } pad

Из приведенного кода — это не ясно.

IID>>>Ну, справедливости ради, GDB та еще какашка
E>>Нормальный отладчик, ты просто им пользоваться не умееш.
CC>Ты просто нормальных видимо не видел никогда.
Ну приведи пример нормальных с твой точки зрения. Если заикнешся про студийный отладчик — можеш сразу засчитать себе фейл — студийный отладчик очень херовый по функционалу.

ХГД>>>Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?
E>>С чего ты взял что constexpr обязательно выполнится на этапе компиляции, а не после ушлого компилятора на этапе инициализации программы ?
CC>Потому что стандарт.
И що ? Стандарт — стандартом, компиляторы его особо не придерживаются, особенно MS.

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

ХГД>>>>Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?
E>>>С чего ты взял что constexpr обязательно выполнится на этапе компиляции, а не после ушлого компилятора на этапе инициализации программы ?
CC>>Потому что стандарт.
E>И що ? Стандарт — стандартом, компиляторы его особо не придерживаются, особенно MS.

Ну конечно же! Операция + может на самом деле делить, ведь "Стандарт — стандартом, компиляторы его особо не придерживаются".

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

Хм, )) Какой-то странный испорченный телефон.

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

AWW>>То есть на СИ писать сложнее, но когда это необходимо то нужна более квалифицирванная рабсила.
CC>Память это не самая большая беда когда пишется большая и сложная система. Куда более серьёзная проблема в том, что на С нет никаких способов писать безопасный код.

Ну вот и чтобы все же что его писать (безопасный код) на СИ, требуется большая квалификация. ))

AWW>>То есть СИ более низкоуровневый язык, а чем ниже уровень, тем ближе к "железу", тем выше нужна квалификация.
CC>Чем сложнее инструмент тем выше нужна квалификация.

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

CC>Те же самые индусы, что у нас пишут на С пишут кое какие части на С++. Туда просто без слёз не взглянуть: нагромождения буста в таких причудливых комбинациях что просто диву даёшься как они такое вообще придумали и как оно вообще умудряется работать. Там где можно сделать просто они делают сложно.



AWW>>Если в языке много поводов сделать ошибок, это писать на нем без ошибок — нужна более высокая квалификация.
CC>Печаль в том, что по факту на С говнокодят в стиле: скомпилировалось — значит ошибок нет.

Так в том, то и дело )) Что бы не говнокодить на СИ надо иметь высокую квалификацю, а С++ тебе уже не даст той вольности, и наложит ограничения. ))

CC>>>классы с конструкторами, деструкторами, операторами и наследованием
E>>За исключением операторов всё реализуемо.
CC>Мне надо автоматический вызов конструкторов и деструкторов. Без макроёбства.
Зачем тебе конструкторы, если ничего полезного в них ты сделать не сможеш по причиние невозможности вернуть ошибку ?

CC>>>перегрузка функций
E>>По указателю. Получается даже гибче чем в С++.
CC>Overloading нужна по параметрам: http://www.cplusplus.com/doc/tutorial/functions2/
Ты можеш реализовать это с использованием gcc шного typeof и свитча внутри function-like макроса.

CC>>>templates (variadics included)
E>>Некоторая часть реализуема на основе макросов, в том числе variadic-макросов.
CC>Вы когда нибудь отлаживали макросы? В вложенные макросы? Я — отлаживал, больше не хочу.
Отлаживал и в огромных кол-вах. Надо просто уметь писать обобщенный код в макросах так, чтобы его было удобно отлаживать.
Для этого надо писать не "в лоб", а немного подумать. Думать можно начать с Степановского сишного прототипа STL.

CC>>>и я уже буду счастлив.
E>>Ты счаслив?
CC>Не то чтобы, ибо вынужден на данный момент писать под линух и на С.
CC>Держат только RSUs и прочие плюшки.

E>>Что осталось:
E>>1. Наследование, полиморфизм из ООП.
E>>2. Автоматический контроль за временем жизни переменных, RAII
E>>3. Темплейты и обобщеное програмирование.
CC>Этого уже достаточно чтобы жить стало легче, кода стало меньше, читабельность и стабильность улучшилась драматически.
См ниже:

E>>А теперь, можно задасться вопросом, насколько оставшийся функционал отличается от Сишного:
E>>1. Наследование, полиморфизм из ООП.
E>>- Элементы ООП прекрасно реализуются средствами Си.
CC>Вот только не надо мне рассказывать про макросы. Я их давным давно наелся.
Ты просто не умееш с ними работать.

E>>2. Автоматический контроль за временем жизни переменных, RAII
E>>- Поскольку исключений нет, то и вернуть ошибку из конструктора невозможно.
CC>Исключения есть, лично писал kernel код с их использованием.
Вот тут было интересно узнать подробности. Особбенно совмещение неопределенных точек возврата с сишным кодом ядра.

E>>3. Темплейты и обобщенное програмирование.
E>>Некоторая часть может быть реализована на основе макросов препроцессора, возможно эта часть даже перекрывает все потребности.
CC>Ещё раз: макросы это разговоры в пользу бедных. Templates в итоге не от хорошей жизни придумали.
CC>Поскольку макросы это просто подстановка без проверки типов то очень просто написать такой код, который скомпилируется без единого чиха и даже будет выполняться, но производить такие тонкие разрушения что придётся доооолго разгребать как же это получилось. Я это видел, дебажил и тыкал носом авторов много раз. Как только надо написать сколь либо сложное то сначала тратится море усилий чтобы написать макросы, потом море усилий чтобы их отладить. В итоге получается хрупкая конструкция, которая рушится как только надо что либо добавить или поменять.
Еще раз — ты просто не научился нормально работать с макросами.

E>>Собственно очень хорошо видно, что оставшаяся огрызок от С++ никаких особых ++ по сравнению Си не дает, зато добавляет кучу всякого системного гемороя по поддержке ++ языка.
CC>Весь "системный геморрой" заключается в написании С++ stdlib для кернела с поддержкой SEH/Signal исключений. Очень сложно, да!
То что ты сказал — на мой взгляд, сделать в линуксе невозможно. Но ты можеш поделить ссылкой на пример, если таковой конечно существует.
Даже для юзер спэйса, где нет кучи ограничений, написание поддержки С++ является проблемой. Через сколько там лет после первого релиза в андроиде появилася порт libstdc++ — можеш напомнить ?

E>>Вам такой С++ вообще нужен ?
CC>Мало того что нужен, мы его в винде давно уже используем.
Не потому ли виндой сейчас уже невозможно пользоваться ?

CC>Только линуксоиды упираются и цепляются за духовные скрепы С.
Винда потихоньку помрет и туда ей дорога.

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

CC>Т.е. на С++ ты ничего серьёзного не писал.

Пугают иногда вот такие вот заявления. )) Или вы знакомы лично?

ХГД>>>>>Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?
E>>>>С чего ты взял что constexpr обязательно выполнится на этапе компиляции, а не после ушлого компилятора на этапе инициализации программы ?
CC>>>Потому что стандарт.
E>>И що ? Стандарт — стандартом, компиляторы его особо не придерживаются, особенно MS.

CC>Ну конечно же! Операция + может на самом деле делить, ведь "Стандарт — стандартом, компиляторы его особо не придерживаются".
В С++ — вполне может.

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

CC>Исключения есть, лично писал kernel код с их использованием.

Так это другие исключения вообщето-то.

На полном и правильном С++ в ядре писать нельзя. Ибо 1 — не нужно. 2 — вредно, так как куча всего делается в тени.

Вообще у меня такое ощущение, что вы все тут про какой-то свой С++ говорите — С++ это всякие итераторы, исключения, потоки, да куча всего, что делает С++ удобным языком, без этого всего С++ это просто удобный СИ. И все его конечно с удовольствием используют. Но это не С++. ))

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

AWW>>!!! Так это делает "это" уже не С++.
CC>Т.е. чтобы писать на С++ надо обязательно использовать каждую фичу языка? Одну забыл и всё, программа уже не на С++?

Тогда о чем спор? ))
С++ без всего это просто удобный СИ. Ну и классы. Это не С++, если человек не занает всех жирностей С++, а использует только его подмножество, то это не знание С++, совсем!

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

A>Т.е. самая высокая квалификация у программистов микроконтроллеров, а самая низкая — у энтерпрайзеров? По-моему неверно. Квалификация — это разница между самыми лоу левел и самыми хай левел знаниями/навыками. Всреднем, ИМХО, чем больше лоу левел, тем меньше хай левел.

Да 100% не верно, так как просто абстрактной квалификации нет. Я же именно про квалификацию владения языком, про понимание того во что этот код выливается в машкомандах.

A>Это не квалификация, а, извините, просто степень задротства Чем больше ресурсов уходит на борьбу с языком, тем меньше остаётся на решение полезных задач. Тут главное помнить, что ценность обычно представляют решения полезных задач.

Вот это и есть разная специфика — для кого то задродство, а для кого-то это просто работа. В том числе и програмирование работы с контроллером памяти на СИ. Если не хватает СИ то приходится писать на асемблере. То есть ассемблер это как раз раздорство. Но увы это такая работа. ))

A>Может быть у нас просто терминология не совпадает. Квалификация — это произведение ширины опыта и знаний на глубину.
A>* Когда программист умеет программировать _вообще_, то знание всяких там указателей — это плюс
A>* Когда программист умеет работать с указателями и всё — это какой-то очень специфический программист

Согласен — вы правы с точки зрения приклодного программиста, видимо в это разница, то есть я то про системного (железячника).

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

E>>>Вам такой С++ вообще нужен ?
CC>>Мало того что нужен, мы его в винде давно уже используем.
E>Не потому ли виндой сейчас уже невозможно пользоваться ?

Да нельзя писать на С++ по правильному (по канону) в ядре виндов.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff557560(v=vs.85).aspx

CC>>Только линуксоиды упираются и цепляются за духовные скрепы С.
E>Винда потихоньку помрет и туда ей дорога.

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

AWW>Вообще у меня такое ощущение, что вы все тут про какой-то свой С++ говорите — С++ это всякие итераторы, исключения, потоки, да куча всего, что делает С++ удобным языком, без этого всего С++ это просто удобный СИ. И все его конечно с удовольствием используют. Но это не С++. ))
По своим прошлым диспутам с этими товарищами я сделал вывод, что это два каких-то бывших игродела (может и ошибаюсь). Учитывая разные упоминания, что в той индустрии вместо нормального С++ используется по большей части очень небольшое подмножество С++, практически Си с классами, можно сделать вывод что они действительно говорят о каком-то своём С++. С++ — это не только синтаксические механизмы, а еще вся стандартная библиотека с которой язык переплетен слишком тесно. Эта гипотеза могла бы обьяснить их такую любовь к windows, где все сделано для максимального неудобства нормального програмиста.

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

ХГД>>>>>>Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?
E>>>>>С чего ты взял что constexpr обязательно выполнится на этапе компиляции, а не после ушлого компилятора на этапе инициализации программы ?
CC>>>>Потому что стандарт.
E>>>И що ? Стандарт — стандартом, компиляторы его особо не придерживаются, особенно MS.
CC>>Ну конечно же! Операция + может на самом деле делить, ведь "Стандарт — стандартом, компиляторы его особо не придерживаются".
E>В С++ — вполне может.
Полностью в соответствии со стандартом между прочим.
Так что ты определись, придерживаются они стандарта или нет.

Здравствуйте, Andrew.W Worobow, Вы писали:

CC>>Т.е. на С++ ты ничего серьёзного не писал.
AWW>Пугают иногда вот такие вот заявления. )) Или вы знакомы лично?

Не знаком, но вдоволь наобщался с до боли похожими персонажами.

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

CC>>Мне надо автоматический вызов конструкторов и деструкторов. Без макроёбства.
E>Зачем тебе конструкторы, если ничего полезного в них ты сделать не сможеш по причиние невозможности вернуть ошибку ?
Это почему ещё?
Исключения работают, RTTI кстати тоже можно прикрутить, впрочем он очень редко нужен.

CC>>Overloading нужна по параметрам: http://www.cplusplus.com/doc/tutorial/functions2/
E>Ты можеш реализовать это с использованием gcc шного typeof и свитча внутри function-like макроса.
Спасибо, макросы кушайте сами.

CC>>Вы когда нибудь отлаживали макросы? В вложенные макросы? Я — отлаживал, больше не хочу.
E>Отлаживал и в огромных кол-вах. Надо просто уметь писать обобщенный код в макросах так, чтобы его было удобно отлаживать.
E>Для этого надо писать не "в лоб", а немного подумать.
Я в тот проект пришёл когда там линуксоиды со стажем все свои макросы уже написали. И занимались увлекательным делом — пытались с этим всем взлететь.

E>Думать можно начать с Степановского сишного прототипа STL.
Ссылка была бы просто замечательна.

CC>>Вот только не надо мне рассказывать про макросы. Я их давным давно наелся.
E>Ты просто не умееш с ними работать.

Можно я буду так отвечать всем, кто кричит что С++ плохой?

E>>>2. Автоматический контроль за временем жизни переменных, RAII
E>>>- Поскольку исключений нет, то и вернуть ошибку из конструктора невозможно.
CC>>Исключения есть, лично писал kernel код с их использованием.
E>Вот тут было интересно узнать подробности.
Речь естественно про винду, в которой озаботились чтобы люди могли просто ловить исключения в ядре. Причём ловятся все, включая access violation.

Throw, сгенеренный компилятором, вызывает _CxxThrowException, которая всегда бросает стандартный виндовый SEH. Ядрёная реализация это делает через RtlRaiseException.
Ловим __try / __except c EXCEPTION_EXECUTE_HANDLER. Бросаться стандартными классами исключений становится несколько сложнее. Можно прикрутить RTTI, можно сделать свои классы с блекджеком и всем что к нему прилагается.
Из-за этой разницы стандартные юзермодные библиотеки без обработки напильником в кернеле использовать не получается.

E>Особбенно совмещение неопределенных точек возврата с сишным кодом ядра.
Не понял про что ты?

E>Еще раз — ты просто не научился нормально работать с макросами.
Судя по тому, как линуксоиды со стажем мудохаются со своими же макросами — с ними никто не умеет работать.
Так что я не вижу смысла инвестировать свое время в напрасный труд.

E>>>Собственно очень хорошо видно, что оставшаяся огрызок от С++ никаких особых ++ по сравнению Си не дает, зато добавляет кучу всякого системного гемороя по поддержке ++ языка.
CC>>Весь "системный геморрой" заключается в написании С++ stdlib для кернела с поддержкой SEH/Signal исключений. Очень сложно, да!
E>То что ты сказал — на мой взгляд, сделать в линуксе невозможно. Но ты можеш поделить ссылкой на пример, если таковой конечно существует.
Почему в винде это возможно (по факту) а в линухе вдруг нет?

E>Даже для юзер спэйса, где нет кучи ограничений, написание поддержки С++ является проблемой. Через сколько там лет после первого релиза в андроиде появилася порт libstdc++ — можеш напомнить ?
Спроси у авторов андроида почему у них руки из задницы.

E>>>Вам такой С++ вообще нужен ?
CC>>Мало того что нужен, мы его в винде давно уже используем.
E>Не потому ли виндой сейчас уже невозможно пользоваться?
Кому?

CC>>Только линуксоиды упираются и цепляются за духовные скрепы С.
E>Винда потихоньку помрет и туда ей дорога.
Дада, она уже чёрти сколько лет вот вот помрёт. Осталось подождать ещё совсем немного.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Так это другие исключения вообщето-то.
Это всё SEH, через них в винде вообще все исключения сделаны. Различают С++ exceptions от остальных чисто по ExceptionCode.

AWW>На полном и правильном С++ в ядре писать нельзя. Ибо 1 — не нужно. 2 — вредно, так как куча всего делается в тени.
Ну, на том, что ты понимаешь под С++ в ядре действительно наверное лучше не писать. А вот фичи языка там очень пригождаются.

AWW>Вообще у меня такое ощущение, что вы все тут про какой-то свой С++ говорите — С++ это всякие итераторы, исключения, потоки
Итераторы и потоки это просто поставляемые в комплекте с компилятором библиотеки.
Мы же говорим про свойства самого языка. Такие как упомянутые тобой исключения (которые в ядре таки работают), которые требуют поддержки компилятором.

AWW>да куча всего, что делает С++ удобным языком
Т.е. те же классы с RAII, overriding, templates и другие чисто языковые фичи — как раз то, о чём мы и говорим.

AWW>Но это не С++. ))
Ну вот опять начинается.
Если я в С++ программе не использую ни одну стандартную библиотеку но использую все фичи самого языка — перестанет ли она быть С++ программой?

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>если человек не занает всех жирностей С++, а использует только его подмножество, то это не знание С++, совсем!

Извини, но это классическая чушь теоретика.

Знание всего подмножества никого не интересует. Всем почему то надо умение решать задачу, используя данный инструмент.
Если для решения задачи какие то возможности инструмента никогда в жизни не пригодятся — никого не волнует, знаешь ты их или нет.
Поэтому никого не волнует, знаешь ли ты какой нибудь хитрожопый SFINAE трюк чтобы сделать blah, если это blah мало где вообще можно применить.
Вон, Страуструп сам свои знания С++ оценил как 8/10. Расскажи ему что он не знает С++, вместе поржём.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Ну вот и чтобы все же что его писать (безопасный код) на СИ, требуется большая квалификация. ))
Это всё в теории. В реальной жизни получается чем сложнее инструмент тем выше нужна квалификация чтобы этим инструментом сделать то, что надо, не навредив самому себе.
С++ мощный язык, но и в то же время опасный в неопытных руках. Он может всё, что может С + ещё много чего сверху.

AWW>>>То есть СИ более низкоуровневый язык, а чем ниже уровень, тем ближе к "железу", тем выше нужна квалификация.
CC>>Чем сложнее инструмент тем выше нужна квалификация.
AWW>Ну а почему инструмент сложен? Самый простой это ассемблер — всего-то команды и адреса. Но писать на нем сложно.
Писать на нём не сложно, писать на нём громоздко. Повышается вероятность тупой ошибки в стиле "просмотрел" или "забыл".
С от ассемблера недалеко ушёл, впрочем он таким и задумывался.
В С++ добавились вещи, которые уже надо понимать как они устроены и работают, чтобы понимать их неявные эффекты.
В других языках уменьшили вероятность банальных ошибок, но появились возможности создания себе комплексных проблем при непонимании как работает его автоматика.

AWW> А "сложность" языка, это рамки которые тебе дают. Но не сложность освоения.
В С++ главное в изучении языка — опыт его использования и понимание как его автоматика работает "под капотом".

AWW>>>Если в языке много поводов сделать ошибок, это писать на нем без ошибок — нужна более высокая квалификация.
CC>>Печаль в том, что по факту на С говнокодят в стиле: скомпилировалось — значит ошибок нет.
AWW>Так в том, то и дело )) Что бы не говнокодить на СИ надо иметь высокую квалификацю
Скорее чистоплотность (посрал — смой выделил — освободи) и усидчивость (чтобы клепать boilerplates и не сойти с ума).
Примитивов в С кот наплакал, ничего реально сложного собрать из языковых конструкций нельзя.
В С++ нужен скилл понимания что именно нужно для решения задачи, иначе получается говнокод из мешанины языковых конструкций. Ярчайшим примером является секта укушенных Александреску, у которых вся программа — параметризуемый шаблон.

AWW>С++ тебе уже не даст той вольности, и наложит ограничения. ))
С++ позволяет делать всё то же что и С. Какие там ограничения?

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

E>В том случае, про который я рассказываю, компилятор сгенерировал инициализирующий конструктор для таблицы замен знаменитого госта (что такое таблица замен и гост я расказывать не буду — ты все равно не поймеш),

Вы про crypto_tfm?