powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Морально устаревшие элементы языков высокого уровня
25 сообщений из 355, страница 4 из 15
Морально устаревшие элементы языков высокого уровня
    #35981508
MasterZiv
Ну, паскаль и не только в этом плане отстаёт. Да он вообще сдохнет
совсем скоро, и туда ему и дорога.

Он уже давно умер аж 19 августа 1662 года
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981511
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Боже ш ты мой, ну что за косность. Ну сгенирируйте H-файл (интерфейс) на
> основе реализации, если это надо для командной работы. А если не надо,
> нафига нужен этот H-файл?

Не всё, что есть в реализации, должно быть в интерфейсе. И отвечает
за этот "отсвет" разработчик. Автоматом можно сделать разве что
заготовку, которую он потом проверит и выкинет ненужное.

Ладно, сдаётся мне, что тема создана только для чтобы пофлеймить.

Рассмотрим детально предложения аффтора. Вот устаревшие конструкты языков:

Объявление библиотек -- во многих языках программирования уже не
обязательно нужно указывать библиотеки. Например, в тех же С/С++ можно
подключать библиотеки автоматом. В Java то же самое, по сути там избавились
от этого пункта путём избавления от библиотек. Но тем не менее в очень
немногих языках удалось избавиться ПОЛНОСТЬЮ от определения в явном
виде того контекста, в котором приложение компилируется, собирается и работает.
Всё же он остаётся. При этом чем мощнее язык и его стандартная библиотека,
тем проще работать только в пределах стандартного окружения и не добавлять
туда ничего больше. Но, ещё раз, полностью от этого избавиться вряд ли удастся.


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


... должна ли подключаться библиотека. В любом случае имя класса уникально.
-- да не уникально имя класса или других объектов. Программисту удобно
использовать короткие имена-алиасы, ссылаясь на заранее определённый контекст,
в котором пишется программа. именно поэтому нет полного имени класса и оно
неуникально. поэтому "определять библиотеки автоматом, по составу классов"
невозможно, потому что неудобно. В смысле - возможно, но никто так не делает.
Ты хоть сейчас в Java можешь так делать. При чём с рождения Java. Но не будешь,
потому что неудобно. И, кстати, в Java using НЕ ПОДКЛЮЧАЕТ библиотеку. Он
только вводит в обрасти определения твоей программы алиасы для классов. Ты
можешь это не делать, и не надо будет писать using.


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


Объявление интерфейса вместе с реализацией -- не понятно, за что ратует
автор. За слияние реализации с интерфейсов, или наоборот, за разделение. Но
видимо всё-таки за слияние. Так в чём проблема ? В Java - есть (и по-другому
нельзя). В C/C++ - можно так, можно так, пиши как хочешь. В Паскале - то же
самое. Вообще, классический паскаль в один листинг должен был запихнут.
Там вообще модулей не было ! Ну и на последок надо заметить, что обычно
программист СНАЧАЛА пишет объявление и интерфейс модуля, а потом -- её
реализацию.


Объявление переменных "В этом плане отстает только Паскаль." -- Да нет,
все нединамически типизируемые языки отстают. Ну или скажем так - нединамические
и не статические с выводимыми типами переменных. Но скоро тут будет счастье --
в С++ добавят auto, паскаль сдохнет, про него уже сказали, и вообще динамически
типизируемые языки будут всё более популярными. С# с CLR - ом только чего
стоят. Они конечно не совсем динамические, но там всё есть объект, а это почти
то же самое.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981513
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixin wrote:

> Буквоедство detected. Речь шла о сборке h-файлов,

Я не понимаю, как это. сборка h-файлов.

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

Так не нравится - не используй, никто не заставляет. Даже в С.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981521
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixin wrote:

> Везде, а что проблема составить список классов? Время поиска -
> 0.00000001 секунда.

Вот сначала ты должен определить, где это ВЕЗДЕ. Причём в любом
языке, в любой системе программирования. Без этого контекста
существуют либо очень примитивные и нерасширяемые языки, типа
бейсика (не VisualBasic, а обычного бейсика) или ассемблера,
либо очень мощные и совершенные языки. Но в любом случае хотя бы
спецификацией языка этот контекст задаётся.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981523
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixin wrote:
> Пардон, я где то писал о *ПОЛНОМ* имени класса? Что за приписывания? Я
> говорил об *ИМЕНИ* класса. Оно тоже может быть уникальным!

Я уже достаточно понаписал про это, ты почитай - поймёшь может быть.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981593
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Fixin wrote:

