egorychmayton,

я вот уже 8 страниц прочитал, и так и не понял в чём начальный поинт топика чувствуется, что парни недовольны, но вот чем, сформулировать у них толком не получается до сих пор.

к примеру, посмотрел свой самый толстый файл в проекте.
общее число строк - 1629,
строк кода - 1329,
пустых строк - 187,
комментариев - 113.
"паразитных" строк, с точки зрения автора - 27! о чём речь?
Еще раз объясняю главную тему - меня блевать тянет от оператора include. Нафига он компилятору, понятно, но нафига он человеку - не очень... Можно проиндексировать все файлы проекта и тягать нужные объявления без этого убогого оператора.

Алексей КmaytonРебята. Набивка, вёрстка - это всё RAD-s, maker, builders. И это к сабжу не имеет отношения! Да как сказать... Язык должен в первую очередь позволять концентрироваться на предметной области, а не заставлять постоянно думать о том, чтобы "не забыть там подправить", "не забыть тут добавить", и т. п. Зачем это надо? Или программисты С++ пишут сразу правильные программы, и им не приходится заниматься рефакторингом? Например, в C# перенос группы полей и методов в другой класс - это тупо копипаст куска текста без изменений. А вот в С++, благодаря его синтаксису, эта операция несколько сложнее.

ЗЫ: Пишу на C# и радуюсь, что больше не приходится сталкиваться с С++.
Вот, автор уже правильно ощутил нюансы Си++. Действительно, приходится очень много писать "не забыть бы тут добавить"... Прямо я вас понимаю!

XDiaBLoАлексей КЯзык должен в первую очередь позволять концентрироваться на предметной области, а не заставлять постоянно думать о том, чтобы "не забыть там подправить", "не забыть тут добавить", и т.

При таком раскладе, пусть топикстартер остаётся на 1С и концентрируется на предметной области.
Топикстартер всего лишь выразил свое недовольство Си++ и посчитал, что оператор include морально устарел.

XDiaBLo
А вам пора бы перейти на 1С.

Путешествие от Си++ в 1С и обратно в С#? ;-)

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

>> Бред. Это одна из основных причин отвратительной читаемости кода в Java. В результате этого требуется просматривать тысячи строк кода только для того, чтобы "по-быстрому" увидеть, что и как умеет этот класс. В результате "сворачивание кода" становится необходимой фичой, поскольку чёрт возьми таки позволяет увидеть суть без шелухи, интерфейс без реализации.
Проще настроить текстовый редактор для фильтрации заголовков, чтобы показывать только объявления, чем вколачивать одно и то же в два места - в объявление и реализацию.


>> Ещё и неграмотен. На Паскале можно не делать - впрочем, это будет стилистической ошибкой.
Мне это не столь важно

>> В угоду хорошему стилю. Это несколько затрудняет написание больших подпрограмм - что минус - но стимулирует "сначала думать, потом делать", что плюс. Особенно для современных программистов, думать не привыкших, привыкших сразу делать.

Чем в данном случае стиль хорош? Тем, что он для мазохистов?

MasterZiv
Так ладно, что предлагаете-то ? Конкретно и по пунктам. Как заменять будем
заголовочные файлы ?

Решение просто - проиндексировать библиотеки и файлы проекта и искать объявление нужного класса в том файле, где он описывается.

eee-pc

человек, ты не понимаешь сипп, а пытаешься спорить. никто не застявляет тебя отделять реализацию от описания. суть в том, чтобы отделить реализацию от интерфейса. понимаешь разницу? интерфейс - абстрактный класс, т.е. без реализации. он проще и УБОБНЕЙ ЧЕЛОВЕКУ для линковки. описания и реализация гораздо больше. тот же дотнет содержит множество интерфейсов и описаний и описания БОЛЬШЕ интерфейсов.

Да на здоровье. А почему я должен повторять описание интерфейса в реализации.
почему я просто не могу написать:
реализация класса такого то
метод1{}
метод2{} //без параметров
Пусть параметры подставляет из интерфейса!

eee-pc
нехер писать интерфейс не на дотнете..

