Вход на сайт
программисткие курсы
649 просмотров
Перейти к просмотру всей ветки
в ответ Wlad75 03.12.05 22:18
Если это условие игнорируется, то я не считаю задачу решенной.
-----
Увы, в системах есть характеристика - время реакции системы - т.е. время с момента получения запроса до момента выдачи результата. До тех пор, пока время реакции гарантируется разработчиком - задача всегда решена, независимо от того каким образом это сделано.
Просто STL слишком абстрактен, чтобы быть эффективным.
-----
Хммм... с каких это пор абстрактность стала синнонимом неэффективности? Возьми, к примеру, математику - совершенно абстрактная вещь - и попробуй обойтись без нее в разработке...
Практически всюду в критических ко времени выполнения кусках кода "С с классами" и ассемблером дают серьезный выигрыш по сравнению с С++/STL/CGAL
-----
Если вы найдете время, чтобы еще раз "сесть и обдумаеть" задачу, желательно - с нуля, совершенно оторвавшись от существующего решения, то выяснится весьма интересная штука - те самые "критические по времени выполнения куски С++ с ассемблером" могут вообще исчезнуть как таковые, а остаток приемлемо решится штатными средствами С++/С#/Java & etc., бо, нет недостаточной эффективности языков, а есть - непонимание задачи и неумение применять имеющиеся средства.
у нас есть проблема фрагментации адресного пространства
-----
Ну-ну... бедняги, 65К дескрипторов сегментов в потоке не хватает... можно подумать, что new/delete автоматическти привязывающие vtable к области данных создают больше проблем, чем alloc/free с последующим ручным назначением так же в ручную сформированных эмуляторов той же vtable и всеми последующими глюками связанными с сопровождением... К тому же время, съедаемое построением и сопровождением данных сурогатов, не позволяет взять документацию по современным процам и подсистеме управления памятью в виндах и научиться их эффективно использовать... даже через тот же STL.
-----
Увы, в системах есть характеристика - время реакции системы - т.е. время с момента получения запроса до момента выдачи результата. До тех пор, пока время реакции гарантируется разработчиком - задача всегда решена, независимо от того каким образом это сделано.
Просто STL слишком абстрактен, чтобы быть эффективным.
-----
Хммм... с каких это пор абстрактность стала синнонимом неэффективности? Возьми, к примеру, математику - совершенно абстрактная вещь - и попробуй обойтись без нее в разработке...
Практически всюду в критических ко времени выполнения кусках кода "С с классами" и ассемблером дают серьезный выигрыш по сравнению с С++/STL/CGAL
-----
Если вы найдете время, чтобы еще раз "сесть и обдумаеть" задачу, желательно - с нуля, совершенно оторвавшись от существующего решения, то выяснится весьма интересная штука - те самые "критические по времени выполнения куски С++ с ассемблером" могут вообще исчезнуть как таковые, а остаток приемлемо решится штатными средствами С++/С#/Java & etc., бо, нет недостаточной эффективности языков, а есть - непонимание задачи и неумение применять имеющиеся средства.
у нас есть проблема фрагментации адресного пространства
-----
Ну-ну... бедняги, 65К дескрипторов сегментов в потоке не хватает... можно подумать, что new/delete автоматическти привязывающие vtable к области данных создают больше проблем, чем alloc/free с последующим ручным назначением так же в ручную сформированных эмуляторов той же vtable и всеми последующими глюками связанными с сопровождением... К тому же время, съедаемое построением и сопровождением данных сурогатов, не позволяет взять документацию по современным процам и подсистеме управления памятью в виндах и научиться их эффективно использовать... даже через тот же STL.