Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата KILLER @ 11.02.13, 11:20

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

Открой для себя паттерн Composite

Цитата KILLER @ 11.02.13, 11:20

Я просто затрудняюсь представить зачем мне сохранять объект куда то там, если он еще толком то создаться не успел...

А после работы конструктора он еще не успел создаться?

Цитата --Ins-- @ 11.02.13, 11:18

А мне архитектура VCL в целом нравится.

В целом да, неплохая архитектура. Но ListView, TreeView, Grid - это просто адовый ад. Заэкстендить нормально практически нереально. Проще написать с нуля.

Вот у VirtualTreeView - правильная архитектура. Но там исходник - 1 мегабайт и методов еще больше, чем во всех названных мной контролах И не факт, что если разделить это все на кучу маленьких файлов, чисто для простоты ориентирования в интерфейсе класса - было бы лучше. Поэтому аутлайн рулит.

Цитата [S]mike @ 11.02.13, 11:23

И не факт, что если разделить это все на кучу маленьких файлов, чисто для простоты ориентирования в интерфейсе класса - было бы лучше.

Лучше большие классы разбивать на несколько унаследованных друг от друга. Хотя это не универсальный совет, нужно смотреть в каком случае меньшим злом будет плодить классы, а в каком - не плодить но перегружать единственный

Цитата --Ins-- @ 11.02.13, 11:22

Открой для себя паттерн Composite

И? Что я в нем должен увидеть такого, что меня бы сразу осенило, о да писать логику в конструкторах это круто...

Цитата --Ins-- @ 11.02.13, 11:22

А после работы конструктора он еще не успел создаться?

Ну в делфях хз, в С++ он уже создался, но я то там и написал : "если он еще толком то создаться не успел..." ...

Цитата [S]mike @ 11.02.13, 09:49

1) Тупая, неочевидная, _медленная_ система сборки.

Медленная там компиляция, да.

Цитата

2) Меньше возможностей для рефакторинга и анализа кода, поиска ликов, профайлинга.

Зависит от сред разработки и набора используемых утилит. С рефакторингом вполне справляется IDE вроде NetBeans/Eclipse и пр. Поиск ликов удобен и надежен - valgrind. Впрочем, ликов при правильном проектировании вообще не будет, т.к. язык заставляет об этом думать. Для профайлинга тоже утилит хватает - gprof, например.

Цитата

ООП это вообще отдельная песня.

Подробнее, пожалуйста.

Цитата

Нету пакетов

В яве вон не хватает их. Модули вводят

Цитата

ад с отдельным объявлением класса и его реализации.

Это, наоборот, очень удобно. Можете этого не делать и писать как в Яве(правда время компиляции от этого пострадает).

Цитата

Избыточный синтаксис.

В яве его не меньше

Цитата

4) Плюсы для Андроида - не "нативно". Все заточено под Джаву. Начиная от отладки и заканчивая всякими дополнительными средствами DDMS.
5) Android поддерживает не все библиотеки, облегчающие жизнь разработчику на плюсах. Тот же BOOST, например, не поддерживается.

Это уже другой разговор.

Цитата KILLER @ 11.02.13, 11:29

И? Что я в нем должен увидеть такого, что меня бы сразу осенило, о да писать логику в конструкторах это круто...

То, что существуют агрегированные и композитные объекты, которые не имеют смысла вне своего контейнера

Цитата KILLER @ 11.02.13, 11:29

Ну в делфях хз, в С++ он уже создался, но я то там и написал : "если он еще толком то создаться не успел..." ...

Расшифруй слово "толком" В дельфях после работы конструктора объект создан полностью, без всяких "толком"

--Ins--, не хочешь ответить на мои сообщения?

Цитата D_KEY @ 11.02.13, 11:31

--Ins--, не хочешь ответить на мои сообщения?

Не знаю. На какие? Я веду беседу с тремя как минимум оппонентами и так

Цитата [S]mike @ 11.02.13, 10:52

