Здравствуйте, Kh_Oleg, Вы писали:

K_O>Шаблоны — это автоматизированный Copy-Paste.
А ну-ну. Так можно в конце концов договорится до того что шаблоны==препроцессор, а любой компилятор это препроцессор языка программирования в машинный код...
K_O>Может размер бинарника и не такая уж критическая вещь, но вот время линковки — это, по крайней мере, в нашем проекте, самое узкое место. А все из-за шаблонов и макросов...
Я не знаю что вы там в своем проекте делаете что он линкуется черт знает сколько времени. Сколько у вас исходников? 500 метров чтоли?

Здравствуйте, WolfHound, Вы писали:

K_O>>Шаблоны — это автоматизированный Copy-Paste.
WH>А ну-ну. Так можно в конце концов договорится до того что шаблоны==препроцессор,
А в чем принципиальная разница?

K_O>>Может размер бинарника и не такая уж критическая вещь, но вот время линковки — это, по крайней мере, в нашем проекте, самое узкое место. А все из-за шаблонов и макросов...
WH>Я не знаю что вы там в своем проекте делаете что он линкуется черт знает сколько времени. Сколько у вас исходников? 500 метров чтоли?
Намного меньше, но порядок угадан верно.

Здравствуйте, Kluev, Вы писали:

K_O>>Может размер бинарника и не такая уж критическая вещь, но вот время линковки — это, по крайней мере, в нашем проекте, самое узкое место. А все из-за шаблонов и макросов...

K>Ерунду несете. На время линковки шаблоны и т.б. макросы никак не влияют. И вообщем-то на скорость компиляции тоже. То что у вас что-то тормозит это следствие плохой изоляции. Там где надо сделать опережающее описание:
K>

K>class Foo;
K>

K>делается:
K>

K>#include "Foo.h"
K>

K>Небольшее изменение и все пересобирается.

K>По моему опыту шаблоны, при их грамотном употреблении, не влияют существенно на скорость компиляции. Все проблемы со скоростью компиляции/линковки исключительно результат криворукости.
Аккуратнее с выводами, сделанных на основе Вами же придуманных предпосылок.

Насчет forward declarations рассказывать не надо — у нас является обязательным использовать forward declarations вместо include там где это возможно. Но оно невозможно при: а) наследовании; б) объявлении поля данного типа (не указателя на тип).

А шаблоны влияют на скорость компиляции и линковки вот почему:
Допустим есть у нас шаблон, который очень много где используется. Например, собственная реализация auto_ptr<T>. Будучи шаблоном, он, естественно, описан целиком в *.h файле. Для того, чтобы использовать такой шаблон, я должен во все файлы, где от используется включить этот (назовем его, Auto.h) файл. Файлов в проекте (считаем только *.cpp), около тысячи. Итого имеем, тысячекратную компиляцию практически идентичного кода (для каждого *.cpp файла). И это в том случае, если в каждом *.cpp только по одной специализации шаблона. Но это только компиляция. Итак, проект откомпилирован, на диске лежит тысяча *.obj файлов. Теперь за дело берется линковщик. Его задача — найти во всей тысяче файлов дублирующийся код и удалить дубликаты так, чтобы для каждой специализации шаблона осталось только по одному экземпляру кода. Вот и получается, что сначала генерится ненужный мусор, а потом на линковщик взваливается бремя уборки за компилятором.

А уж если в проекте много подобных шаблонов...

Здравствуйте, Kh_Oleg, Вы писали:

K_O>А шаблоны влияют на скорость компиляции и линковки вот почему:
/*поскипано*/
K_O>...., что сначала генерится ненужный мусор, а потом на линковщик взваливается бремя уборки за компилятором.

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

Здравствуйте, Kh_Oleg, Вы писали:

WH>>А ну-ну. Так можно в конце концов договорится до того что шаблоны==препроцессор,
K_O>А в чем принципиальная разница?
А в чем принципиальная разница между компилятором и препроцессором?

