P>Я не предлагаю клонировать реализацию поддержки исключений из Javы, мне просто в С++ не хватает инструмента который бы мог определить, что какое-то исключение оставлено без внимания.
Зачем вносить в стандарт С++, то что можно реализовать как внешний инструмент?
http://edoc.sourceforge.net/

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

RO>Конечно, здесь есть, что улучшить. Например, хорошо бы избежать полной перекомпиляции при добавлении какой-нибудь private-функции, она же не меняет ABI. Но полностью засунуть std::sort в модуль не удастся никогда.
.NET'у удалось.
Кто мешает поступить также?
Те фронтенд генерит некий промежуточный код(возможно даже кроссплатформенный), а бекенд конкретные бинарники.
См например LLVM.

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

R>Здравствуйте, Аноним, Вы писали:

R>>>Что Вам мешает в С++?

А>>Как ни парадоксално — свобода в выборе стиля. Можно писать в стиле старого доброго С, можно использовать шаблоны и прочие прелести ФП, можно ООП, можно даже автоматическое управление памятью, которое по мне так даже удобнее GC. Проблема в том что когда проект пишет сотня человек у каждого из который свое понятие "правильности" — вот это то и мешает в С++.

R>Ок. Принимается. Сам с таким сталкивался.

Это не проблема языка. Это проблема команды, и личной дисциплины каждого. Есть coding style проекта, за любое отступление от него должно биться по рукам и производиться обязательное "выправление". Если не согласны со стилем — все вопросы к лидеру проекта. Но пока он не одобрит изменения в coding style — все должны пищать, но соответствовать текущему варианту. Ибо нефиг.

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

RO>>Конечно, здесь есть, что улучшить. Например, хорошо бы избежать полной перекомпиляции при добавлении какой-нибудь private-функции, она же не меняет ABI. Но полностью засунуть std::sort в модуль не удастся никогда.

WH>.NET'у удалось.
WH>Кто мешает поступить также?

Это tradeoff. Решение .NET не строго лучше. Тем более, что то же самое можно сделать и в C++, см. pimpl. Например, <stdio.h>: пользователю неведомо, что внутри структуры FILE, и при изменении внутренностей fopen не нужна перекомпиляция. Чем за это нужно платить, понятно?

WH>Те фронтенд генерит некий промежуточный код(возможно даже кроссплатформенный), а бекенд конкретные бинарники.
WH>См например LLVM.

Если я добавлю в класс еще один член, то пользователей класса всё равно придется перекомпилировать, верно?

Если изменится что-нибудь в недрах std::sort, то нужно будет перекомпилировать все воплощения, верно?

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

Впрочем, было бы интересно попытаться реализовать два способа компиляции: тот, который есть сейчас, и дотнетоподобный, где весь статический полиморфизм был бы заменен динамическим. Для разработки использовался бы второй, а для конечного продукта — обычный, с полномасштабным инлайнингом и т. п. Во время разработки отдавалось бы предпочтение скорости компиляции, а по окончании ее — скорости работы самой программы.

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

А>интерфейсы — наше все
я за и делаю максимально где это возможно, но иногда чтото требует скорости, например matlib и вот тут интерфейсы ну уж совсем не к месту

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

RO>Это tradeoff. Решение .NET не строго лучше. Тем более, что то же самое можно сделать и в C++, см. pimpl. Например, <stdio.h>: пользователю неведомо, что внутри структуры FILE, и при изменении внутренностей fopen не нужна перекомпиляция. Чем за это нужно платить, понятно?
Ты не понимаешь.
Нет там ничего такого.
Генерики воплощаются каждый раз. (правда только для value типов но это чисто заморочки .NET)

RO>Если я добавлю в класс еще один член, то пользователей класса всё равно придется перекомпилировать, верно?
Не совсем.
Отработает только бекенд.
А он очень быстро работает ибо ему не нужно ничего проверять, искать и порождать сотни одинаковых воплощений в разных единицах трансляции.

RO>Промежуточный код мог бы помочь, различая существенные и несущественные изменения. Но ускорить компиляцию на порядки не выйдет.
Как нефиг делать. Даже прекомпилированные заголовки очень сильно помогают.
А на сколько порядков можно разогнать линькер...

RO>Впрочем, было бы интересно попытаться реализовать два способа компиляции:
Для этого придется очень сильно менять язык.

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

