Андрей Александреску, The Case for D

Ужос. Т.е. константа в с++ изменяемая? Так а чем он тогда отличается от банальной переменной?

А понял. Смысл в const вложен совершенно инопланетный относительно других языков. Подозреваю - близко к readonly в С#

>> По моему только Александреску в конце концов приблизился к тому чтобы соорудить из изначально бесполезных шаблонов что-то стоящее наподобие языка спецификации проектирования

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

Акробатики в его подходе меньше всего - он намечает цель где-то на горизонте и идет к ней строго по прямой, причем не нарушая правил (стандарт ANSI/ISO). Причем цели он выбирает достойные. А то что результат получается таким монструозным и по факту хрупким несмотря на строгое соответствие стандарту это уже личная заслуга Строуструпа.

Так что тут неверна изначальная задумка.

Какая задумка - параметризованные типы?

Ну да - вся затея не работает. Надо было не выпячиваться и делать нормальные макросы как в лиспе.

> разница между static const и const static

O_o

Я не докурил мануалы по С++?

Я не докурил мануалы по С++?

докури)

Ужос. Т.е. константа в с++ изменяемая?

в C++ есть кроме переменной еще и указатель
так вот const может по разному влиять на переменную и переменую типа указатель

1 переменная может меняться но нельзя изменить указатель
2 указатель может меняться но нельзя изменить переменную

:))

> Ужос. Т.е. константа в с++ изменяемая? Так а чем он тогда отличается от банальной переменной?

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

На самом деле конечно менять можно, если нет аппаратной защиты в процессоре или не включена в операционной системе защита. Т.е. выдираем адрес константы в указатель, разыменовываем и меняем. Но это хак.

> Александреску - акробат, который должен отправиться в адЪ вслед за Степановым.

Акробат — согласен. К его книгам в обязательном порядке должна прилагаться надпись типа «трюки в фильме выполняли каскадеры, не пытайтесь их повторить на личном автомобиле». Но в адЪ это уж слишком.

То, что этот акробат приложил руку и к D - серьезный минус в моих глазах.

х.з. скорее наоборот, там эти трюки становятся уже не трюками

>>> Так что тут неверна изначальная задумка.

Какая задумка - параметризованные типы?

Ну да - вся затея не работает.

«Я знал, что ты это скажешь» (с) Спорить не буду, ибо бесполезно.

спасибо :)

> На самом деле конечно менять можно, если нет аппаратной защиты в процессоре или не включена в операционной системе защита. Т.е. выдираем адрес константы в указатель, разыменовываем и меняем. Но это хак.

Скорее, дыра... Если честно.

> Он есть в STL de-facto. А de-facto мне как то более важно.

de-facto как я понимаю - это вендор такой? ;)

> х.з. скорее наоборот, там эти трюки становятся уже не трюками

Но станут ли они от этого «нормальным стилем» вождения. Это уже вопрос. :)

докури)

Я не про указатели, а про пример, что был выше. Проясни в чем разница между эти объявлениями не указателей.

static const int x1 = 1;
const static int x2 = 2;
static int const x3 = 3;
const int static x4 = 4;
int static const x5 = 5;
int const static x6 = 6;

С++ скорее всего умрёт, его заместят языки из новой волны. на

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

нужды языка (да, это указатели, память, синтаксиса). На сегодняшний

день на C++ приходится писать слишком много кода и помнить слишком

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

плохо что многие кто не освоил C++ хаят его
есть очень много людей которые его знают и даже хорошо знают
но очень мало тех кто дествительно пишет на нём хороший код

вот те кто не освоил С++ уже присматриваються на D

> Скорее, дыра... Если честно.

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

В java для такого вида хаков можно использовать reflection. Не далее чем пару недель назад пришлось protected поле менять не в наследнике через reflection. Хотя язык этого вроде как не разрешает, но можно.

«плохо что многие кто не освоил C++ хаят его есть очень много людей которые его знают и даже хорошо знают но очень мало тех кто дествительно пишет на нём хороший код»

С другой стороны, поговорка «На С++ хорошую программу написать можно, но это слишком долго» тоже не на пустом месте родилась.

«даже хорошо знают» Ну вот сейчас разбираю библиотечку с CodeProject - html parser. Вроде бы и какой-то браузер чел сваял, но как: написал свой top-down малопонятный рекурсивный парсер, свою реализацию strtok... - что тоже показательно. Высокая степень велосипедостроительства :)

«очень мало тех кто дествительно пишет на нём хороший код» Ну эта фраза 100% применима и к паскальщикам, и к пистонщикам, и к руби, и ко всему-всему-всему :)