WH>>Я не знаю что вы там в своем проекте делаете что он линкуется черт знает сколько времени. Сколько у вас исходников? 500 метров чтоли?
K_O>Намного меньше, но порядок угадан верно.
А конкретней можно? Надеюсь статистика проекта не является коммерчиской тайной.

Я тут небольшой тест сделал.
Сгенерил 1000 файлов такого соержания

#include "..\stdafx.h"
struct c_0
{
    typedef c_0 self_t;
    int i;
    virtual void f(){}
    friend bool operator<(self_t const& l, self_t const& r)
    {
        return r.i<l.i;
    }
};
void f_0()
{
    std::list<c_0> l;
    l.sort();
}

#include "..\stdafx.h"
struct c_1
{
    typedef c_1 self_t;
    int i;
    virtual void f(){}
    friend bool operator<(self_t const& l, self_t const& r)
    {
        return r.i<l.i;
    }
};
void f_1()
{
    std::list<c_1> l;
    l.sort();
}

...
релиз без опции инкрементал линк:
общее время билда 8:13 из которых 0:43 заняла линьковка.
изменение одного файла и линковка примерно 0:30
дебуг с опцией инкрементал линк:
общее время билда 12:40 из которых 1:00 заняла линьковка.
изменение одного файла и линковка примерно 0:02

ЗЫ Может вы всетки инкрементал линк включить забыли?

Здравствуйте, Kh_Oleg, Вы писали:
K_O>Ну я ж говорил, что нельзя будет отличить переменные от массивов...
Как насчет редактора, который будет подсвечивать типы? Ну там для векторов сверху -> рисовать, всякие шрифты для матриц, домики там и т.п. См. Фихтенгольц, к примеру. А?

Здравствуйте, gbear, Вы писали:

G>Другими словами... чем больше операторов, тем легче читается, но труднее понимается... так что ли?! Или на оборот?! Имхо, что-то тут не то

Нет, я имел в виду, что разные варианты лучше при разном уровне пользоавтеля. Т.е. для "новичка" который только знакомится с библиотекой лучше развернутые имена функций чтобы не искать их каждый раз в доках. А для "профессионала" (т.е. пользователя с более чем недельным-месячным "стажем"), который уже хорошо знаком с библиотекой удобнее операторы чтобы текст проще было охватить глазом (и головой).

Кстати, хорошая анлогия (да, да, люблю я аналогии — Меню и горячие клавиши в приложениях. "Новичку" удобнее меню, "профессионалу" — горячие клавиши. Хорошо написанное приложение предоставляет удобные средства управления и для тех, и для других.

Здравствуйте, WolfHound, Вы писали:

WH>>>А ну-ну. Так можно в конце концов договорится до того что шаблоны==препроцессор,
K_O>>А в чем принципиальная разница?
WH>А в чем принципиальная разница между компилятором и препроцессором?
В том, компилятор на основе текста программы на ЯП, генерирует команды процессора, а препроцессор всего лишь заменяет в тексте программы одни строки на другие.
Так вот, каждая специализация шаблона — это новая копия класса с заменой одного идентификатора на другой.

WH>ЗЫ Может вы всетки инкрементал линк включить забыли?
не забыли, там загвоздка в опции "Generate Debug Info", если ее отключить, то линкуется минуты за полторы, но отладчик, ессно, не работает .

Здравствуйте, INTP_mihoshi, Вы писали:

INT>Здравствуйте, gbear, Вы писали:

G>>Другими словами... чем больше операторов, тем легче читается, но труднее понимается... так что ли?! Или на оборот?! Имхо, что-то тут не то

INT>Нет, я имел в виду, что разные варианты лучше при разном уровне пользоавтеля. Т.е. для "новичка" который только знакомится с библиотекой лучше развернутые имена функций чтобы не искать их каждый раз в доках. А для "профессионала" (т.е. пользователя с более чем недельным-месячным "стажем"), который уже хорошо знаком с библиотекой удобнее операторы чтобы текст проще было охватить глазом (и головой).

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

Прочитать выражение основанное на операторах, легче и тому и другому — функциональная запись несколько более громозка. Но понимание, в случае перегрузки что оператора, что функции возможно только после изучения кода (документации) перегрузки. А поскольку семантическая нагрузка на операторы выше (в силу привычки ), то впасть в заблуждение проще.

Вот и получается что, "операторный код" — легче прочитать (субъективно, он "не режет глаз") — но, в случае с возможностью перегрузки операторов, "потенциальная запутанность" такого кода выше


INT>Кстати, хорошая анлогия (да, да, люблю я аналогии — Меню и горячие клавиши в приложениях. "Новичку" удобнее меню, "профессионалу" — горячие клавиши. Хорошо написанное приложение предоставляет удобные средства управления и для тех, и для других.

Аналогия несколько не та.

---
С уважением, Сиваков Константин.

Здравствуйте, LaptevVV, Вы писали:

LVV>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm

После полугода агонии — как для отца, так и для сына — я посоветовал сыну бросить этот курс.

Всего то полгода ! И сразу бросили =) Так они никогда программистами не станут =)