> Слив засчитан. Моя тема посвящена не эмоциям, а лишнему тексту, который
> должен набирать человек, хотя вместо него это может и должен делать
> компилятор.
Да не может он делать, в том -то и фигня вся. Может, если только
каждому классу дать глобально уникальное имя. Ну, например, GUID
подойдёт. Ты будешь писать такие программы ? Думаю, не будешь.
Вот затем и нужны заголовки, CLASSPATH-ы и т.п.



Главную мысль ты не уловил, зациклился на неймспейсах, - если я хочу создать экземпляр класса MyLib.MyClsass, нафига мне вставлять в код #include <mylib\myclass>, это компилятор должен сделать сам.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981595
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Fixin wrote:

> Да вы што. H-файлы тоже нужны для командной разработки? Без них ну никак
> в командной разработке, да? Давайте поговорим про H-файлы.
В общем-то, именно так. Никуда без них.


Да вы что, не можете себе представить С++ без H-файлов? даю наводку - вы пишете имя файла, а компилятор сам подключает нужный h-файл. Возможно, если я вам скажу что С++ может быть без инклюдов, вам проще будет понять идею?
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981599
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Так не нравится - не используй, никто не заставляет. Даже в С.

Я и не использую, но по ходу, выбора нет. Мэйнстрим глубоко завяз в морально устаревшем С++.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981602
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv

Вот сначала ты должен определить, где это ВЕЗДЕ. Причём в любом
языке, в любой системе программирования. Без этого контекста
существуют либо очень примитивные и нерасширяемые языки, типа
бейсика (не VisualBasic, а обычного бейсика) или ассемблера,
либо очень мощные и совершенные языки. Но в любом случае хотя бы
спецификацией языка этот контекст задаётся.


Я тебе уже объяснил, где это везде.
1. Библиотеки ядра.
2. Дополнительные библиотеки, указанные в настройках проекта.
3. Файлы классов проекта.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981606
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пойду по пунктам:

>> Объявление библиотек -- во многих языках программирования уже не
обязательно нужно указывать библиотеки. Например, в тех же С/С++ можно
подключать библиотеки автоматом. В Java то же самое, по сути там избавились
от этого пункта путём избавления от библиотек. Но тем не менее в очень
немногих языках удалось избавиться ПОЛНОСТЬЮ от определения в явном
виде того контекста, в котором приложение компилируется, собирается и работает.
Всё же он остаётся. При этом чем мощнее язык и его стандартная библиотека,
тем проще работать только в пределах стандартного окружения и не добавлять
туда ничего больше. Но, ещё раз, полностью от этого избавиться вряд ли удастся.

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

>>Объявление структуры объектов -- Ну, без этого вообще никуда. От этого
не уйти. Если есть объект, его структура должна быть где-то описана. Неописывать
можно только автоматически саморасширяемые объекты, а таких не во многих языках
можно найти.

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


>> .. должна ли подключаться библиотека. В любом случае имя класса уникально.
-- да не уникально имя класса или других объектов. Программисту удобно
использовать короткие имена-алиасы, ссылаясь на заранее определённый контекст,
в котором пишется программа. именно поэтому нет полного имени класса и оно
неуникально. поэтому "определять библиотеки автоматом, по составу классов"
невозможно, потому что неудобно. В смысле - возможно, но никто так не делает.
Ты хоть сейчас в Java можешь так делать. При чём с рождения Java. Но не будешь,
потому что неудобно. И, кстати, в Java using НЕ ПОДКЛЮЧАЕТ библиотеку. Он
только вводит в обрасти определения твоей программы алиасы для классов. Ты
можешь это не делать, и не надо будет писать using.

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

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

Я вообщето преимущественно вел речь об избавлении от include-файлов, смысла этого поста не понял.


>> Объявление интерфейса вместе с реализацией -- не понятно, за что ратует
автор. За слияние реализации с интерфейсов, или наоборот, за разделение. Но
видимо всё-таки за слияние. Так в чём проблема ? В Java - есть (и по-другому
нельзя). В C/C++ - можно так, можно так, пиши как хочешь. В Паскале - то же
самое. Вообще, классический паскаль в один листинг должен был запихнут.
Там вообще модулей не было ! Ну и на последок надо заметить, что обычно
программист СНАЧАЛА пишет объявление и интерфейс модуля, а потом -- её
реализацию.

В С++ - смешно, да можно, но зато потом не используешь такой модуль в проекте.

>> Объявление переменных "В этом плане отстает только Паскаль." -- Да нет,
все нединамически типизируемые языки отстают. Ну или скажем так - нединамические
и не статические с выводимыми типами переменных. Но скоро тут будет счастье --
в С++ добавят auto, паскаль сдохнет, про него уже сказали, и вообще динамически
типизируемые языки будут всё более популярными. С# с CLR - ом только чего
стоят. Они конечно не совсем динамические, но там всё есть объект, а это почти
то же самое.