RO>>Это tradeoff. Решение .NET не строго лучше. Тем более, что то же самое можно сделать и в C++, см. pimpl. Например, <stdio.h>: пользователю неведомо, что внутри структуры FILE, и при изменении внутренностей fopen не нужна перекомпиляция. Чем за это нужно платить, понятно?
WH>Ты не понимаешь.
WH>Нет там ничего такого.
WH>Генерики воплощаются каждый раз. (правда только для value типов но это чисто заморочки .NET)

Таки не понимаю, объясни, пожалуйста.

Как можно оставить возможность создания объектов на стеке и избежать перекомпиляции при изменении внутренней структуры объектов?

Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?

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

RO>Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?
Без запуска фронтенда (для модуля с std::sort) легко.
Также учти что в этой схеме не будет сотен воплощений одного и тогоже метода.
Компилятору не придется их долго и нудно компилировать, а линькеру не придется их долго и нудно сливать.
Не будет гигабайт промежуточных файлов что позволит очень не хило сэкономить на IO.
...
А еще бекенд можно очень сильно распаралелить.
Вплоть до потока на функцию что в условиях наступающих многоядерников совсем не помешает.

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

RO>>Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?
WH>Без запуска фронтенда (для модуля с std::sort) легко.

Вот как именно легко? Как это реализовать?

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

RO>Вот как именно легко? Как это реализовать?
Псевдокод:
std.sort.cpp

module std.sort;
public import std.iterator;
public import std.predicate;

namespace std
{
    template<class IterType, class Comparator, class ValueType>
    public void sort(IterType begin, IterType end, Comparator cmp)
    where IterType : std::random_access_iterator<ValueType>
    where Comparator : std::order_predicate<ValueType>
    where ValueType : std::swappable<ValueType>
    {
        ...сортируем...
    }

    template<class IterType, class ValueType>
    public void sort(IterType begin, IterType end)
    where IterType : std::random_access_iterator<ValueType>
    where ValueType : std::ordered<ValueType>, std::swappable<ValueType>
    {
        sort(begin, end, std::less<ValueType>());
    }
}

Теперь просто компилим и получаем бинарник в котором недокомпилированный код.
В такой схеме приходится указывать констрейнты но ИМХО это даже плюс.
Ибо автокомплит будет работать без проблем.
Да и ошибки будут наааамного понятнее.

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

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

M>>чета вы гоните.

ST>чета кто-та по ночам не то-та чета пишет

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

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

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

M>>корректная реализация finally может быть сделана, если оно вообще нужно, но только не через нули.
M>>инициализируйте короче свои мусорные поля ручками, потом вызывайте то, что может генерить исключение.
M>>finnaly реализуется просто как первоначальный jump на кусок кода обьявленный как finally, а потом уж поиск по стеку подходящего по типу обработчика исключания. finally аналогичен тут дополнительно вставленному в цепочку обработчиков исключения, еще одному обработчику, что выполняется при ЛЮБОМ исключении, и потом ищется уже обработчик по типу выброшенного.

ST>Блок finally выполняется в любом случае, даже если исключения не было.
ST>Так что если не использовать scope guard-ы, отсутствие finally ведет к дублированию кода.

ST>

ST>int *i = new int;
ST>try
ST>{
ST>  ...
ST>}
ST>catch(...)
ST>{
ST>  delete i;
ST>  throw;
ST>}
ST>delete i;
ST>

ST>против
не делайте throw, если вы обработали исключение.
раз вы его делаете, это значит, что вы не можете исключение реально обработать.
вообще это моветон, программировать "на исключениях", моду на такое пресекать нуна!

ST>

ST>int *i = new int;
ST>try
ST>{
ST>  ...
ST>}
ST>finally
ST>{
ST>  delete i;
ST>}
ST>

ST>Вот и все, видимо, о чем хотел сказать автор.

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

M>хидер вообще не стандартизован, насколько я понимаю, и есть лишь общепринятое соглашение. можете не поддерживать! сколько раз я видел людей, что просто не умеют писать хидеры, причем спецы между прочим. например они в хидер впихивают инклуды, нужные только для имплементации. почему?

Скорее всего проекты небольшие, и время компиляции не превысило некий критический порог.

WolfHound пишет:

> Единственное толстое обстоятельство это раздолбайство авторов С.
>
Я думаю, авторы C были в шоке от последствий.

Мне вот на днях консерву надо было ночью открыть, а открывашка
потерялась, я ключом "открыл" (помыв его до и после, конечно).

А теперь представьте, что одним солнечным днём я обнаруживаю в продаже
швейцарский набор ключей. Теперь уже не только для открывания консерв.
Винты можно вкручивать вместо отвёртки, на гитаре играть вместо медиатора.