Здравствуйте, LaptevVV, Вы писали:

LVV>http://www.inr.ac.ru/~info21/greetings/wirth_doklad_rus.htm

Читаю выступление, и всё жду, когда же начнутся восхваления Паскаля.
Оп-па — вот и они
ИМХО, всё написанное — сплошное словоблудие без единой конструктивной мысли.

если у кого-то есть желание понаставить минусов — аргументы в студию, плиз!

Глупости написаны. Период жёсткого формализма закончен. Современные программы слишком сложны, чтобы можно было провести формальное доказательство корректности. Да что там программирования, похожая ситуация в математике. Современные численные методы эмпирические. Их сходимость не доказана. В них нарушаются математические правила. Чтобы не быть голословным — в градиентных методах (CG, SCG, BiCG, BiCGStab) используется эренгетическая норма по некоторой матрице, которая, по определению, должна быть симметричной и положительно определённой. Для того, чтобы применить его к произвольной матрице, строят специальную, вдвое большей размерности, коорая заведомо симетрична. Но не положительно определена. Метод, чья правильность (сходимость и аппроксимация) доказана для положительно определённых матриц абсолютно незаконно применяется для произвольных матриц. И на этом алгоритме работают модели АЭС, самолётов, космических кораблей. Вроде работает...

очень понравился этот пассаж:

Мой сын не мог понять, почему x = y должно отличаться от y = x

Это наверно должно убедить всех, что надо писать не x = y, а x := y :lol:
Вот хоть убейте, не вижу никакой разницы. Если человек не можеть понять, что такое переменная, то никакие различия в нотации ему уже не помогут.

Особенно порадовало про учебники для начинающих с описанием формальной грамматики языка. Ну конечно, можно не сомневаться, что EBNF поможет "чайникам" разобраться в сути языка. Ведь каждый чайник сможет усвоить, что такое формальные грамматики, без малейших проблем.

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

Здравствуйте, Дарней, Вы писали:

Д>EBNF поможет "чайникам"

А кого Вы называете "чайниками"? По моему, наоборот, тот кто не знает EBNF, тот и есть "чайник" или другими словами "кул-хацкер" знакомый с программированием по журналу "Хакер" и раскидывающий понты!

Д>теоретики от информатики

Это Вы Вирта, что ли, назвали теоретиком? Если теоретиком называть человека создавшего несколько языков программирования и несколько операционных систем, то кого же тогда называть практиком?

Если бы меня спросили, кого я считаю оторванными от реальности теоретиками, то я бы назвал UML-щиков.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>А кого Вы называете "чайниками"? По моему, наоборот, тот кто не знает EBNF, тот и есть "чайник" или другими словами "кул-хацкер" знакомый с программированием по журналу "Хакер" и раскидывающий понты!