Я вел речь не о динамически определяемых типах, а о объявлении переменных в любом месте модуля, будьте внимательнее.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981618
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
XDiaBLoНе мусорный, после того как класс написан, достаточно при использовании смотреть в .h-файл, чтобы узнать интерфейс. Это очень удобно.Баян.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981629
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FixinЕсли надо, можно уточнить, о какой библиотеке идет речь, но не писать полный путь.
Но если я точно знаю, что мое имя класса уникально, я хочу его получить по этому имени, без лишних телодвижений. Понятна мысль?Спасибо, ненадо. Какой-то идиот уже реализовал в COM только глобальную прозрачность расположения классов. Теперь никто не знает что с ней делать.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981670
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КFixinЕсли надо, можно уточнить, о какой библиотеке идет речь, но не писать полный путь.
Но если я точно знаю, что мое имя класса уникально, я хочу его получить по этому имени, без лишних телодвижений. Понятна мысль?Спасибо, ненадо. Какой-то идиот уже реализовал в COM только глобальную прозрачность расположения классов. Теперь никто не знает что с ней делать.

ответьте пожалуйста конкретно, а не со ссылкой на COM, чем будет мешать подобное разыменование. Все равно вы используете несколько областей и имена могут пересекаться.
В случае пересечения имен можно выдавать ошибку типа ambigous names of classes. давайте без "идиотов" а по существу.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981680
eee-pc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
headers позволяют разделять реализацию и интерфейс. вы можете подключать реализацию интерфейса из другой либы.

но делать жесткую привязку (как в ява) ТУПО !!! ибо это ограничивает возможности, и добавляет тупости коду.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981728
Fixin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eee-pcheaders позволяют разделять реализацию и интерфейс. вы можете подключать реализацию интерфейса из другой либы.

но делать жесткую привязку (как в ява) ТУПО !!! ибо это ограничивает возможности, и добавляет тупости коду.

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

То бишь С++ написан для извращенцев, а не нормальных людей. В норме либа должна быть одна, а если вам хочется разных, наберите нужный код, понятно? Т.е. нормой считается когда либа и интерфейс одинаковые, нужно специфицировать, когда они разные. А С++ считает нормой патологию. Неудивительно, он написан для компиляторов, а не людей.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981743
eee-pc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixineee-pcheaders позволяют разделять реализацию и интерфейс. вы можете подключать реализацию интерфейса из другой либы.

но делать жесткую привязку (как в ява) ТУПО !!! ибо это ограничивает возможности, и добавляет тупости коду.

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

То бишь С++ написан для извращенцев, а не нормальных людей. В норме либа должна быть одна, а если вам хочется разных, наберите нужный код, понятно? Т.е. нормой считается когда либа и интерфейс одинаковые, нужно специфицировать, когда они разные. А С++ считает нормой патологию. Неудивительно, он написан для компиляторов, а не людей.

ну да. только heander + lib == библиотека. вы путаете понятия.
Сипп написан для нормальных людей, а не для лентяев, у когорых замедление в сотню раз считается нормальным. и не путайте понятия. сипп в отношении интерфейсов НИЧЕМ не хуже той де явы или дотнета. и не надо путать интерфейсы и стандартные классы. я много работаю на сипп, работал много на яве и когда то на vb. IDE для сипп дают столь же ПРОСТОЕ подключение как и та же ява. только в яве куча непонятных закрутов, снижающих возможности и усложняющих понимание (например, один файл - один класс (не всегда, но в целом верно)).

к тому же та же ява: интерфейс и класс вам ПРИХОДИТЬСЯ дублировать.
и конечно же. НИКТО НЕ ЗАСТАВЛЯЕТ вам делать много файлов. вам нужен лишь ОДИН .C (.CPP), все остальные могут быть заголовками.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981745
eee-pc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
короче, как ни крути, но:
- с линковкой у сипп все в порядке (у противников этого пункта либо слабые знания и опыт на сипп либо руки кривые)
- скорость у сипп пока самая высокая (асм не смотрим) для большнства задач (например пролог или лисп проще и быстрей решают свои задачи)
- каждый язык для своих задач. например, писать ГУЙ на сипп не есть гут, в то время как писать большие проги (логику особенно) на не сипп есть еще больший не гут.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981772
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixin
1. Файл интерфейса можно получить автоматом, если надо, или в той же IDE посмотреть только заголовки функций, зачем требовать его обязательное наличие?

О каком файле интерфейса идёт речь? IDL что-ли?