То бишь ты считаешь, что на QT писать интерфейс - лажа?

eee-pcв Visuaal Studio (vax) есть нормальные инструменты для, например, для изменения описания фунции. изменяешь в спп и она изменяется в h. куда уж проще ?
То бишь язык без IDE мертв?

XDiaBLoeee-pc
- каждый язык для своих задач. например, писать ГУЙ на сипп не есть гут, в то время как писать большие проги (логику особенно) на не сипп есть еще больший не гут.
Тут основная проблема в том, что на С++ нету никакого ГУЯ :) А эти поделки, которые дают возможность таки делать ГУЙ на С++, они все не являются стандартом :(

QT - поделка по вашему?

XDiaBLoАлексей КXDiaBLoА в чём тогда собственно претензии?Да ни в чём. :-) Просто согласился с Fixin в том, что ручное описание метаданных - это плохо. Из-за того, что в программу добавляется некоторая избыточность.
Проблема высосана из пальца. Это просто мелкое неудобство для вас и Fixin, в принципе не составляющее проблемы.

не фига себе. Да это капитальное неудобство, особенно если классов много.
1. почему я должен следить за именами h-файлов.
2. почему я должен включать IFDEF в начало, придумывать идентификаторы.
3. Почему включать нужные h-файлы не может компилятор.

Все это бред! Компилятор уже может быть умнее. На дворе прошел 20 век, а С++ топчется уж не знаю в каких? 80-е? 90-е?

mayton
Здесь нужен экскурс в историю. Дело в том, что самые первые версии компилляторов действительно были машинно- а не человеко- ориентироваными. Это проявлялось во всём. Экономия памяти в именах переменных (исходник не прогружался в ОЗУ). Оверлейные буферы. Различные расширители верхней (hi), расширенной (extended) и еще x$й знает какой памяти. Катастрофическая нехватка оперативки и чудовищно медленный дисковый интерфейс (как вариант 5.25 дюймовая дискета и никакого HDD). И сделать #include <*> было нельзя. И сегодня, ты избалованный и изнеженный 2-4 ГБ оперативки и бесконечной страничной памятью не понимаешь программистов-семидесятников. Их работа была адской. Ресурны машины надо было ЭКОНОМИТЬ. А человеко-ресурсы нет. Человеков ведь всегда много. Вот такие вот пирожки. Поэтому тяжёлое наследие первых компилляторов несут в себе очень многие языки.

Нафига мне история сейчас? Включайте новые варианты, оставляя обратную совместимость. Так ты что же, батенька, согласен, что include - это устаревшая конструкция?

maytonFixinВсе это бред! Компилятор уже может быть умнее. На дворе прошел 20 век, а С++ топчется уж не знаю в каких? 80-е? 90-е?
Что вы предлагаете?

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

maytonFixinПисал уже выше - индексацию файлов используемых классов и подключение нужных для компиляции классов автоматом, без H-файлов.
Ну и что дальше? А КТО будет из списка поиндексированных выбирать нужную библиотеку (пространство имён (модуль)) ?

Ну Джава же выбирает.

Т.е. когда я пишу MyClass *myclass; то компилятор начинает искать MyClass во всех либах.
Если я пишу в начале:

Uses MyLib, YourLib;
MyClass *myclass;

То компилятор начинает искать описание myclass сначала в MyLib, затем в YourLib, затем везде.

Если найдено несколько MyClass, выдается ошибка - ambigous class names.

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

И вообще, чтобы что-то свое предлагать в области ЯП надо понимать все статьи на LtU включая слова "катамормизм" и "зависимые типы"

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

XDiaBLoFixin>> H-файлы - действительно, тяжкое наследие семидесятых.
Ну вот об этом я и хотел сказать... H-файлы морально устарели... А вы до сих пор жуете этот кактус и говорите - вкусно.
Да что вы к хидерам докопались? В С/С++ полно более важных проблем, на фоне которых, ваша проблема меркнет.

Я решаю проблемы в порядке очередности. Про другие проблемы не знаю, но хидеры меня бесят. Это отстой, для языка 21 века позор.