ну во первых, я бы посоветовал внимательно прочитать мое сообщение. Я как раз и написал, что с EBNF мало кто знаком, уж тем более — среди начинающих. А его освоение и, что самое главное, понимание — требует намного больше труда, чем освоение языка программирования (упомянутой там Явы, например). Поэтому идея формального описания языка в учебнике для начинающих лишена смысла. В книге для профессионалов это имеет определенный смысл, но как раз они обычно сложностями с пониманием не страдают
Ну а во вторых — я надеюсь, это не про меня было? Потому что я знаю, что такое EBNF и никогда не читал журнал "Хакер"

СГ>Это Вы Вирта, что ли, назвали теоретиком? Если теоретиком называть человека создавшего несколько языков программирования и несколько операционных систем, то кого же тогда называть практиком?

единственный стоящий упоминания (в практическом плане) это Pascal, точнее — Delphi Да и его роль тоже невелика. Хотя в свое время Паскаль и правда был довольно хорошо, особенно для обучения. Но те времена давно прошли, прогресс ушел далеко вперед, и это надо бы понимать.

СГ>Если бы меня спросили, кого я считаю оторванными от реальности теоретиками, то я бы назвал UML-щиков.

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

Здравствуйте, Дарней, Вы писали:

Д>единственный стоящий упоминания (в практическом плане) это Pascal, точнее — Delphi Да и его роль тоже невелика. Хотя в свое время Паскаль и правда был довольно хорошо, особенно для обучения. Но те времена давно прошли, прогресс ушел далеко вперед, и это надо бы понимать.


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

Здравствуйте, Дарней, Вы писали:

Д>единственный стоящий упоминания (в практическом плане) это Pascal, точнее — Delphi Да и его роль тоже невелика. Хотя в свое время Паскаль и правда был довольно хорошо, особенно для обучения. Но те времена давно прошли, прогресс ушел далеко вперед, и это надо бы понимать.
Algol-W — впервые в строго определенном языке появились записи.
Eiler — Эйлер так пишется? К сожалению, ничего не знаю про этот язык
PL-360 — язык высокого уровня для программирования как на ассемблере. Регистры входили в описание языка
Pascal -!!!!!!!
Modula, Modula-2, Modula-3
Oberon, Oberon-2.
Это только то, что я знаю.
Нифига себе теоретик!!!!

Здравствуйте, Quintanar, Вы писали:

Q>Там же написано, что его Модула используется в каких-то там аэрокосмических проектах. Там, короче, где кульность и "современность" языка никому нафиг не нужна, а нужна сверхнадежность. Да и вообще военные, например, предпочитают довольно консервативные языки, а не новомодные фишки.

Про это я уже много раз слышал. Правда, никто не уточнял, что это за проекты и что за программы на ней реализованы. Может быть, это просто прога для расчета зарплат персоналу?
Хотелось бы более детальной информации.

Q>Прогресс в практическом программировании никуда особенно далеко не ушел. Просто практика, наконец, доросла до некоторых идей, которым уже не один десяток лет.

Ничто не ново под луной.
Тем не менее, то, что они дошли до практической реализации — это безусловно прогресс

Здравствуйте, Дарней, Вы писали:

Д>Я как раз и написал, что с EBNF мало кто знаком, уж тем более — среди начинающих.

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


Д>единственный стоящий упоминания (в практическом плане) это Pascal, точнее — Delphi

Из этой фразы я делаю заключение о том, что Вы не компетентны в этой области. (Вирт не имеет отношения к Delphi. Delphi создал Андерс Хейльсберг, кстати, он же создал C#. Вирт создал Pascal, Modula, Modula-2, Oberon + различные клоны Оберона в соавторстве с другими людьми, в том числе OLGA, Oberon-2, Component Pascal, Active Oberon и т.д; а также ряд операционных систем).



Д>Но с тех пор я немного поумнел

Поздравляю Вас!