Ну я не извращенец, чтобы торчать от такого кода:

    std::vector<std::vector<RESULT> >::iterator ext_iterator;
    std::vector<RESULT>::iterator int_iterator;
    std::vector<std::vector<RESULT> > ext = ...;
 
    for(ext_iterator = ext.begin(); ext_iterator!=ext.end(); ++ext_iterator) {
        for(int_iterator = ext_iterator->begin(); int_iterator!=ext_iterator->end(); ++int_iterator) {
...

for(auto & ext_val : ext) {
    for(auto int_val : ext_val) {
...

Цитата D_KEY @ 11.02.13, 11:31

С рефакторингом вполне справляется IDE вроде NetBeans/Eclipse и пр.

Возможностей рефакторинга управляемого кода всяко больше

Цитата D_KEY @ 11.02.13, 11:31

Поиск ликов удобен и надежен - valgrind. Впрочем, ликов при правильном проектировании вообще не будет, т.к. язык заставляет об этом думать. Для профайлинга тоже утилит хватает - gprof, например.

Еще раз - речь я веду об Андроиде. Под Винду/Линукс я бы на плюсах, возможно, и написал бы что-то.

Цитата D_KEY @ 11.02.13, 11:31

Это, наоборот, очень удобно.

Цитата D_KEY @ 11.02.13, 11:31

В яве его не меньше

Ну я тут уже все свои аргументы по этому поводу выложил, копировать не буду

Сообщение отредактировано: [S]mike - 11.02.13, 11:38

Цитата --Ins-- @ 11.02.13, 11:22

А после работы конструктора он еще не успел создаться?

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

причин насколько я понял две
первая: если в конструкторе возникнет исключение, то деструктор НЕ будет вызван. нужно будет отдельно файнализировать частично сконструированный объект. это сподвигает народ писать как можно более простые конструкторы, в которых не может быть исключений.
вторая: в плюсах конструкторы не полиморфные и _вызов любого метода из конструктора НЕ полиморфный_. это тоже ограничивает полет фантазий.

Добавлено 11.02.13, 11:40
справедливости ради надо сказать, что массовое применение смартпоитеров первую проблему решает на корню.

--Ins--, ответь вот на это, например:

Цитата D_KEY @ 09.02.13, 22:04

Цитата --Ins-- @ 09.02.13, 18:26

Цитата D_KEY @ 09.02.13, 16:42

Не понятно, зачем разделять пользовательские типы на ссылочные и значений.

А мне непонятно зачем подменять понятие объекта и класса, и зачем передавать объекты по значению.

Никто понятий не подменяет. class в С++ может объевлять не только класс иерархии наследования. Но позволяет делать и это. Потому С++ и является языком с поддержкой ООП, но не ОО-языком. Я не понимаю твоего вопроса. Если не надо передавать - не передавай. В чем трудность?
Как, кстати, мне в Delphi изменить работу этих самых неявных ссылок на объекты? Язык же нативный и без сборки мусора... Вот в С++:

// сырой указатель
typedef my_type * my_type_ptr;
//  указатель, уникально владеющий объектом
typedef unique_ptr<my_type> my_type_unique;
// подсчет ссылок
typedef shared_ptr<my_type> my_type_shared;
 
// так же могут быть другие "указатели",
// для размещения в shared memory, например
// или там от какой-нибудь реализации GC
// ...

И если очень хочется, ты можешь выбрать один из видов указателей, сделать удобный typedef и получить такое же поведение, как в Delphi и даже немножко больше(т.к. сможешь менять вид указателя).

Цитата

Нисколько не удивляюсь что от этой тенденции благоразумно уходят со временем, и не только в Delphi

Какой тенденции?

Добавлено 09.02.13, 22:18
И на всякий случай скажу, что вышеприведенные typedef'ы и указатели будут одинаковы для любых типов.

Цитата D_KEY @ 11.02.13, 11:37

for(auto & ext_val : ext) {
    for(auto int_val : ext_val) {
...

Так это же только в C++11 появилось?

Цитата D_KEY @ 11.02.13, 11:40

Никто понятий не подменяет. class в С++ может объевлять не только класс иерархии наследования. Но позволяет делать и это. Потому С++ и является языком с поддержкой ООП, но не ОО-языком. Я не понимаю твоего вопроса. Если не надо передавать - не передавай. В чем трудность?

Подменяете. Никто не запрещал сделать объект с точки зрения ООП отдельным типом и не перемешивать все в кучу

Цитата D_KEY @ 11.02.13, 11:40

И если очень хочется, ты можешь выбрать один из видов указателей, сделать удобный typedef и получить такое же поведение, как в Delphi и даже немножко больше(т.к. сможешь менять вид указателя).

В контексте сказанного выше - мешать то никто не мешает, кроме того, что понятия смешаны

Цитата D_KEY @ 11.02.13, 11:40

Какой тенденции?

Расширения использования одновременно двух семантик

Цитата jack128 @ 11.02.13, 11:39

первая: если в конструкторе возникнет исключение, то деструктор НЕ будет вызван. нужно будет отдельно файнализировать частично сконструированный объект.

Нет, не нужно. Если, конечно, пишешь конструкторы нормально. Объект или будет или нет. Исключение в конструкторе может привести к вызову деструктора только в том случае, если конструктор вызывает другой конструктор(в С++11) перед тем, как возникло исключение. Поэтому, если очень хочется, можно добиться поведения, аналогичного делфийскому.

Цитата

конструкторы, в которых не может быть исключений.

Пишут и с исключениями

Цитата

вторая: в плюсах конструкторы не полиморфные и _вызов любого метода из конструктора НЕ полиморфный_. это тоже ограничивает полет фантазий.

Это правильное поведение, которое предотвращает ошибки. В Java, например, рекомендуют(по крайней мере Эккель в Философии) как раз избегать вызова виртуальных методов в конструкторах, т.к. это приводит к проблемам и вызову метода для несконстрированного объекта.

Сообщение отредактировано: D_KEY - 11.02.13, 11:47