? — критерии и единицы оценки размера не указаны

? — vtable ведь тоже данные

? — во время компиляции, вероятно (в asm-коде уже только данные)

vs
тогда уж, сравнивать следовало бы с некими "расширенными" библиотеками C++

? — e.g. в method.dll есть код класса type (C++), method.lib подключается к проекту,
использующему (as dynamic library, not static) type (где дублирование?)

Это сообщение отредактировал(а) SergeCpp - 22.11.2006, 14:35

зачем городить такую кострукцию , если можно поставить число?

Template metaprogramming

Blitz++
Blitz++ examples, also look at FFT implementation

etc.


Это сообщение отредактировал(а) SergeCpp - 22.11.2006, 16:02

не вижу хороших преймуществ, имхо все конструкции типа
можно заменить константами или дефайнами
А о пункте 
* Readability:
они сами сказали, что фиг прочитаешь, зачем тогда путать людей? все равно эти Template metaprogramming кроме как сложновычисляемые постояные не заменяют, имхо , тогда проще вычислить все постояные и вставить в один массив, даже время компиляции сократится!

Readability: With respect to C++, the syntax and idioms of template metaprogramming are esoteric compared to conventional C++ programming, and advanced, or even most non-trivial, template metaprogramming can be very difficult to understand. Metaprograms can thus be difficult to maintain by programmers inexperienced in template metaprogramming (though this may vary with the language's implementation of template metaprogramming syntax).


vs

Boost.MPL

Boost.Lambda



Это сообщение отредактировал(а) SergeCpp - 22.11.2006, 16:35

  Если объект не хранилище данных, то обычно размер (в байтах) его полей данных намного меньше чем область памяти занимаемая его методами. 

  Таблица виртуальных методов тоже данные, но что из этого следует я не понял... я же не говорил, что класс содержит только методы... класс содержит все что является статичным т.е. не меняется от объекта к объекту. А методы как раз и не меняются от экземпляра класса к экземпляру (если объект действительно экземпляр своего класса, а не класса наследника).

  Под структурой я понимаю некую область памяти где размещены данные объединенные логически (т.е. класс,  речь не идет о структурах языка С++)

Так объектов-то (даже крохотных) может быть очень много... А метод на всех них — один.

Это к Вашему слову "обычно". В объекте всегда только данные, а не "обычно".

Объект всегда экземпляр своего класса. Вы, наверное, имели в виду указатель на объект.

В физической DLL конечно же есть логические области. Но вот как процессор поймёт что это область, без физического указания?..

Так где же дублирование-то?..


Это сообщение отредактировал(а) SergeCpp - 22.11.2006, 16:56

SergeCpp, что ты этим всем хочешь сказать , имхо , я те уже говорил

смысл описания этих

в контексте темы?
PS сколько я программил на С/С++, никогда еще не возникало надобности в использовании 

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


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


Если чесно, то я просто не понял. Неужели статические библиотеки *.lib можно загружать динамически во время исполнения и использовать классы реализованные в ней? Они же называются статическими   

Так это же основное условие работы с чем-либо — знать...

это данные... используемые нетривиальным образом.


Так я же говорил...


Ключевые слова — as dynamic library, not static (method.lib в таком случае — библиотека импорта [из DLL]).


Это сообщение отредактировал(а) SergeCpp - 22.11.2006, 17:36

Из такого краткого пояснения мало что можно понять. То ли *.lib файл помогает динамически связывать классы определенные в Dll, то ли она сама заменяет dll, то ли ее помещают в секцию импорта экзешника, и потом все происходит волшебным образом  , можно еще придумать пару способов как интерпретировать эту фразу  . Все осложняется тем, что секция импорта содержит экспортируемые (библиотекой) функции, а не классы, так что, что нам помогает делать *.lib для передачи классов вообще не ясно  

Это сообщение отредактировал(а) alexeis1 - 22.11.2006, 17:48

Почитайте...

Я был вместе с Delphi со 2-й по 4-ю версию, потом перешел на C++ и не жалею.
Можно посоветовать примерно следующее:

только здесь число 3 заменить на N  И осваивать не только императивные, но декларативные языки программирования.


А вот благодаря Билдеру я совершил переход в плюсы на год позже, чем мог бы. Элементарно, установив Билдер и увидев, что Борланд сделал с родной Дельфи -- я на некоторое время посчитал этО недостатком языка, а не Борланда. Испугался, одним словом, и снес Билдер  С тех пор его больше и не ставил 


Я аж прослезился. До сих пор рыдаю.
Такие вот мы, садомазохисты и извращенцы 


Угу. И в теме кроссплатформенности Дельфи не лидер. 
Про математику вообще молчу.

Правда, сам я уже пару-тройку лет не чистый плюсатник, но это, наверно, уже не в тему  .

Добавлено @ 04:10 

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

Это сообщение отредактировал(а) Artemios - 23.11.2006, 04:29

А ты не молчи , мы тя слушаем!

1. ее здесь никто не обсуждает
2. при большом желании ее тоже в дельфи можно найти

Да. Именно они. Мне не всегда нужен полиморфизм времени выполнения. Имея инструмент в виде шаблонов, я могу использовать полиморфизм времени компиляции. Что даст мне прирост производительности и уменьшение вероятности сделать ошибку. Правда за такое удобство приходится платить, но плата несущественна.

Я бы сказал иначе - любой алгоритм.

Да, плюс, но увы единственный ради которого ещё можно объяснить использование Delphi (хотя я лишний раз подумаю о С# или о python). Если убрать RAD средства, то в чем смысл использования? Что Delphi в таком виде может предложить по сравнению с другими языками?

Примеры тебе предоставляет рынок ПО.