Здравствуйте, DelphiGuru, Вы писали:
DG>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
Что значит чистое ООП ? STL вдруг перестала быть ООП ?
Пока что никто не смог доказать, что лямбда-счисление Черча превосходит по мощности машину тьюринга, что означает что любую задачу можно ка попало решить.
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, DelphiGuru, Вы писали:
DG>>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
S>Си++ — это источник бабала, возможность найти себе работу практически в любой стране, да Дельфи нет. Что там внутри технологии мне поровну.
Отвечаю всем.
1- Шаблонов и дженериков не будет
2- Лень побеждает в 4 раз за 2 года
3- При появлении везде дженериков не вижу смысла выкладывать. На Дельфи уже вовсю смарт пойнтеры кропают
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, DelphiGuru, Вы писали:
DG>>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
I>Что значит чистое ООП ? STL вдруг перестала быть ООП ?
I>Пока что никто не смог доказать, что лямбда-счисление Черча превосходит по мощности машину тьюринга, что означает что любую задачу можно ка попало решить.
1-STL сроду не ООП. Там в половине случаев вообще можно обойтись без шаблонов, при использовании столь мощной абстракции как итераторы.
2-Вектор реализован вообще через одно место. Чтобы мне пройти вектор по не последовательно, а используя другой способ формирования следующей позиции — то облом.
про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
Здравствуйте, DelphiGuru, Вы писали:
DG>2-Вектор реализован вообще через одно место. Чтобы мне пройти вектор по не последовательно, а используя другой способ формирования следующей позиции — то облом.
Вектор прекрасно индексируется. Если надо на итераторах, то std::advance к итератору вектора имеет сложность операции сложения.
DG>про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
конкретику в студию. Что именно нужно получить, но нельзя из-за "жёсткого представления"
Здравствуйте, DelphiGuru, Вы писали:
S>>вы имеете ввиду динамический полиморфизм? легко можно, но получим тогда что-то такое тормозное, типа явы. DG>Я имею в виду, то что его можно реализавать именно в том виде, в каком он есть в Си++, то есть алгоритмы будут независимы от контейнеров, более того, я считаю, что контейнеры не более чем примерами использования алгоритмов, т.к. на тех же плюсах я могу использовать алгоритмы STL и на велосипедных контейнерах.
Т.е. речь идёт о том, чтобы для совместимости с интерфейсом оставить шаблоны где нужно, а внутри ввести операции боксинга-анбоксинга? А в чём-смысл?
Здравствуйте, DelphiGuru, Вы писали:
I>>Пока что никто не смог доказать, что лямбда-счисление Черча превосходит по мощности машину тьюринга, что означает что любую задачу можно ка попало решить. DG>1-STL сроду не ООП. Там в половине случаев вообще можно обойтись без шаблонов, при использовании столь мощной абстракции как итераторы.
Шаблоны это не ооп ?
DG>2-Вектор реализован вообще через одно место. Чтобы мне пройти вектор по не последовательно, а используя другой способ формирования следующей позиции — то облом.
Возможности обхода это ООП ?
DG>про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
Т.е. если способ представления поменять нельзя, стало быть это не ООП ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, DelphiGuru, Вы писали:
I>>>Пока что никто не смог доказать, что лямбда-счисление Черча превосходит по мощности машину тьюринга, что означает что любую задачу можно ка попало решить. DG>>1-STL сроду не ООП. Там в половине случаев вообще можно обойтись без шаблонов, при использовании столь мощной абстракции как итераторы.
I>Шаблоны это не ооп ?
DG>>2-Вектор реализован вообще через одно место. Чтобы мне пройти вектор по не последовательно, а используя другой способ формирования следующей позиции — то облом.
I>Возможности обхода это ООП ?
DG>>про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
I>Т.е. если способ представления поменять нельзя, стало быть это не ООП ?
Я что, должен копипастить весь шаблон vector, чтобы иметь возможность иногда менять строго поэлементный просмотр на нечто другое. А если бы методы возвращающие итераторы были виртуальными все было бы гораздо проще:
class MyVector: public Vector<MyType>{
virtual ittype begin{}
и т. д (прошу прошения за ошибки, давно не писал)
}
А про количичество типов деревьев, которые наиболее производительно каждое на своем сегменте задач я вообще не говорю. а В STL зашит один тип и его не поменяешь
Здравствуйте, DelphiGuru, Вы писали:
I>>Т.е. если способ представления поменять нельзя, стало быть это не ООП ? DG>Я что, должен копипастить весь шаблон vector, чтобы иметь возможность иногда менять строго поэлементный просмотр на нечто другое.
ООП и хороший/плохой дизайн это вещи никак между собой не связаные.
И то и другое может быть как в ООП так и безо всякого ООП.
Чего ты хотел сказать про STL, что тебе не нравятся возможности, что тебе не нравится дизайн, что ты не считаешь это ООП ?
Здравствуйте, DelphiGuru, Вы писали:
DG>Я что, должен копипастить весь шаблон vector, чтобы иметь возможность иногда менять строго поэлементный просмотр на нечто другое. А если бы методы возвращающие итераторы были виртуальными все было бы гораздо проще: DG>class MyVector: public Vector<MyType>{ DG> virtual ittype begin{} DG> и т. д (прошу прошения за ошибки, давно не писал) DG>} DG>А про количичество типов деревьев, которые наиболее производительно каждое на своем сегменте задач я вообще не говорю. а В STL зашит один тип и его не поменяешь
Погоди, а что не давало перегузить метод?
Если ты делаешь свой тип, наследный от vector, перекрываешь невиртуальный метод и потом указываешь его в параметрах шаблонов функций, то будет вызван твой метод, а не метод vector.
Здравствуйте, Sni4ok, Вы писали:
S>в расчётах, где-же ещё.
C++ именно в расчетах, в которых критична скорость, совершенно не оправдан. Потому что как только речь заходит об оптимизации по скорости все высокоуровневые абстракции C++ применять нельзя. От C++ остается фактически только Си, который и используется в расчетах. Да и Фортран в вычислениях до сих пор широко используется и не только для поддержки старого кода. Еще один минус C++ в этом случае — это Name mangling из-за чего усложняется использование C++-ных библиотек в других средах и даже просто других компиляторов.
Так что писать сугубо вычислительную часть на C++ неразумно.
Здравствуйте, DelphiGuru, Вы писали:
DG>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
Пишу на C++. Писал на Delphi. STL использую. ООП использую. Вопроса не понял.
Здравствуйте, DelphiGuru, Вы писали:
DG>Здравствуйте, Ikemefula, Вы писали:
I>>Здравствуйте, DelphiGuru, Вы писали:
DG>>>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
I>>Что значит чистое ООП ? STL вдруг перестала быть ООП ?
I>>Пока что никто не смог доказать, что лямбда-счисление Черча превосходит по мощности машину тьюринга, что означает что любую задачу можно ка попало решить. DG>1-STL сроду не ООП. Там в половине случаев вообще можно обойтись без шаблонов,
Какое отношение это имеет к ООП? Никакого. Это имеет отношение к дизайну.
DG>при использовании столь мощной абстракции как итераторы. DG>2-Вектор реализован вообще через одно место. Чтобы мне пройти вектор по не последовательно, а используя другой способ формирования следующей позиции — то облом.
Какое отношение это имеет к ООП? Никакого. Это имеет отношение к дизайну.
DG>про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
Какое отношение это имеет к ООП? Никакого. Это имеет отношение к дизайну.
Странно, ты считашь, что в стл не чистый ООП, а примеры приводишь не по ООП, а по дизайну библиотеки
I>>Возможности обхода это ООП ?
DG>>>про map уже гдето здесь писали, что способ представления жестко зашит и его не поменяешь
I>>Т.е. если способ представления поменять нельзя, стало быть это не ООП ? DG>Я что, должен копипастить весь шаблон vector, чтобы иметь возможность иногда менять строго поэлементный просмотр на нечто другое. А если бы методы возвращающие итераторы были виртуальными все было бы гораздо проще: DG>class MyVector: public Vector<MyType>{ DG> virtual ittype begin{} DG> и т. д (прошу прошения за ошибки, давно не писал) DG>} DG>А про количичество типов деревьев, которые наиболее производительно каждое на своем сегменте задач я вообще не говорю. а В STL зашит один тип и его не поменяешь
Какое отношение это имеет к ООП? Никакого. Это имеет отношение к дизайну. Менее ООП оно от этого не становится
Здравствуйте, DelphiGuru, Вы писали:
DG>После недели детального изучения исходников STL я пришел к выводу, что ее можно реализовать при помощи чистого ООП. Что думают пишущие на Си++ об этом
ты потратил неделю своей жизни в пустую, вот что мы думаем
Здравствуйте, lazy_walrus, Вы писали:
_>Здравствуйте, Константин Л., Вы писали:
КЛ>>ты потратил неделю своей жизни в пустую, вот что мы думаем
_>Мы, царь всея Руси?
ну я. какая разница. предвосхищая вопросы — если чел пялился в исходники неделю и в 2011 задает такие вопросы и делает такие предположения, значит он зря потратил своё время
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, Sni4ok, Вы писали:
S>>в расчётах, где-же ещё.
M>C++ именно в расчетах, в которых критична скорость, совершенно не оправдан. Потому что как только речь заходит об оптимизации по скорости все высокоуровневые абстракции C++ применять нельзя.
+1. Своими глазами видел в коде GCC
if (current_abstraction_level > 4)
enable_optimization = 0;
M>Еще один минус C++ в этом случае — это Name mangling из-за чего усложняется использование C++-ных библиотек в других средах и даже просто других компиляторов. M>Так что писать сугубо вычислительную часть на C++ неразумно.
Здравствуйте, Константин Л., Вы писали:
КЛ>ну я. какая разница. предвосхищая вопросы — если чел пялился в исходники неделю и в 2011 задает такие вопросы и делает такие предположения, значит он зря потратил своё время
А почему зря? Человек с опытом программирования на Delphi изучил исходники STL, расширил свой кругозор, у него возникли понятные вопросы почему STL сделан так а не иначе, и нельзя ли сделать лучше.