> С++ скорее всего умрёт, его заместят языки из новой волны. на ктороых можно легко и непринуждённо писать код, не заморачиваясь на нужды языка (да, это указатели, память, синтаксиса). На сегодняшний день на C++ приходится писать слишком много кода и помнить слишком много деталей, что бы получить результат. Пока у конкурентов много недостатков, но скоро это поправят. C останется - на его лавры пока никто не претендует.

_Никогда_ он не умрёт, слишком много кода на нём написано, до полной реализации квантового компьютера. Невозможно написать эффективную программу ни на каком языке не принимая во внимание этих деталей. Даже с gc необходимо знать что такое память как они выделяется и что она освобождается, иначе у тебя будет shit а не программа. Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность.

Тут Линус видимо прав, я офигел, когда реально померил скорость

плюсовых исключений. А ведь раньше не верил

все зависит от реализации
да ексепшены плохи в std::
но это минус std (abi) что они так реализованы

Линус не прав был когда отверг имплементацию ексепшинов в ядро
тем самым отказав в полном использовании С++ в ядре

многие программисты согласны в том что нет смысла тягать указатель на структуру по всем функциям
поскольку в каждом обьекте C++ этот указатель уже передаеться через ecx регистр
нет это конечно же не значит что нужно переписать все линукс ядро на С++
но полнофункциональное использования С++ в линукс ядре было бы суппер

а скорость раскрутки ексепшенов уже будет зависеть от реализации этого в ядре

в винде же работает
и достаточно быстро

C++ выглядит уродливо когда с ним идёт в комплекте STL и Boost
ежели их выбросить
и абстрагироваться к C++ как к стандарту - он очень хорош

> Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность.

Иными словами, Лисп. ;)

> Не дыра в том смысле, что если в языке есть ассемблерные ставки, то такие хаки можно всегда сделать.

Да. В этом смысле Вы правы. Но я о другом, на самом деле. Стоит ли так делать?

> в винде же работает и достаточно быстро

Видел давненько исходники ядра оффтопика. С++ там мало. Впрочем, _все_ исходники мне не были интересны. Рассматривались только отдельные части.

в общем-то, это недостаток Д, который его полностью инвалидирует как

замену с++

т.е. да, в Д исправлена куча косяков с++, добавлено кое-что

полезное, и сам по себе он лучше с++

язык D мне напоминает программера который хочет программить на C#/java используя C++

но полезность D для меня пока что туманна
пусть еще десяток лет поживет а там посмотрим

> Линус не прав был когда отверг имплементацию ексепшинов в ядро тем самым отказав в полном использовании С++ в ядре

Возможно. Вот только мы про ядро малость выше пообщались. Как Вы представляете себе реализацию отдельной части С++ (механизма исключений) в отрыве от других частей С++? Или нужно было сгондобить довесок к ядру? Но тогда это уже не моноядро получится. А микроядро. Со всеми вытекающими.

Linus, по всей видимости, просто уменьшил себе число проблем. Не более.

Видел давненько исходники ядра оффтопика. С++ там мало. Впрочем,

_все_ исходники мне не были интересны. Рассматривались только

отдельные части

на С++ в _оффтопике_ реализована win32k.sys - тоесть GUI
так же на C++ там весь DirectX

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

а на чистом С в _оффтопике_ реализовано остальное потому что удобней и понятней експортировать биндинг _strcmp например
чем ??_L@YGXPAXIHP6EX0@Z1@Z

да и експорируемая функция в _оффтопике_ дефакто уже стандарт
тоесть если она експортируеться она документирована и готова к использованию ее так легче запоминать в формате языка С
а вот тот же DirectX еспортирует vtbl от С++ классов называя их Interface

Возможно. Вот только мы про ядро малость выше пообщались. Как Вы >представляете себе реализацию отдельной части С++ (механизма >исключений) в отрыве от других частей С++? Или нужно было сгондобить

TRY/CATCH/THROW
живут и без С++
сами по себе
если они реализованы

довесок к ядру? Но тогда это уже не моноядро получится. А микроядро. >Со всеми вытекающими.

нет не получться не моно ядро
все будет зависить от реализаци исключений

Linus, по всей видимости, просто уменьшил себе число проблем. Не более

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

Но я о другом, на самом деле. Стоит ли так делать?

Что именно? Как механизм языка - не сильно мешает. Нужно ли так писать - нет, не нужно. Много проблем - запутанность кода, конфликт с аппаратной защитой, конфликт с оптимизацией.

Вот, например, как думаете, что выведет следующий код?

