Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Шаблоны не являются ОО-инструментом ну вообще никак. Их можно отнести к МП.
I>Ну да, полиморфизм к ООП никакого отношения не имеет
ООП обычно использует довольно слабый вид полиморфизма: ad-hoc полиморфизм по неявному аргументу.
Шаблоны и генерики не относятся к ООП вообще никак.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Ikemefula, Вы писали:
I>>Здравствуйте, gandjustas, Вы писали:
G>>>Шаблоны не являются ОО-инструментом ну вообще никак. Их можно отнести к МП.
I>>Ну да, полиморфизм к ООП никакого отношения не имеет
G>ООП обычно использует довольно слабый вид полиморфизма: ad-hoc полиморфизм по неявному аргументу.
G>Шаблоны и генерики не относятся к ООП вообще никак.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Ikemefula, Вы писали:
I>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Шаблоны не являются ОО-инструментом ну вообще никак. Их можно отнести к МП.
I>>>Ну да, полиморфизм к ООП никакого отношения не имеет
G>>ООП обычно использует довольно слабый вид полиморфизма: ad-hoc полиморфизм по неявному аргументу.
КЛ>G>Шаблоны и генерики не относятся к ООП вообще никак.
КЛ>однако они дают статический полиморфизм
И что? Причем тут ООП?
[]
G>>>ООП обычно использует довольно слабый вид полиморфизма: ad-hoc полиморфизм по неявному аргументу.
КЛ>>G>Шаблоны и генерики не относятся к ООП вообще никак.
КЛ>>однако они дают статический полиморфизм
G>И что? Причем тут ООП?
Здравствуйте, Michael7, Вы писали:
M>C++ именно в расчетах, в которых критична скорость, совершенно не оправдан.
Он оправдан там, где _сложность_
Что касается скорости, то не забываем, что критичного кода к остальному даже не 20:80, а где-то от 5:95 до 1:99 при внимательном изучении
Также не забываем, что с современными оптимизаторами практически нет смысла соревноваться на низком уровне
Гораздо более важно иметь _гибкость_ — возможность легко заменять реализацию какого-либо алгоритма, подзадачи.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, Michael7, Вы писали:
M>>C++ именно в расчетах, в которых критична скорость, совершенно не оправдан.
HA>Он оправдан там, где _сложность_ HA>Что касается скорости, то не забываем, что критичного кода к остальному даже не 20:80, а где-то от 5:95 до 1:99 при внимательном изучении HA>Также не забываем, что с современными оптимизаторами практически нет смысла соревноваться на низком уровне HA>Гораздо более важно иметь _гибкость_ — возможность легко заменять реализацию какого-либо алгоритма, подзадачи.
Если бы всё было так, то ради гибкости код бы писался на питоне, а оставшийся 1% — на Си или Фортране. =)))
я вот до того как померил думал что сишного кода
в меркуриале не 5% а как минимум 20%.
Понятно что полно приложений которые так не напишешь, но такие гибриды вполне конкуренты C++ и даже яве с шарпом.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, Michael7, Вы писали:
M>>C++ именно в расчетах, в которых критична скорость, совершенно не оправдан.
HA>Он оправдан там, где _сложность_
И чем он оправдан там где сложность?
Скорее наоборот. Сложность реализации простых вещей оправдывается языком C++, но при этом во всю говорят о том как это эффективно.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Mazay, Вы писали:
M>>Если бы всё было так, то ради гибкости код бы писался на питоне, а оставшийся 1% — на Си или Фортране. =)))
FR>Тык и пишут http://www.rsdn.ru/forum/design/4127605.1.aspx
я вот до того как померил думал что сишного кода FR>в меркуриале не 5% а как минимум 20%. FR>Понятно что полно приложений которые так не напишешь, но такие гибриды вполне конкуренты C++ и даже яве с шарпом.
Да-да. Я там как-то криво написал. Короче не важно сколько там процентов критичного по производительности кода. Важно что если такого кода много (1% от дофига, это всё равно дофига) и он сложный, то его удобно писать на C++. То есть С++ это удачный компромисс между производительностью и современными языковыми средствами. Почти нулевой пенальти и почти все современные тулзы. Страдает при этом понятность языка для человека. Классический случай "Овцы целы, волки сыты. Так погиб чабан Никита".
Здравствуйте, DelphiGuru, Вы писали:
DG>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
Собственно говоря, отличие в том, что на С++ это делать не нужно. А преимущество это или недостаток...
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, Mazay, Вы писали:
M>>>Если бы всё было так, то ради гибкости код бы писался на питоне, а оставшийся 1% — на Си или Фортране. =)))
FR>>Тык и пишут http://www.rsdn.ru/forum/design/4127605.1.aspx
я вот до того как померил думал что сишного кода FR>>в меркуриале не 5% а как минимум 20%. FR>>Понятно что полно приложений которые так не напишешь, но такие гибриды вполне конкуренты C++ и даже яве с шарпом.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, DelphiGuru, Вы писали:
DG>>На Дельфи уже вовсю смарт пойнтеры кропают
S>Главное, что дельфа никому не надо. В лучшем случае поддержка старья.
Здравствуйте, DelphiGuru, Вы писали:
DG>Здравствуйте, Ikemefula, Вы писали:
I>>Здравствуйте, DelphiGuru, Вы писали:
DG>>>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
I>>Что значит чистое ООП ? STL вдруг перестала быть ООП ?
I>>Пока что никто не смог доказать, что лямбда-счисление Черча превосходит по мощности машину тьюринга, что означает что любую задачу можно ка попало решить. DG>1-STL сроду не ООП. Там в половине случаев вообще можно обойтись без шаблонов, при использовании столь мощной абстракции как итераторы. DG>2-Вектор реализован вообще через одно место. Чтобы мне пройти вектор по не последовательно, а используя другой способ формирования следующей позиции — то облом. DG>про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
Я смотрю, набросы про STL дают много корма нашим зелёным друзьям...
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, blackhearted, Вы писали:
b>> я не в курсе. b>> Он их on server-side считает?
AB>Для mercurial термин server-side не совсем корректен. Хотя, смотря что считать сервером.
Где он диффы считает? На локальной машине в локальном репозитории?
Здравствуйте, FR, Вы писали:
FR>Ну замыкание в реализации итератора явно присутствует, во первых итератор держит в себе ссылку на контейнер во вторых позицию FR>в контейнере
Но это же не означает эквивалентности. Замыкание — особенность реализации итератора, а не основная его функция.
Здравствуйте, blackhearted, Вы писали:
AB>>Для mercurial термин server-side не совсем корректен. Хотя, смотря что считать сервером.
B>Где он диффы считает? На локальной машине в локальном репозитории?