2. Почему я должен писать IF DEFINE в каждом H-файле.

Не пиши. Используй директиву pragma. Или ты этими if проверяешь что-то другое? Тогда покажи код.


3. Зачем я должен следить за именами H-файлов?
4. Зачем мне вообще H-файлы, если найти нужное описание класса может и сам компилятор?

Управление -h файлами это в некотором роде контроль над scope vision для компиллера. Ты отделяешь, что ему надо видеть, а что нет. И элементарное управление пространством имён.


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

> Я тебе уже объяснил, где это везде.
> 1. Библиотеки ядра.
> 2. Дополнительные библиотеки, указанные в настройках проекта.
> 3. Файлы классов проекта.

Ну, так всё-таки указанные в настройках. А против чего ты возмущался ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981943
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixin wrote:
> Расскажите, как можно подключать библиотеки автоматом.

#pragma comment(library)

Если вы про
> линковку - то это другая песня. Я про include-файлы.

А при чём тут include-файлы, если ты о библиотеках ?
Никак это не связано.

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

А что такое описание структуры данных класса, как не его реализация ?
Я не понял, её богу.

> Если надо, можно уточнить, о какой библиотеке идет речь, но не писать
> полный путь.
> Но если я точно знаю, что мое имя класса уникально, я хочу его получить
> по этому имени, без лишних телодвижений. Понятна мысль?

Неа. Давай тогда в таком разрезе. Напиши, как это должно выглядеть.
В языке, в окружении. Представь, что ты пишешь часть стандарта.
И напиши. А мы посмотрим.

> В С++ - смешно, да можно, но зато потом не используешь такой модуль в
> проекте.

Да почему же ? Используй на здоровье.

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

Да я понял. Обобщил я.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981947
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton wrote:

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


Это немного неправильный экскурс в историю. Когда появились первые
языки программирования, дискет ещё даже в планах не было.
И появились языки программирования высокого уровня именно из-за того,
что нужно было экономить ресурсы именно в виде ЧЕЛОВЕКОВ-ПРОГРАММИСТОВ.
А иначе мы так бы в кодах и кодили.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981981
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fixinответьте пожалуйста конкретно, а не со ссылкой на COM, чем будет мешать подобное разыменование. Все равно вы используете несколько областей и имена могут пересекаться.
В случае пересечения имен можно выдавать ошибку типа ambigous names of classes. давайте без "идиотов" а по существу.Я лиш привёл пример, к чему может привести Ваша концепция отсутствия reference-ов. В принципе, то что Вы предлагаете уже существует в каком-то виде в C# + Visual Studio. Я набираю имя класса - IDE предлагает добавить соответствующий using. Разумеется, поиск производится среди библиотек, подключенных к проекту.
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35981986
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonFixin
1. Файл интерфейса можно получить автоматом, если надо, или в той же IDE посмотреть только заголовки функций, зачем требовать его обязательное наличие?

О каком файле интерфейса идёт речь? IDL что-ли?Да хоть о каком. Речь идёт об абстрактной возможности сгенерировать и отобразить интерфейс модуля (сборки, класса и т. д.) на основании метаданных, хранящихся в нём.

mayton

3. Зачем я должен следить за именами H-файлов?
4. Зачем мне вообще H-файлы, если найти нужное описание класса может и сам компилятор?

Управление -h файлами это в некотором роде контроль над scope vision для компиллера. Ты отделяешь, что ему надо видеть, а что нет. И элементарное управление пространством имён.Для этого существуют более разумные способы.

mayton

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

> Подстановки.

Подстановка тела функции в месте вызова имеется в виду ?
И как это связано с inline ? То-то, что НИКАК это не связано.
Именно поэтому и не будет проблем.

А что такое инлайн по вашему тогда?
...
Рейтинг: 0 / 0
Морально устаревшие элементы языков высокого уровня
    #35982000
Фотография XDiaBLo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FixinXDiaBLo
Это делают пространства имён, гораздно удобнее, чем в названии каждого класса набивать так нелюбимый вами лишний текст.
По поводу JAVA я всего лишь предлагал, если библиотека не указана, то искать имя класса во всей библиотеке. Это не отрицает пространство имен, а дополняет возможности JAVA
Кроме детского-лепета о конфликте имен классов возражений я не услышал.
А я кроме детского лепета об уникальных названиях всех классов в мире, тоже ничего не услышал. Я сторонник всегда всё указывать явно, поэтому данный подход попросту не одобряю.
...
Рейтинг: 0 / 0
25 сообщений из 355, страница 4 из 15
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Морально устаревшие элементы языков высокого уровня
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]