#include <cstdio>
int main(){
	const int x = 1;
	*(int*)(&x) = 3;
	printf("%d\n", x);
	printf("%d\n", *(&x));
	printf("%d\n", *(int*)(&x));
	return 0;
}

> Александреску - акробат, который должен отправиться в адЪ вслед за Степановым. То, что этот акробат приложил руку и к D - серьезный минус в моих глазах.

В чём собственно проблема? В С++ простые «метавещи» выражаются сложным образом. Если тебе не нужна эта акробатика - использовать её никто не заставляет. То, что в С++ эти самые метавещи вообще как то выражаются - плюс, и достаточно большой. И то, что Александреску кого то научил пользоваться этой частью С++ - хорошо. Если кто то не понимает когда эта дополнительная сложность оправдана, а когда нет, это не проблема инструмента (точнее, может быть проблема, но лишь частично). STL-ем пользоваться никто не заставляет. Сам по себе он простой (я никогда не понимал идиотских имён переменных и членов класса в его реализации, из за которых код кажется обфусцированным донельзя, но это проблема реализации). Несложно написать ему замену, или использовать 1 из 10000 готовых.

падает с ошибкой.

> падает с ошибкой.

Компиляции или выполнения?

const int x будет помещён в readonly память и попытка изменить эту ячейку бросит аппаратное исключение. Я не проверял, но уверен что так и будет. Ошибка выполнения, конечно.

Будет под линуксом. Что под вендой будет хз, там такие вещи вроде немножко по-другому компилируются. По стандарту неопределённое поведение.

Лично мне в STL нравится одна вещь, которую почему-то я больше нигде не вижу: указание сложности тех или иных алгоритмов. Ну и чем там имена обфусцированные - не знаю, вроде все довольно просто. Хотя диапазоны в D и совершенно убойное выражение sort(chain(a, b, c)) меня поразили напрочь - точно погляжу поближе, а там и перейду, может быть... Благо я сам выбираю, на чем писать проекты

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

http://ru.wikipedia.org/wiki/Не_читал,_но_осуждаю!

У меня отработало на fedora core 6 (компилил как g++ так и gcc). И на vista x64 (visual studio 2008). Исключений не было ни в одном из трёх вариантов, а вывод программ разный.

Ясно, извиняюсь.

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

http://www.youtube.com/watch?v=XHosLhPEN3k

:))

> В чём собственно проблема? В С++ простые «метавещи» выражаются сложным образом. Если тебе не нужна эта акробатика - использовать её никто не заставляет.

Проблема в том, что кому-то эта акробатика понравится, и тут 2 выхода - либо связать ему руки, либо тоже пользоваться ей,

Несложно написать ему замену

Ты запредельно крут.

или использовать 1 из 10000 готовых.

Можно, конечно.

Отработало нормально. Выдало

1 1 3

g++ 4.4.2 на арче.

>Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность.

Я бы и рад с тобой согласиться (не касательно С++, а простоты и эффективности), но пока всё говорит, что "Рано или поздно рюшечки становятся не интересны, и тогда побеждает простота и эффективность _написания программ_!" И конца этому не видно. Да я, если честно, и не уверен, что этот путь не есть правильный

Отлично, меняем cstdio на stdio.h Правим расширение файла и компилим gcc. У меня на g++ и gcc получился разный результат ;-)

Отлично, меняем cstdio на stdio.h Правим расширение файла и компилим gcc. У меня на g++ и gcc получился разный результат ;-)

Мда, занятно...

> "... и тогда побеждает простота и эффективность _написания программ_!"

Да ну, сделай wc -l программ в любом дистрибутиве и потом расскажи что побеждает.

> Вот, например, как думаете, что выведет следующий код?

Ну undefined behavior ведь, какая разница что получилось если так ( *(int*)(&x) и (*(int*)(&x))) писать нельзя?

Кто сказал что компилятор обязан положить константы в .data?

> Ну undefined behavior ведь

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

> С99 - комплексной математики быстрее не бывает.

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

>STL. Искренне надеюсь, что за это Степанов оправится в адЪ.

Гораздо раньше там окажутся авторы жабы, php и питона и адЪ засвопится на неопределённо долгий срок.

>Да ну, сделай wc -l программ в любом дистрибутиве и потом расскажи что побеждает.

Самому не стыдно за такую "аргументацию"? Оффтопик побеждает "стопудова" (при несколько другом запросе).

Хоть бы на вакансии какие глянул...

> вот те кто не освоил С++ уже присматриваються на D

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

>Скорее, дыра... Если честно.

Вирт, залогиньтесь