--
ISO/IEC 8652:1995/Amd 1:2007

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

TB>>Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти...
А>За delete и голвые в С++ коде воще по рукам бить надо.

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

TB>>Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом.
А>Правда, неужели переход с .net 1.1 на 2.0 был совершенно безболезненным?)

Единственный большой проект, который мне пришлось сделать на 1.1, коллеги перевели на 2.0 без меня, но на проблемы вроде не жаловались.

merk пишет:

> более того, от таких рекурсивных инклудов вам насыпят в область
> видимости могучее множество внешних обьектов, пересекающихся с вашими по
> именам

Мухехе...

http://aurelien_regat-barrel.blogspot.com/2004/08/problem-with-vtk-headers-under-windows.html
http://www.vtk.org/pipermail/vtkusers/2004-May/073854.html

http://www.gamedev.net/community/forums/topic.asp?topic_id=275559

http://rubyforge.org/pipermail/wxruby-users/2003-October/000064.html

http://www.eggheadcafe.com/forumarchives/vclanguage/Dec2005/post24763701.asp

--
ISO/IEC 8652:1995/Amd 1:2007

А>Это не проблема языка. Это проблема команды, и личной дисциплины каждого. Есть coding style проекта, за любое отступление от него должно биться по рукам и производиться обязательное "выправление". Если не согласны со стилем — все вопросы к лидеру проекта. Но пока он не одобрит изменения в coding style — все должны пищать, но соответствовать текущему варианту. Ибо нефиг.

Это все, конечно, хорошо звучит, однако работать приходится не с роботами, а с людьми. Думаю не стоит доказывать, что никакой тим-лид не в состоянии постоянно контролировать каждый участок кода, да и нездорово это. К тому же написать Стандарт Кодирования, в частности стиль кодирования, который бы удовлетворял всех и при этом был непротиворечив, практически невозможно (я как-то пробовал). При этом если только у вас не армейское предприятие, будет довольно трудно и посему дорого контролировать код...

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

_>Это все, конечно, хорошо звучит, однако работать приходится не с роботами, а с людьми. Думаю не стоит доказывать, что никакой тим-лид не в состоянии постоянно контролировать каждый участок кода, да и нездорово это. К тому же написать Стандарт Кодирования, в частности стиль кодирования, который бы удовлетворял всех и при этом был непротиворечив, практически невозможно (я как-то пробовал). При этом если только у вас не армейское предприятие, будет довольно трудно и посему дорого контролировать код...

Ипатьевский метод творит чудеса, даже на гражданских предприятиях...

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

M>не делайте throw, если вы обработали исключение.
M>раз вы его делаете, это значит, что вы не можете исключение реально обработать.

Это он изображает finally.

Кстати, как можно иначе сделать вот это:

context.begin();
try
{
    . . .
}
catch(...)
{
    context.rollback();
    throw;
}
context.commit();

?

M>вообще это моветон, программировать "на исключениях", моду на такое пресекать нуна!

А как правильно?

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

RO>А как правильно?

CTransaction tr( context );
// ...
tr.commit();

а rollback, если он вообще нужен, делается в деструкторе незакоммиченой транзакции...

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

RO>Для производительности. Чтобы можно было всё инлайнить. Чтобы можно было реализовать статический полиморфизм. За это приходится платить увеличением времени компиляции. Неужели не понятно?

imho, tradeoff это не только увеличение времени компиляции, но и увеличение затрат на сопровождение, что выражается в таких проблемах, как лишние инклуды (представьте компоненту, код к которой пишут несколько команд из разных стран, под прессингом времени находится немного людей, которые удаляют такие лишние зависимости времени компиляции — сталкивался неоднократно на собственном опыте).
Плюс появление различных вариаций, как можно писать инклуды —
так
#include "myfolder/myfile.h",
#include "../myfolder/myfile.h",
#include "myfile.h",
#include <myfolder/myfile.h>,
#include <myfile.h>
???
И еще — необходимость писать инклуд гарды. Я считаю идиотизмом, что не стандартизировали хотя бы в 98 году #pragma once, которая была известна еще в 80-х. И по сей день для написания "ISO 100% compliant" кода приходится писать эти наборы #ifndef/#define...#endif

Я понимаю, что таково наследие С++ и иногда(хоть это категорически не рекомендуется) инклуд того же файла пишется дважды с целью иной трактовки его содержимого. Но, согласитесь, это в промышленном коде это встречается исчезающе редко.