|
|
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
не удержусь. там, кстати, в качестве преимущества говорится, что дженерики явы будут нормально инстанцироваться для полиморфных типов. В С++ же нужно строгое соответсвие типам. Я не считаю это недостатком. 1) объекты в яве всегда по сути указатели на их место в куче. поэтому когда вы пишете в яве vector<MyObj>, то это по сути вектор указателей. Указатели в С++ обладают тем же свойством, т.е. возможность присвоения полиморфных объектов. неверно наверное выразился. За исключением канечно даункастинга. Вопрос: а нафига так смешивать две разные технологии? Их взаимодействие необходимо, они т.о. компенсируют недостатки друг друга и услиливают преимущества. Вобчем возможно есть какие-то приемы программирования, для которых такая возможность нужна. Буду рад если мне о них кто-нить расскажет. 2) если бы мы написали полиморфные классы. Т.е. класс имеющий виртуальные функции и имеющий потомков. Ну это я к примеру. Можно ли в С++ такой класс распологать в динамических массивах или контейнерах напрямую без указателей? Нет нельзя. Потому что размер объекта в этом случае может быть разный. Вобчем это давняя ошибка начинающих программеров. В таких случаях как раз хранят только указатели на объекты. Сергей Ильич пирмеры форвардинга шаблонов полно в инете. сегодня меня не будет, вернее буду только поздно вечером. поэтому в добавок к способам применения generic programming, могу привести достаточно удачный и удобный способ управления преобразованием типов. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. нам не надо писать кучу операторов для всех возможных типов. Мы пишем один шаблонный метод обычного класса. И теперь на этапе компиляции все ошибки нерадивых пользователей библиотеки или наши собственные будут присекаться. А если учесть, что методы можно перекрывать, то можно рарешать преобразования только для ОДНОГО или НЕСКОЛЬКИХ типов. Для остальных запрещать. вот вам еще один удобный способ применения шаблонов. до вечера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 08:17 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Cергей Ильич кстати насчет бинарника, могу свой пример откомпилировать и он будет занимать килобайт ну или чуть больше. могу на спор. только интересно как вы будете проверять. между прочим это связано не с шаблонами а опциями линковщика. 8-))) Распухание EXE из-за шаблонов это миф. Известно ли вам в кратце механизм инстанцирования шаблонов? Известно ли вам, что инстанцируются, т.е. компилируются только те методы которые вызываются, все остальное так и остается простым текстом программы. Т.е. если мы бы писали контейнер на Яве и с теми методами которые есть у std::vector и его итераторов, то класс получился бы толще, чем std::vector на С++ именно, потому что инстанцируется только то что мы используем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 08:23 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
dwl 2) про конструктор ваще смешно, стандартное раскручивание стека. никакой утечки памяти не бует. уничтожатся все объекты, кторые успели создаться. это стандарт. не только для буста. Гнусная багофича MSVC - при возникновении исключения в конструкторе память, выделенная под объект, *не освобождается*. "Не бросайте исключений в конструкторах" (С) Microsoft Честно говоря, это очень хреново, посколько инициализация - это зона повышенного риска. Если писать только пустые конструкторы, а инициализацию выносить в Init() или Create(), то я не смогу инициализировать const - поля класса. Без const полей мне не нужны const методы. Без const методов клиент моего кода сможет делать не то, что я от него ожидал. dwl 3) если хотите без исключений ставьте опцию компилятора без исключений Придется вестимо. А как буст будет мне сигналить об ошибках? dwl Сергей ИльичА если обобщенному классу A нужен обобщенный класс В, а обобщенному классу B нужен обобщенный класс A? конкретно, что вы имеете ввиду. если речь о форвардных декларациях в шаблонах они возможны. Пример - в студию dwl Сергей Ильич Но в MSVC так с шаблонами делать нельзя. я не знаю кто вам нашептывает на ушко. дайте кнкретный код, я его скомпилирую в MSVC. Масоны мне шепчут. Помню я писал на ATL/WTL, там из-за шаблонов нельзя было разделять предварительную декларацию и имплементацию классов. Я конкретно задолбался подбирать порядок инклюдов. Кроме того, длительность компиляции возрастала квадратично в зависимости от объема кода. Когда проект вырос до ~300Кб исх.кода, начали выскакивать Internal Compiler Error. Кроме того, я огреб огромный гиморрой, когда два класса хотели сущности перекрестно друг из друга. Влом сейчас поднимать, что там было, но вот тривиальный вариант. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. dwl Сергей ИльичПочему бы и не поплодить. Ведь в Java есть пакеты. По крайней мере я 100% знаю, что мне в качестве параметра будут передавать org.sergey.ilyich.sql-forum-conversation.Listener, а не метод с какую-то сигнатурой. Однако меня вы очень рьбъяно и принципиально обвиняли в плодении сущностей. Сущностей языка, а не программы. Пользуясь интерфейсами, я имею большую гранулярность контроля, и большую type safety org.sergey.ilyich.sql-forum-conversation.Listener это не какая-нибудь сигнатура. dwl Ляпнули что-то про книжку Александреску и отказались это объяснить. ушли просто убежали от обсуждения. Пока появились компиляторы, пристойно это поддерживающие (я ксати не знаю, появились ли и насколько пристойно), я успел сделать пару проектиков, и мне теперь их надо поддерживать. Сергей ИльичЛямбда чтоли? ну наверное, я понятия не имею что вы конкретно подразумеваете под этим словом. опять возвращаясь к вашему любимому критерию, который два поста назад был для вас принципиальным, а теперь вы его отторгнули. я о кол-ве сущностей. 8-) анонимные методы, тоже ИНОГДА удобный способ не плодить чего-то понапрасну. Лямбда исчисление Черча - это термин из середины прошлого века. Ламбда - функциями называются анонимные функции в функциональных языках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 09:14 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Пардон, длинный пост, неправильно отцитировал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 09:16 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Siebentearbeit авторЗачем нужны функции и методы? Почему не одни методы? Не писал, видимо, никогда на сях. В Яве ни одна функция не может существовать сама по себе. В сях может, и это удобно, для классонезависимых приседаний. Например у меня одной функцией сделана работа дебага, со статических хэндлом окна, статическим указателем на файл и статическими флагами. Мне тут класс нафиг никакой не нужен, чё бы кто там про концептуальность и прочее не говорил. Кто тебе в Яве мешает сделать статическую функцию? И свалить все статические поля в радом? Не будет в глобальном skope всякое шайзе бултхаться Siebentearbeit авторПро размер бинари - это тоже хороший вопрос. Мой пример займет несколько килобайт, твой - возможно несколько десятков или сотен килобайт. Звиняйте, ваш код - код для интерпретатора, а не бинарник. И работать, не смотря на малость, будет дольше. PE EXE - это тоже интерпретируемый код для ядра win32. Он тоже не чистый native. Siebentearbeit авторОй, пишут, гады, представляешь ? Пишут. Да, я подозревал, что такие есть. Они либо не умеют С. Либо страшные приверженцы Явы. Либо лучше держаться от них подальше - неясно, что у них на уме :) Я вообще пишу server - side, НО кстати, в Яве грид для контролов сделан более по уму. Если в немецкой версии программы на кнопке вместо "Cancel" будет написано "Abbrechen", то пропорции в сетке будут пересчитаны, вместо того чтобы откусывать чего-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 09:57 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Сергей Ильич PE EXE - это тоже интерпретируемый код для ядра win32. Он тоже не чистый native. разве так? думаю нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:12 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
alex_k Сергей Ильич PE EXE - это тоже интерпретируемый код для ядра win32. Он тоже не чистый native. разве так? думаю нет... Загрузчик PE EXE конкретно готовит код для работы. Он как минимум распихивает куски кода по страницам, и меняет адреса переходов по спец. таблице. JVM комиплирует программу по ходу ее работы. Уровень абстракии разндый, это да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:20 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
это может быть и интерпретируемый код для ядра win32, но эта работа выполняется на стадии загрузки процесса в память. На мой взгляд это разные уровни абстракций разных сущностей. Всетаки загрузка процесса в память и исполнение процесса - это разные сущности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:29 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
авторНе будет в глобальном skope всякое шайзе бултхаться Что все так боятся глобальных переменных и функций? Что в них плохого? авторPE EXE - это тоже интерпретируемый код для ядра win32. Он тоже не чистый native. Это кто? Стоп, может я чё-то недопонимаю... Вот в VC я собираю ехе-шник, он грузится в память по кускам и выполняется, как есть. В Java я собираю class. Они разбирается машиной, и ей же выполняется. (зато на разных(вроде) платформах) Но медленнее, чем родной код. Поэтому я и говорю, что на яве писать виндовые апликухи - странно. А ещё использовать какой-нить свинг.. это вообще капец...(как я, когда был глупый и писал апплет,.. потом переписывал на стандарнтных, переделанных мной, контролах) авторНО кстати, в Яве грид для контролов сделан более по уму. В яве в стандартных контролах нету грида. оффтоп: Как-то, однажды, тоже писал гр.интерфейс под немецкий язык :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 10:44 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Cергей ИльичГнусная багофича MSVC - при возникновении исключения в конструкторе память, выделенная под объект, *не освобождается*. "Не бросайте исключений в конструкторах" (С) Microsoft специально запустил это на шестерке Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. Cергей ИльичПример - в студию Код: plaintext Cергей ИльичМасоны мне шепчут. Помню я писал на ATL/WTL, там из-за шаблонов нельзя было разделять предварительную декларацию и имплементацию классов. вот ведь коварные какие масоны! Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. теперь о перекрестном форвардинге. Чтобы проинстанцировать шаблон должны быть известны все типы и значения переменных и функций, на которых он собирается. Поэтому в некоторых случаях можно и придется явно проинстанцировать шаблон полностью. Только это очень плохо. Не стоит забывать что ООП, и generic это разные технологии. Прнименять один и тот же подход к обеим нельзя. Как например глупо писать массив нетипизированных указателей, когда можно определить шаблон контейнера. Форвардная декларция нужны для независимости от реализации типа, а привязки только к интерфейсу например. что ж в шаблонах это лучше делать так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. именно этот прием используется в большинстве библиотек. Хотя на самом деле можно обойтись вложенными типами, по аналогии с итераторами. Реализация итератора зависит от реализации контейнера, поэтому класс инкапслуриуется внутрь контейнера. Так меньше сложностей. Так что в случае с шаблонами, т.к. это все таки другая технология, перкрестных ссылок можно избежать. Хотя повторюсь форвардная декларация как шаблона класса так и шаблона функции ВОЗМОЖНА . пример выше на два примера. Cергей ИльичСущностей языка, а не программы. Пользуясь интерфейсами, я имею большую гранулярность контроля, и большую type safety org.sergey.ilyich.sql-forum-conversation.Listener это не какая-нибудь сигнатура. А вот это увы голословность. А точнее просто вода. Не может массив Object* быть безопасней (да и вообще безопасным), чем vector<T>. Это очевидно из определений. Динамический полиморфизм ограничен рамками определенного интерфейса, т.е. он bounded и dynamic. bounded, как раз и означает ограничение по интерфейсам для типов участвующих в полиморфизме. Чтобы с этим "бороться" приходится повторно переписывать и копировать тот или иной код, или прибегать к НЕБЕЗОПАСНЫМ преобразованиям типов. Ну и наконец само связывание происходит динамически то есть на этапе ВЫПОЛНЕНИЯ ПРОГРАММЫ. Т.е. многие ошибки программиста при работе с интерфейсом будут вылетать только на этапе выполнения программы. Вот уж что нечитабельно так это AV. но у такого подхода есть приемущества, как то меньший размер кода и нет необходимости в исходниках для предоставления библиотечных функций. Статический полимрфизм - интерфейс типов участвующих в полиморфизме не определен. Плюс связывание происходит на этапе компиляции. Это значит, что ошибки будут выявлены при компиляции программы, а не при ее выполнении и долгой отладке(чтобы исследовать все функции). Связывание типов, которое происходит на этапе компиляции ПО ОПРЕДЕЛЕНИЮ более надежно, чем СВЯЗЫВАНИЕ НА ЭТАПЕ ВЫПОЛНЕНИЯ. Недостаток статического связывания напрямую зависит от программиста. Потому что семантика(алгоритмика) обощенных классов может быть перврана. Например определить оператор<< как операцию сложения, а оператор+ как вывод в поток. такие сдвиги по фазе не определяются компилятором. поэтому грамотным людям очевидно, что лучше использовать и то и другое. Самый известный пример модель рекуррентного шаблона. при помощи него например можно параматризировать виртуальность методов, т.е. грубо говоря параметризировать интерфейс, а юзать его обычным ООП. Очень распространенный прием. Cергей ИльичПока появились компиляторы, пристойно это поддерживающие (я ксати не знаю, появились ли и насколько пристойно), я успел сделать пару проектиков, и мне теперь их надо поддерживать. рад за вас. Но это ИМХО не дает вам право выдавать такие обощения как книга Александреску не имеет никакого пракитческого применения ну или пользы. В просто мели все одну гребенку. Cергей ИльичЛямбда исчисление Черча - это термин из середины прошлого века. Ламбда - функциями называются анонимные функции в функциональных языках. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 19:34 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Отдельным постом отвечу насчет Не увеличений сущностей языка . Итак, бросаем на весы. ВЕСЫ МЕРЯЮТ ВРЕД И ПОЛЬЗУ только в ПЛАНЕ добавления и убавления сущностей языка. Что у нас добавляется: 1) шаблоны, а точнее технология статического полиморфизма, ну или связывания, как вам удобней. Это технология работает на обычном наборе УЖЕ ИМЕЮЩИХСЯ сущностей ЯП. ДОпустим это у нас в недостатки пойдет. Как вред в плане увелечения сущностей языка. (ох как я не люблю философское бла-бла) другая чаша весов. Чтобы мы получаем взамен из плюсов 1) большую безопасность типов. Статическое связывание дает большую безопасность, чем связывание во время выполнеия программы (виртуальные функции интерфейса или преобразование типов) 2) Большой запас прочности языка в плане востребованности других сущностей. Например, тип variant добавляется в некоторых языках, С++ не имеет такой необходимости, потому что такой тип реализуется посредством шаблонов, см. boost::any и boost::variant, который обходит ограничение на union+POD. Другой пример, проперти. Та же история, другие языки вынуждены добавлять новые ключевые слова, т.е преумножать сущности. проперти элементарно реализуются посредоством шаблонов, см. boost::poperty. Еще один пример, некоторые языки видя успех и преимущество контейнеров STL, добавляют новую структуру данных - динамические массивы, опять же преумножая сущности языка. Двигаемся дальше, делегаты - используя шаблоны реализуется даже более лучший(безопасный) и гибкий класс - boost::signal. Далее, анонимные функции. Далее, сборщик мусора. Т.е. создавая что-то одно (generic programming) мы избавляем язык от необходимости добавлять новые сущности. 3) Генерация более быстрого кода. Единственный язык, на котором при помощи шаблонов выражений (см. простейший пример std::valarray) была создана библиотека (матричные вычисления) более быстрая по скорости, чем аналогичная на фортране, которая держала короную многие десятки лет. Причем здесь сущности? Дело в том что другие языки, созданные для безопасного кода, чтобы получить какое-то ускорение добавляют в язык возможность написания ОПАСНОГО кода. Пример, unsafe и fixed в C#. Т.е. увеличивают кол-во сущностей языка. Весы явно перевешивают в сторону положительных моментов Статического Связывания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 19:54 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Добавочный короткий пост. уже запутался в длинных и мелких ПРИДИРКАХ к С++ от поклонника ИДЕАЛЬНОГО ЯЗЫК ЛИШЕННОГО НЕДОСТАТОКОВ. Сергей ИльичБез const полей мне не нужны const методы. ну у вас странное понимание относительно конст методов. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Сергей ИльичПридется вестимо. А как буст будет мне сигналить об ошибках? А зачем вам надо было отключать исключения? Вы спросили я ответил. Вы еще спросите, а можно что-то записать на нулевой адрес? и что тогда будет? Вобчем народ! всех с НАСТУПАЮЩИМ праздником. у меня лично начались праздничные хлопоты, чего и вам желаю. Это лучше чем лаяться на форумах и сидеть у компа. До после НОВОГО ГОДА, коллеги! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 20:05 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
dwl Cергей ИльичГнусная багофича MSVC - при возникновении исключения в конструкторе память, выделенная под объект, *не освобождается*. "Не бросайте исключений в конструкторах" (С) Microsoft специально запустил это на шестерке Код: plaintext 1. 2. 3. 4. 5. Ты его в стеке, а не в куче создаешь. dwl Cергей ИльичПример - в студию Код: plaintext Ну и куда мне это пихать? В модуль - клиент, модуль - сервер, может быть между инклюдов куда - нибудь? dwl Cергей ИльичМасоны мне шепчут. Помню я писал на ATL/WTL, там из-за шаблонов нельзя было разделять предварительную декларацию и имплементацию классов. вот ведь коварные какие масоны! Код: plaintext 1. Не удивил. Это вещь в себе. Компилятор начинает компилировать cpp файл, с помошью препроцессора втыкает в середину hpp файл, и получается один плоский файл, который ему надо скомпилировать. Когда он начнет компилировать другой cpp файл, он забудет про реализацию из первого cpp. dwl Хотя на самом деле можно обойтись вложенными типами, по аналогии с итераторами. Реализация итератора зависит от реализации контейнера, поэтому класс инкапслуриуется внутрь контейнера. Так меньше сложностей. Так что в случае с шаблонами, т.к. это все таки другая технология, перкрестных ссылок можно избежать. Хотя повторюсь форвардная декларация как шаблона класса так и шаблона функции ВОЗМОЖНА . пример выше на два примера. Кстати, в Java вложенные классы имеют доступ с переменным охватывающего класса, в контексте которого они порождены. Внутренние типы в стиле C++ в Java известны как "статические внутренние классы", т.е не имеющие доступ к охватывающему классу. dwl Cергей ИльичСущностей языка, а не программы. Пользуясь интерфейсами, я имею большую гранулярность контроля, и большую type safety org.sergey.ilyich.sql-forum-conversation.Listener это не какая-нибудь сигнатура. А вот это увы голословность. А точнее просто вода. Не может массив Object* быть безопасней (да и вообще безопасным), чем vector<T>. Это очевидно из определений. Динамический полиморфизм ограничен рамками определенного интерфейса, т.е. он bounded и dynamic. Вышеприведенный пример с Notification Broadcaster вполне можно запихать в класс, и повторно использовать сколько угодно раз, воспользовавшись агрегированием и Decorator design pattern. Про большую безопасность не надо - уж сколько слез я вижу в нашей столовой "Ой, у нас Protection fault выскакивает раз в 4 часа, и повторить условия мы не можем". Хотя, нам наверное dwl'а не хватает, чтобы он пришел и все разрулил. В Java подобные ошибки бывают, согласен, но все таки они не связаны с памятью, а поэтому втречаются намного реже. Какая-нибудь гнилая third-party библиотека, которую нам навязывает заказчик, пытается подключится к базе, и после таймаута возвращает null pointer, который передается другой гнилой библиотеке, которая куда-то его записывает. Причем этот тайм-аут там hardcoded. dwl Связывание типов, которое происходит на этапе компиляции ПО ОПРЕДЕЛЕНИЮ более надежно, чем СВЯЗЫВАНИЕ НА ЭТАПЕ ВЫПОЛНЕНИЯ. Недостаток статического связывания напрямую зависит от программиста. Потому что семантика(алгоритмика) обощенных классов может быть перврана. Например определить оператор<< как операцию сложения, а оператор+ как вывод в поток. такие сдвиги по фазе не определяются компилятором. В Java проверка соответствию типов осуществляется в процессе компиляции. Нормальные люди выставляют наружу (в public методах) специализированные интерфейсы. Есть утилиты типа checkstyle, которые анализируют код проекта, и сигналят, когда кто-то злоупотребляет типом Object, либо используют вместо функциональных интерфейсов конкретные типы. В С++, кстати, подобных утилит я не видел. Наверное, сложно все это проанализировать. Кстати, давно хотел спросить - спецификации исключений (throw) являются в С++ частью сигнатуры функции или не являются? dwl Cергей ИльичЛямбда исчисление Черча - это термин из середины прошлого века. Ламбда - функциями называются анонимные функции в функциональных языках. Код: plaintext 1. А смысл? В Лиспе или OCaml это будет более к месту. Программу на OCaml кстати, можно статически скомпилировать в машинный код, и язык этот строго типизирован. Там, кстати, нет уборки мусора, но управление памятью там сделано более по уму. Я, конечно, не агитирую за OcaML, но для общего развития полезно посмотреть этот язык. Чтобы сравнить. dwl уже запутался в длинных и мелких ПРИДИРКАХ к С++ от поклонника ИДЕАЛЬНОГО ЯЗЫК ЛИШЕННОГО НЕДОСТАТОКОВ. А чего - адвокаты в судах свято верят в невиновность своих подзащитых? Я не поклонник Джавы. Я просто знаю, что когда я пишу на Джаве, я встречаю намного меньше препятствий. dwl Сергей ИльичПридется вестимо. А как буст будет мне сигналить об ошибках? А зачем вам надо было отключать исключения? Вы спросили я ответил. Вы еще спросите, а можно что-то записать на нулевой адрес? и что тогда будет? Потому что исключения в С++ сделаны через жопу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 15:02 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Sie авторНО кстати, в Яве грид для контролов сделан более по уму. В яве в стандартных контролах нету грида. А как же GridBagLayout, SpringLayout etc? Кстати, почему в С++ нет дефолтовой GUI библиотеки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 15:33 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
а есть хоть одна операционная система, написанная на Java? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 15:42 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
gardenmanа есть хоть одна операционная система, написанная на Java? Не знаю. Может Symbian. Кстати, на С++ - тоже нет. Линукс написан на С, Винда написана на ASM + C + MS vision of C++. Кстати, из постов видно, что я не ненавистник С++, просто я к этому языку реалистично отношусь. Я придерживаюсь того стиля, который мне библиотеки навязывают. Я библитеки в основном от MS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 15:49 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
а JavaOS разве не на Java была написана? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2004, 16:19 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Сергей ИльичТы его в стеке, а не в куче создаешь. Во-первых не вижу необходимости лишний раз создавать объекты в куче - это вам не Ява. Но раз уж дело пошло на принцип... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Сергей ИльичКогда он начнет компилировать другой cpp файл, он забудет про реализацию из первого cpp. не вижу смысла размазывать реализацию ОДНОГО класса по нескольким CPP модулям - это плохой стиль. Сергей ИльичВышеприведенный пример с Notification Broadcaster вполне можно запихать в класс, и повторно использовать сколько угодно раз, воспользовавшись агрегированием и Decorator design pattern. вряд ли. Вернее так: 1) класс, как я неоднократно говорил создавался для списка callback функций. Ты оный кстати так и не представил нашему вниманию 2) в крайнем случае я просил показать как ты будешь сравнивать два объекта одного класса в твоем случае. 3) твой нотификатор работает только для одного типа методов. Для статической функции или просто функции тебе придется объявлять новый тип. 4) декоратор декоратором, один хрен - ПЛЮС новый тип, ПЛЮС преобразование типов, лио явное, либо через полиморфизм. Т.е. опять познее связывание. Вобчем как не крути все равно проигрышь. Сергей ИльичПро большую безопасность не надо - уж сколько слез я вижу в нашей столовой "Ой, у нас Protection fault выскакивает раз в 4 часа, и повторить условия мы не можем". Хотя, нам наверное dwl'а не хватает, чтобы он пришел и все разрулил. ну теперь ясна природа твоей ненависти к С++. Ты смотришь, как на нем неправильно пишут другие. ясненько. Это весьма типично. Сергей ИльичВ Java проверка соответствию типов осуществляется в процессе компиляции. замучился я повторять. Напиши контейнер для любого типа данных и ты увидишь, КОГДА ЯВА НЕ ПРОВЕРЯТ БЕЗОПАСНОСТЬ ТИПОВ. Эти случаи достаточно часты в больших проектах. Это по моему опыту. Сергей ИльичКстати, давно хотел спросить - спецификации исключений (throw) являются в С++ частью сигнатуры функции или не являются? дома у меня нет стандарта, на память - ИМХОт не является. Это что каверзный вопрос из разряда - АГА ОН НЕ ЗНАЕТ С++ настолько чтобы о нем судить? Да я и не говорил что я знаю С++ хорошо. Мне приятно перечитывать книги по нему(некоторые) и узнавать каждый раз что-то новое. Сергей ИльичЯ просто знаю, что когда я пишу на Джаве, я встречаю намного меньше препятствий. Это бессмыслено обсуждать. Я уже говорил, что у каждого специалиста в своей области выработаны свои привычки и технологии. Это как например взять посадить программиста MSSQL на ORACLE. ОН достаточно скоро его обругает и скажет что ORACLE плохая система. И это будет НЕВЕРНО. Сергей ИльичПотому что исключения в С++ сделаны через жопу. Опять обощения можно по конкретней? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.12.2004, 16:43 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
dwl Сергей ИльичТы его в стеке, а не в куче создаешь. Во-первых не вижу необходимости лишний раз создавать объекты в куче - это вам не Ява. Как в Яве, так и в С++ надо отдавать предпочтение долгоживущим объектам. Неплохо использовать Singleton, или какой-нибудь пул объектов. А создать долгоживущий объект в стеке несколько проблематично. dwl Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Меня интересует не факт вызова деструкторов, а факт вызова ::operator delete(...) под адрес, который вернул ::operator new(...), когда его попросили выделить память для помещения туда Three1 / Three2. MSDN Throwing an exception in a constructor is tricky, however, because the memory for the object itself has already been allocated by the time the constructor is called. There is no simple way to deallocate the memory occupied by the object from within the constructor for that object. Thus, you will find that throwing an exception in a constructor will result in the object remaining allocated. For a discussion of how to detect objects in your program that have not been deallocated, see the article Diagnostics: Detecting Memory Leaks. Вот так вот. Создаю какой-то долгоживущий (и наверное соответственно большой) объект в куче, у которого есть поля из бустовых классов, а какое-то бустовое поле возьми да и кинь екзепшен во время конструирования. И потеряю я память. А некоторые из мох программ должны вообще работать неделями и автономно - без мальчика аникейщика для нажимания резета. Ты видел, сколько памяти может вытечь даже очень маленькими и редкими капельками, если работа идет десятками часов? dwl Сергей ИльичКогда он начнет компилировать другой cpp файл, он забудет про реализацию из первого cpp. не вижу смысла размазывать реализацию ОДНОГО класса по нескольким CPP модулям - это плохой стиль. Я не о размазывании реализации класса, а о том, что эта реализация может понадобиться для компиляции других модулей проекта. НО компилятор ее не будет иметь, поскольку он про нее забыл, когда взял другой cpp файл. dwl 1) класс, как я неоднократно говорил создавался для списка callback функций. Ты оный кстати так и не представил нашему вниманию Поразительная твердолобость. Нету в Java callback функций, ибо не нужны они. Есть java.lang.reflect.Method, который можно использовать для вызова любого метода из любого класса, но он используется только для системного программирование под JVM. И в С++ они не нужны, я лично использую интерфейсы + (множественное наследование или внутренние классы), то есть тот же подход. std::vector<INotificationHandler*> в сто раз гибче и понятней. И не требует буст. И не требует небезопасного приведения типов. И такой сущности, как "Указатель на виртуальный метод класса" нету в С++ (может к счастью? напридумывали бы извратов с этим). dwl 2) в крайнем случае я просил показать как ты будешь сравнивать два объекта одного класса в твоем случае. Что такое "сравнивание двух объектов одного класса в моем случае"? Любой класс в Яве наследует от Object метод equals, который можно перегрузить. Ты про это? dwl 3) твой нотификатор работает только для одного типа методов. Для статической функции или просто функции тебе придется объявлять новый тип. Это я вообще не понял. Ты видишь сложности там, где их нет. dwl Сергей ИльичПро большую безопасность не надо - уж сколько слез я вижу в нашей столовой "Ой, у нас Protection fault выскакивает раз в 4 часа, и повторить условия мы не можем". Хотя, нам наверное dwl'а не хватает, чтобы он пришел и все разрулил. ну теперь ясна природа твоей ненависти к С++. Ты смотришь, как на нем неправильно пишут другие. ясненько. Это весьма типично. Я не люблю апеллировать к чужим авторитетам, как попы или моралисты. Скажу лишь, что во-первых стоимость специалиста - это очень немаловажный фактор. А у нас многие ребята - выпускники ИТМО и СПбГУ. А во-вторых, если какой-то человек может видеть многомерную структуру ньюансов С++, но при этом проект-лидер и коллеги по бригаде никак не могут достучаться до внутреннего мира такого человека, это очень плохо. Если по-твоему "реалистичное отношение к С++" это ненависть, то ненавистник - это как раз ты. По - моему реалистичное отношение к С++ это "Самый распространенный компилируемый язык программирования, доступный на Win и UNIX, доступно много библиотек из первоисточника, требует колоссальных усилий для написания даже простой программы, но выбора зачастую нет." dwl Сергей ИльичВ Java проверка соответствию типов осуществляется в процессе компиляции. замучился я повторять. Напиши контейнер для любого типа данных и ты увидишь, КОГДА ЯВА НЕ ПРОВЕРЯТ БЕЗОПАСНОСТЬ ТИПОВ. Эти случаи достаточно часты в больших проектах. Это по моему опыту. А я замучался отвечать, что в Яве никто не выставляет внутренние коллекции класса в public - доступ. А public API классов не дает права передавать в качестве параметров объекты любых типов. Тут кто-то заявил, что NullPointerException - это bane Ява - программирования. Он на 3-5% прав, поскольку такие ошибки иногда бывают во врема билдов, когда какие-то модули не срастаются. С BadCastException мне почему-то не приходилось сталкиваться. Ни разу. dwl Сергей ИльичКстати, давно хотел спросить - спецификации исключений (throw) являются в С++ частью сигнатуры функции или не являются? Это что каверзный вопрос из разряда - АГА ОН НЕ ЗНАЕТ С++ настолько чтобы о нем судить? Да я и не говорил что я знаю С++ хорошо. Мне приятно перечитывать книги по нему(некоторые) и узнавать каждый раз что-то новое. Вообще это твой стиль - сыпать какими-то терминами типа "мультиметод, функтор, абстрактная фабрика, политика etc" и чего-то ждать. Я лишь интересовался безопасностью типов в коллекции callback функций. надо ли каждый вызов метода из этой коллекции оборачивать в Код: plaintext 1. 2. 3. 4. 5. чтобы не словить unexpected() dwl Сергей ИльичЯ просто знаю, что когда я пишу на Джаве, я встречаю намного меньше препятствий. Это бессмыслено обсуждать. Я уже говорил, что у каждого специалиста в своей области выработаны свои привычки и технологии. Это как например взять посадить программиста MSSQL на ORACLE. ОН достаточно скоро его обругает и скажет что ORACLE плохая система. И это будет НЕВЕРНО. Ситуация обратная. Полгода назад перешел на Яву, и до сих пор не могу привыкнуть к отсутствию непонятных глюков и к удобочитаемым сообщениям компилятора. И что программа ведет себя сразу так, как я задумывал. dwl Сергей ИльичПотому что исключения в С++ сделаны через жопу. Опять обощения можно по конкретней? Посмотри, как экзепшены сделаны в Java и сравни. Там есть checked и uncheсked исключения. Про finally я вообще не вижу смысла с тобой разговаривать: у тебя наверное один критерий - если Строуструп сказал, что finally - это зло, значит это зло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2005, 13:37 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Сергей ИльичКак в Яве, так и в С++ надо отдавать предпочтение долгоживущим объектам. Не во всех ситуациях. Например, локальные переменные. Все зависит от контекста. Не стоит думать, что во всех случаях можно обойтись только стековым размещением или только "кучным". Каждому свое. Сергей ИльичМеня интересует не факт вызова деструкторов, а факт вызова ::operator delete(...) под адрес, который вернул ::operator new(...), когда его попросили выделить память для помещения туда Three1 / Three2. Освобождение памяти в этом случае гарантируется. Оно не гарантируется только в двух случаях: 1) буфирезированные оператор размещения new (buf) A; 2) и если перекрыт оператор new, но не перекрыт оператор delete Во всех остальных случаях происходит освобождение памяти. Сергей Ильичstd::vector<INotificationHandler*> в сто раз гибче и понятней. Это ваше ИМХО. Речь идет о том, что в этом случае идет проверка типов на этапе выполнения, а не на этапе компиляции. Например вы захотите присвоит в этот контейнер объект другого типа. ТО в этом случае будет либо неявное(если они родственники) либо явное преобразование типов. Которое не может быть выполнено на этапе компиляции. Просто посмотрите на generic programming как на еще один прием повторного использования кода. Однотипные дествия над типами объединяются в функции или структуры, которые связываются с конркетными типами на этапе компиляции. Проверка производится компилятором. Это лучше чем преобразование типов. Сергей ИльичЛюбой класс в Яве наследует от Object метод equals, который можно перегрузить. Ты про это? да я про это. Допустим у тебя есть контейнер или просто два объекта которые по сути являются ну например пользовательскими обработчиками событий. Тебе надо их сравнить. Например, мы имеем некоторый список "обработчиков", которые заполняет программа для этого объекта, чтобы потом их вызвать. Чуть позже один из обработчиков надо удалить. Сергей ИльичЭто я вообще не понял. Ты видишь сложности там, где их нет.Я не говорю что это сложно. Я лишь хотел показать, что имея тип Функтор, в котором реализованы все необходимые действия, нам не надо его переписывать для разных типов функций, которых он оборачивает. нам не надо копировать код. И нам не надо прибегать к преобразованиям типов или другим седствам познего связывания. Сергей ИльичПо - моему реалистичное отношение к С++ это "Самый распространенный компилируемый язык программирования, доступный на Win и UNIX, доступно много библиотек из первоисточника, требует колоссальных усилий для написания даже простой программы, но выбора зачастую нет." я так не считаю. Хотя это канеш мое ИМХО. Здесь все упирается в наличие той или иной билиотеки для написания какой-то конркетной задачи. Например, мне жутко не нравится подход MFC. Поэтому приходилось юзать что-то другое. Наличие готовых решений - это сильное преимущество и большой плюс в выборе какого-либо инструмента разработки. Сергей ИльичА public API классов не дает права передавать в качестве параметров объекты любых типов.Еще раз хочу проевить свою твердолобость. Все дело в повторном использовании кода. Допустим нам надо написать некий класс, например, контейнер. У него есть ряд стандартных действий по динамическому распределению объектов и управлению доступом к ним. И я, например, хочу, чтобы мне не приходилось писать каждый раз код этого класса для разных типов хранимых объектов. Если я не использую шаблоны, то мне придется указатель на некий базовый объект, и путем преобразования типов получать доступ к его членам или методам. В случае шаблонов не надо ни копировать исходники, не нужны преобразования типов. Я просто подставляю нужный тип и все. Это просто безопасное повторное использование кода. Сергей ИльичЯ лишь интересовался безопасностью типов в коллекции callback функций. надо ли каждый вызов метода из этой коллекции оборачивать в нет не надо. Насчет терминов. Извини что не дал определения этих понятий. Просто я подумал, что человек, который прочел книгу Александреску и сказал что она фуфло знает смысл этих терминов. Именно в ней дается определение этих понятий, а точнее приемов программирования. И упомянул я их только в качестве вопроса тебе, как прочитавшему книгу Александреску. Сергей ИльичСитуация обратная. Полгода назад перешел на Яву, и до сих пор не могу привыкнуть к отсутствию непонятных глюков и к удобочитаемым сообщениям компилятора. И что программа ведет себя сразу так, как я задумывал. ну и отлично. У меня есть друг, который разработал свою систему распознования почерка на С++. Сейчас ее собирается продавать. У него тоже все работает без проблем. Никаких утечек памяти. А у него там очень большие структуры данных, которые часто реорганизуются тем или иным способом. Ничего не имею против Явы, о чем постоянно говорил в постах. Я лишь ПОПЫТАЛСЯ упомянуть о разнице в приемах разработки generic programming и ООП (т.к. вопрос изначально был почти именно про это). О том, что дает первое. И что оптимально использовать их вместе. И я не являюсь единственным аппологетом того, что эта технология имеет право на жизнь. Это стали понимать и разработчики компиляторов. И шаблоны стали появляться и в Яве и в C#. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2005, 17:01 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Сергей Ильич Как в Яве, так и в С++ надо отдавать предпочтение долгоживущим объектам. Неплохо использовать Singleton, или какой-нибудь пул объектов. А создать долгоживущий объект в стеке несколько проблематично. Вообще это твой стиль - сыпать какими-то терминами типа "мультиметод, функтор, абстрактная фабрика, политика etc" почитав ваши диалоги у меня большие сомнения в том что вы писали что-то серьезнее чем Hello world на С++. Извините, вы просто не владеете предметом. Мне тоже было не легко при переходе от структурного к ООП программирования, затем к generic. Поймите - это просто новый уровень мышления. Да, книжки для законченных идиотов С++ за 21 день не хватит. Не ошибусь, если скажу что 90% софта на вашем компьютере написано на С++. Все серьезные и большие компании коробочный софт делают только на С++. Купить что-то на Java приактически не возможно - потому как почти всегда требуется тех саппорт. Производительность вообще смех какой-то. Поставил Office написанный на Java - Copy/Paste из IE в редактор на P4 заняло 2 минуты ! Сергей Ильич Вот так вот. Создаю какой-то долгоживущий (и наверное соответственно большой) объект в куче, у которого есть поля из бустовых классов, а какое-то бустовое поле возьми да и кинь екзепшен во время конструирования. вы о чем ? что такое конструирование ? Сергей Ильич Ты видел, сколько памяти может вытечь даже очень маленькими и редкими капельками, если работа идет десятками часов? мы занимаемся моделирование и расчеты ведутся сутками с трехмерными кубами со стороной 10000 элементов. Даже и мысли не было сделать на JAva потому как производительность будет мама не горюй. dwl не вижу смысла размазывать реализацию ОДНОГО класса по нескольким CPP модулям - это плохой стиль. иногда бывает нужно. Когда реализация класса превышает 1-1.5 тыс. строк - стараюсь разделить функциональность. Скажем класс основного приложения у меня в текущем проекте превышает 10 тыс. строк. Сергей ИльичПро большую безопасность не надо - уж сколько слез я вижу в нашей столовой "Ой, у нас Protection fault выскакивает раз в 4 часа, и повторить условия мы не можем". Хотя, нам наверное dwl'а не хватает, чтобы он пришел и все разрулил. вам просто нужно найти профессионалов. ---А у нас многие ребята - выпускники ИТМО и СПбГУ. дилетанты бывают в любой среде Сергей Ильич А во-вторых, если какой-то человек может видеть многомерную структуру ньюансов С++, но при этом проект-лидер и коллеги по бригаде никак не могут достучаться до внутреннего мира такого человека, это очень плохо. для этого есть корпоративное полиси написания кода Сергей ИльичПотому что исключения в С++ сделаны через жопу. может не умеете ими пользоваться ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2005, 18:23 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
dwl Сергей ИльичМеня интересует не факт вызова деструкторов, а факт вызова ::operator delete(...) под адрес, который вернул ::operator new(...), когда его попросили выделить память для помещения туда Three1 / Three2. Освобождение памяти в этом случае гарантируется. Оно не гарантируется только в двух случаях: 1) буфирезированные оператор размещения new (buf) A; 2) и если перекрыт оператор new, но не перекрыт оператор delete Во всех остальных случаях происходит освобождение памяти. Кем гарантируется ? Стандартом или конкретным компилятором ? dwl Сергей Ильичstd::vector<INotificationHandler*> в сто раз гибче и понятней. Это ваше ИМХО. Речь идет о том, что в этом случае идет проверка типов на этапе выполнения, а не на этапе компиляции. Например вы захотите присвоит в этот контейнер объект другого типа. ТО в этом случае будет либо неявное(если они родственники) либо явное преобразование типов. Которое не может быть выполнено на этапе компиляции. Никто не сможет поместить в этот контейнер объект другого типа. Для этого понадобился бы С-Style cast или reinterpret_cast. А против лома не приема. dwl Просто посмотрите на generic programming как на еще один прием повторного использования кода. Однотипные дествия над типами объединяются в функции или структуры, которые связываются с конркетными типами на этапе компиляции. Проверка производится компилятором. Это лучше чем преобразование типов. Нету никакого generic programming. Есть functional programming и lambda + high order functions. И есть нечто бледное, чего пытаются изобразить в С++. dwl Сергей ИльичЛюбой класс в Яве наследует от Object метод equals, который можно перегрузить. Ты про это? да я про это. Допустим у тебя есть контейнер или просто два объекта которые по сути являются ну например пользовательскими обработчиками событий. Тебе надо их сравнить. Например, мы имеем некоторый список "обработчиков", которые заполняет программа для этого объекта, чтобы потом их вызвать. Чуть позже один из обработчиков надо удалить. По умолчанию каждый объект к Яве равен только самому себе (дефолтовая реализация eqals в java.lang.Object сравнивает указатели на объекты). Можно его перегрузить, чтобы сравнивать тождество содержимого объектов. Но в объектах - хандлерах лучше этот метод не трогать. dwl Сергей ИльичЭто я вообще не понял. Ты видишь сложности там, где их нет. Я не говорю что это сложно. Я лишь хотел показать, что имея тип Функтор, в котором реализованы все необходимые действия, нам не надо его переписывать для разных типов функций, которых он оборачивает. нам не надо копировать код. И нам не надо прибегать к преобразованиям типов или другим седствам познего связывания. Статический метод Collections.sort(...) может отсортировать любую последовательность содержащую объекты любых типов. И там не надо ничего переписывать. Не вижу никаких проблем с поздним связыванием (он делает downcasting к типу Comparable). В любом случае, пространства для нетривиального бага тут нет. В конце концов, operator< тоже можно неправильно перегрузить. dwl Сергей ИльичА public API классов не дает права передавать в качестве параметров объекты любых типов. Еще раз хочу проевить свою твердолобость. Все дело в повторном использовании кода. Допустим нам надо написать некий класс, например, контейнер. У него есть ряд стандартных действий по динамическому распределению объектов и управлению доступом к ним. И я, например, хочу, чтобы мне не приходилось писать каждый раз код этого класса для разных типов хранимых объектов. Если я не использую шаблоны, то мне придется указатель на некий базовый объект, и путем преобразования типов получать доступ к его членам или методам. В случае шаблонов не надо ни копировать исходники, не нужны преобразования типов. Я просто подставляю нужный тип и все. Это просто безопасное повторное использование кода. какие функциональные кирпичи программы кроме контейнеров ты можешь себе представить? В конце концов, каждый кандидат на роль содержимого контейнера STL должен быть assignable и copy constructable. Если подумать, на эти обязательства довольно сложно подписаться в случае нетривиальных объектов. А указатели всегда assignable и copy constructable (кроме auto_ptr конечно). dwl Сергей ИльичЯ лишь интересовался безопасностью типов в коллекции callback функций. надо ли каждый вызов метода из этой коллекции оборачивать в нет не надо. Насчет терминов. Извини что не дал определения этих понятий. Просто я подумал, что человек, который прочел книгу Александреску и сказал что она фуфло знает смысл этих терминов. Именно в ней дается определение этих понятий, а точнее приемов программирования. И упомянул я их только в качестве вопроса тебе, как прочитавшему книгу Александреску. Почему не надо? кто-то заявил, что он кидает только SomeException (throw SomeException), он вызал мой метод, мой метод вызвал какой-то калбэк из внутренней коллекции. А этот калбэк кинул SomeOtherException. По идее, соглашение о кидании только SomeException нарушено, поэтому должен быть вызван unexpected(), который по умолчанию сводится к terminate(). Я знаю значение этих терминов, но они были упомянуты явно не к месту. Паттерны проектирования типа абстрактной фабрики лучше раскрыты в других книжках. К тому же абстрактную фабрику в Яве можно сделать намного лучше - например чтобы она выбирала нужный DAO плугин к базе данных, основываясь только на конфиге. Причем, при написании нового плугина не надо было добавлять ни строчки ни эту фабрику ни вообще в основной код. Мультиметоды - это методы, поведение которых зависит не только от динамического типа объекта - сервера, но и от динамического типа объекта - клиента, в отличие от простых виртуальных функций, поведение которых зависит только от динамического типа объекта - сервера. Наверное, с помошью шаблонов можно проэмулировать наличие таких вещей в С++, но тогда придется отказаться от раздельной компиляции. Ну не собрать шаблонный класс в *.obj. Никак. Я говорил об этом. В ответ мне было заявлено, что я абсолютно не понял книгу Александреску. Тогда, очевидно, я чего-то не понял. В этом случае мне нужно объяснение, как класс с мультиметодом можно поместить в *.obj. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 14:57 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
Cергей Ильич я прочел твои тут умные фразы ;) про джава и с ++ ;) или ты в практике ничем не сталкивался ;) или сталкивался кривыми программерами на с ++ согласис что с ++ намного быстрее работает ;) (имеется на виду написанные на с ++) а что то делать .. как ни как с ++ более близок системе самой ;) так что тут про функциональности не надо говорить .. просто это может быть не так легко будеть как ты думаеш. просто перетаскал с помощю мышки и готово ;) так скорое всего не будет .. но в умелых руках повер мне (или не повер - дело твое ;)) с с ++ сравнить джава даже не стоит ;) а то что думаеш прежде чем написать и упорно стоять на своем - хотя бы имей совесть работат с с ++ столько сколько работаеш с джава. освой как надо и потом сам посмотри ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 15:29 |
|
||
|
C++ & Java
|
|||
|---|---|---|---|
|
#18+
О, Лепрозорик! Привет, проказник! Lepsik Сергей Ильич Как в Яве, так и в С++ надо отдавать предпочтение долгоживущим объектам. Неплохо использовать Singleton, или какой-нибудь пул объектов. А создать долгоживущий объект в стеке несколько проблематично. Вообще это твой стиль - сыпать какими-то терминами типа "мультиметод, функтор, абстрактная фабрика, политика etc" почитав ваши диалоги у меня большие сомнения в том что вы писали что-то серьезнее чем Hello world на С++. Извините, вы просто не владеете предметом. Ну, пусть будет так. Устами дилетантов глаголет истина. Lepsik Не ошибусь, если скажу что 90% софта на вашем компьютере написано на С++. Мои рабочие тулзы - IDEA и Together - написаны на Java. Lepsik Производительность вообще смех какой-то. Поставил Office написанный на Java - Copy/Paste из IE в редактор на P4 заняло 2 минуты ! Навеяло тут ... Эдмон Ростан .. из Сирано де Бражерак Ваш нос... Hy, в общем... крупноват... Сирано. Да. Он крупней, чем красноречье ваше, А я бы о таком, заметьте, О выдающемся предмете Острот набрал бы целые тома, Меняя жесты и топа... Вот, например, из не особо острых -- Тон описательный -- так шутит новичок: Как называете вы этот полуостров, Который вырос между ваших щек? Развязный тон, каким острят друзья: Вам из стакана пить нельзя -- Побьет ваш нос посуду вашу! Позвольте подарить вам чашу? Или почтительно-умильный; Вы этой башнею фамильной Давно владеете? Наивный: С дальних мест Вы этот монумент везли для дам столичных? Любезный: Сударь любит птичек? Он приготовил им вместительный насест! Ехидный: Это что? Крючок для шляп? Удобный! Платить не надо в гардеробной! Тон нежный: Боже мой! От дождичка и ветра Вы заказали зонтичек ему? Тон удивленный: Извините, это -- Вам одному? Доброжелательный: В пылу житейских гроз, Фиаско потерпев в каком-нибудь вопросе, Вам нелегко повесить нос, Зато легко повеситься на носе! Язвительный, чуть в сторону и косо: Но, сударь, вам решительно везет: Не видя дальше собственного носа, Вы все же видите широкий горизонт! Практический: Советовать вам смею Для носа вашего устроить лотерею; Я вам скажу с открытою душой, Что получивший вещь такую Имел бы выигрыш большой, Имея радость небольшую. Вот так острить могли б вы наобум, Когда бы знания имели или ум. Lepsik Сергей Ильич Вот так вот. Создаю какой-то долгоживущий (и наверное соответственно большой) объект в куче, у которого есть поля из бустовых классов, а какое-то бустовое поле возьми да и кинь екзепшен во время конструирования. вы о чем ? что такое конструирование ? Чего - не скомпилировалась мысль в голове ? С чем поведешься, оттого и наберешься. Я вообще о работе конструктора (конструирование == работа конструктора). Понял? Lepsik Сергей Ильич Ты видел, сколько памяти может вытечь даже очень маленькими и редкими капельками, если работа идет десятками часов? мы занимаемся моделирование и расчеты ведутся сутками с трехмерными кубами со стороной 10000 элементов. Даже и мысли не было сделать на JAva потому как производительность будет мама не горюй. Когда я был на курсах по Джаве, мой руководитель мне дал задание - сделать два потока - один будет точечки на экран выводить, другой будет факториал считать. Мне приходилось замедлять цикл вычисления факториала, чтобы хотя бы 6-7 точечечек на экран успевали выскочить. Причем вычисление факториала было по рекурсивному алгоритму, и в качестве аргумента я подобрал такое число, чтобы если чуть больше - все вылетало с переполнением стека. Раньше классы BigDecimal и BigInteger были реализованы через native. в jre 1.3 их переписали на чистый java, и их скорость даже немного возросла. Игра chrome (3d fps с открытыми пространствами) написана на джава + native связка с Direct3d. Библиотека fftw (Fatest Furier Transform in the West) была написана вовсе даже не на c/С++, а на ML, функциональном языке. Lepsik ---А у нас многие ребята - выпускники ИТМО и СПбГУ. дилетанты бывают в любой среде Показал отделу кадров - вместе посмеялись. Они помнят, как по всему Питеру было не найти человека подходящего уровня. Искали год. А компания у нас большая. Специализация - IT. Видимо могучий Лепсик пишет вообше без ошибок. Lepsik Сергей ИльичПотому что исключения в С++ сделаны через жопу. может не умеете ими пользоваться ? В прошлый раз благодаря такому аргументу мы пришли к выводу, что чтобы пользоваться произведением бездушной системы документирования javadoc не нужно умение, в противоположность документации от Борланд. Видимо, Борланд очень много души вкладывает в свою документацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2005, 15:46 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=32851774&tid=2029679]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 378ms |

| 0 / 0 |
