Вирт, фактически, вытряс из Паскаля и Модулы все проблемные места. Остался лишь синтаксис.
То есть изначально Оберон проще своих предшественников, обеднев на излишние фичи.
Зато поверх этой платформы стало легко делать различные клоны.
Отвлечёмся от коммерческой стороны вопроса ("что делать с legacy кодом, кто будет переписывать алгоритмы, куда бедным людям податься" итд).
Вот язык С++. Что в нём вызывает проблемы и может быть отринуто (для упрощения компилятора, для повышения ошибкоустойчивости и т.д.), что хочется оставить, а что просто необходимо прибавить.
Сверхзадача — получить компактный язык, при этом не ломающий навыки С++ников.
Дополнительные пожелания: минимизировать рантайм (или сделать его гибко настраиваемым: в частности, сборка мусора — может ли быть опциональной, как RTTI, или же просто обязана быть в ядре?)
Интересно, получится ли в результате новая Java, D, или же что-то оригинальное?
Здравствуйте, Кодт, Вы писали:
К>То есть изначально Оберон проще своих предшественников, обеднев на излишние фичи.
как уже много раз говорилось, простота в мире ЯП — хуже воровства. Если бы в нем были шаблоны или более продвинутое средство для метапрограммирования, он бы чего-то стоил как язык общего назначения. В своем же текущем виде это — нишевой язык, с очень ограниченной областью применения. Не понимаю людей, которые из-за него поднимают шум на форуме
К>Интересно, получится ли в результате новая Java, D, или же что-то оригинальное?
Выбросить:
указатели и всю адресную арфиметику — в специальные "небезопасные секции"
функции с переменным числом аргементов в их текущем виде
разделение на h и cpp файлы
Добавить:
отражение
сборку мусора
поддержку самых распространенных паттернов — на уровне языка (Observer, etc)
вложенные функции
Здравствуйте, Кодт, Вы писали:
К>Вот язык С++. Что в нём вызывает проблемы и может быть отринуто (для упрощения компилятора, для повышения ошибкоустойчивости и т.д.), что хочется оставить, а что просто необходимо прибавить.
Выкинуть:
1) поддержку pure С — большинство проблем языка связано с тем, что он тащит за собой обратную совместимость с обычным C, пример, комитет по стандартизации можете сколь угодно долго и мощно наворачивать жёсткую типизацию и контроль типов, но пока программист может делать так — (SomeType)otherTypeVal все его ухищрения имеют смысл лишь декларации о намерениях;
2) неоднозначности в трактовке стандарта и реализации языка — стандарт содержит слишком много UB и "зависит от реализации"; примеры, которые приходят на ум самыми первыми: по умолчанию просто char — это signed char или unsigned char; в каком порядке инициализируются и уничтожаются статические члены в разных модулях трансляции; гарантия того, что локальные статические переменные инициализируются при компиляции (до входа в область видимости), следствие этой неоднозначности — нет гарантированного потоко-безопасного кода, использующего static (читай на плюсах нет гарантированной поток-безопасной реализации синглтона);
3) ещё кое-что по мелочи, что сейчас вспомнить не могу и что в основном прямо или коссвенно следует из 1 и 2 .
Что добавить (возможно опционально, как сейчас RTTI):
1) мультиметоды;
2) возможность передачи контекста вызова;
3) GC — дабы успокоить споры о том, что C++ хуже C#-па, потому что в нём нет GC .
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Кодт, Вы писали:
Д>Выбросить: Д>указатели и всю адресную арфиметику — в специальные "небезопасные секции"
Это не возможно и не нужно... Если вы это сделаете, то это как раз сломает навыки C++ников и породит другой язык...
Д>функции с переменным числом аргементов в их текущем виде
Согласен — от них одни беды!
Ещё от макросов... О как вариант — необходимо как-нть жёстко ограничить область видимости макроса с параметрами, типа в конце первого cpp, в котором встретился макрос, претранслятор принудительно делает undef для него и запрещает когда-либо ещё его определять...
Д>разделение на h и cpp файлы
Тоже сложно...
Д>Добавить: Д>отражение
Не надо — есть RTTI — этого в большьшинстве случае достаточно, вот опциональное включение сохранения контекста вызова добавить можно...
Д>сборку мусора
С возможностью её включения и отключения...
Д>поддержку самых распространенных паттернов — на уровне языка (Observer, etc)
Не вижу смысла — надо сам сделай, или скачай библиотеку...
Д>вложенные функции
Нафиг? Нужны вложенные функции, используй вложенные класса
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Кодт, Вы писали:
К>Сверхзадача — получить компактный язык, при этом не ломающий навыки С++ников. К>Дополнительные пожелания: минимизировать рантайм (или сделать его гибко настраиваемым: в частности, сборка мусора — может ли быть опциональной, как RTTI, или же просто обязана быть в ядре?)
К>Интересно, получится ли в результате новая Java, D, или же что-то оригинальное?
Не получится, по крайней мере так просто. Всему есть разумное обоснование — и в C++ и в Обероне и в C# и в Java. Вот некоторые доводы, спонтанные — чисто так, поток сознания.
1. Работа с указателями. В C++ — это с одной стороны, беда — все настоятельно рекомендуют использовать авто-указатели или нечто подобное. Но господа-хорошие. Указатели существуют не только для new/delete, а еще и для непосредственной работы с ними, *dst++ = *src++. Если запретить указатели, мы запретим целый большой сегмент языка.
2. c-smile, помнится, спрашивал, где в C++ is_pod_type(. . .). Это, конечно хорошо, но что с этим делать? В compile-time это уже получается макро-процессор со всеми вытекающими. А в run-time — RTTI так или иначе, то есть, самый натуральный reflection. Это дорого.
3. Сборка мусора. В C++ это принципиально невозможно. Чтобы автоматическая сборка мусора стала возможной, надо обеспечить на уровне языка принципиальную перемещаемость всех объектов — чтобы можно было делать уплотнение памяти и содержать кучу в порядке. Это — принципиальный момент и необходимое условие. Без уплотнения кучи сборка мусора утрачивает всякий смысл. Но это фактически означает запрет указателей — операция *dst++ = *src++ становится неправомерной.
4. Generics в C#. Не надо их ругать. Их концепция вполне хороша и замечательно вписывается в парадигму программирования на C# вообще — их можно легко трассировать, нет килобайтных сообщений об ошибках, они легко экспортируются и т.д. — все в runtime, только синтаксис похож на шаблоны.
5. Шаблоны в C++. Ужасная, невообразимая конструкция. Одних только синтаксических несуразностей несть числа. За счет этого, написать хотя-бы парсер C++ — задеча гигантской сложности. Здесь я вполне солидарен с Виртом — язык программирования должен легко парситься, в том числе и умственным мозгом. Но шаблоны предоставляют такое мощное средство оптимизации, которого нет ни в одном другом языке. Макросы и compile-time кодогенерация — это исконное, издавна существующее решение, которе тоже вполне оправдано. Шаблоны же отличаются от макросов одной единственной вещью — исходный код шаблонов можно трассировать в отладчике, код макросов — принципиально нельзя.
6. Замшелая традиция раздельной компиляции/компоновки. Это то, что мне больше всего не нравится в C++ — какая-то ослиная упрямость — вот должен быть компилятор и должен быть компоновщик. Для Си или Фортрана это еще правомерно. Но для C++ — должен быть единый модуль — некий компилинкер, который понимает и исходники и объектники и библиотеки. Тогда бы проблема экспорта шаблонов исчезла сама собой и можно было бы вернуться к Сишной схеме — есть бинарные библиотеки и есть заголовки к ним, без раскрытия деталей имплементации. А код методов шаблонов — да пожалуйста, пусть он лежит в объектниках, хоть в исходном виде (утрирую). Компилинкер его всегда в состоянии до-компилировать их в реальный код и выдать диагностику, если что не так. То же самое — с inline. Почему я обязан писать код inline-метода в .h файле? Я хочу его писать в .cpp файле и помечать как inline — тоже в .cpp файле. А файл определения класса вообще не должен знать, что там inline, а что — нет. А это тоже означает, что inline-функции надо помещать в библиотеки в исходниках. Отсюда опять же вытекает парадигма единого компи-линкера для C++, который бы, в частности, понимал формат библиотек на Си, Фортране и других традиционных структурных языках.
7. JIT-компилятор никогда не сможет предоставить таких же эффективных средств оптимизации, как просто компилятор, хотя бы в силу того, что в том же MSIL не существует такого понятия, как inline, по крайней мере в том виде в каком оно существует в C++.
Такие дела...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Mr. None, Вы писали:
MN>Это не возможно и не нужно... Если вы это сделаете, то это как раз сломает навыки C++ников и породит другой язык...
у меня тут другое мнение... ничего бы это не сломало, зато сильно помогло бы локализовывать ошибки
MN>Тоже сложно...
сложно... но нужно
Скорость компиляции C++ это просто чудовищно, даже заплатки вроде pch не сильно помогают
MN>Не надо — есть RTTI — этого в большьшинстве случае достаточно, вот опциональное включение сохранения контекста вызова добавить можно...
надо-надо но — опционально
MN>С возможностью её включения и отключения...
это — да
MN>Не вижу смысла — надо сам сделай, или скачай библиотеку...
а когда какой-нибудь boost вываливает тебе сообщение об ошибке в n кбайт длиной — это по твоему хорошо?
MN>Нафиг? Нужны вложенные функции, используй вложенные класса
Здравствуйте, McSeem2, Вы писали:
MS>Почему я обязан писать код inline-метода в .h файле? Я хочу его писать в .cpp файле и помечать как inline — тоже в .cpp файле. А файл определения класса вообще не должен знать, что там inline, а что — нет. А это тоже означает, что inline-функции надо помещать в библиотеки в исходниках.
Это не обязательно — достаточно включить нужную опцию оптимизатора.
А искоренять все равно давно уже пора..
Здравствуйте, Кодт, Вы писали:
К>Вот язык С++. Что в нём вызывает проблемы и может быть отринуто (для упрощения компилятора, для повышения ошибкоустойчивости и т.д.), что хочется оставить, а что просто необходимо прибавить.
К>Сверхзадача — получить компактный язык, при этом не ломающий навыки С++ников. К>Дополнительные пожелания: минимизировать рантайм (или сделать его гибко настраиваемым: в частности, сборка мусора — может ли быть опциональной, как RTTI, или же просто обязана быть в ядре?)
ИМХО давно уже назрела необходимость в подобном.
Вот мое виденье:
Препроцессор и раздельная компиляция должны умереть.Должен быть стандартный фронт-энд, котороый парзит исходники выполняет все возможные проверки, и выдает некий стандартный AST (не IL). А бэк-энд уже кушает его и генерит native. Таким образом язык можно развивать гораздо быстрее, т.к. производителям компилеров не нужно делать все, а только кодогенератор. Более того такой подход хорошо подходит для opensource разработки и unix-way. Сценарии могут быть такими: фронт-энд генерит ast-файлы, по которым можно узнать о коде все. Их могут юзать класс-броузеры, тулзы для рефакторинга, и т.п.
Это что касается языка с т.з. компиляции. Теперь сам язык: ГЦ не нужен? иначе второй шарп поулчится. Нужен именно низкоуровневый язык на котором можно делать все. Старые сишные атавизмы выкинуть и слегка почистить язык. Добавить аттрибуты. Причем аттрибуты должны быть для всего включая и блоки кода. Тогда можно будет делать так:
int foo( int x, int y)
{
[debug]
{
validate(x);
validate(y);
}
some_func(x,y)
}
// или так
[unit_test]
{
void test1() { ... }
void test2() { ... }
}
Так же в языке совершенно необходимы интерфейсы. Только не такие убогие как в шарпе, где все функции виртуальные, а грамотные с невиртуальными хелперами. Например:
Hello, McSeem2!
You wrote on Fri, 18 Feb 2005 06:37:43 GMT:
M> 2. c-smile, помнится, спрашивал, где в C++ is_pod_type(. . .). Это, M> конечно хорошо, но что с этим делать?
Как что делать? Шаблоны им специализировать.
M> В compile-time это уже получается макро-процессор со всеми вытекающими. M> А в run-time — RTTI так или иначе, то есть, самый натуральный M> reflection. Это дорого.
Не, нужен полноценный CTTI. Чтоб можно было в CT прогнать шаблон по всем
членам класса и чего-нибудь по ним нагенерировать.
M> 3. Сборка мусора. В C++ это принципиально невозможно. Чтобы M> автоматическая сборка мусора стала возможной, надо обеспечить на уровне M> языка принципиальную перемещаемость всех объектов — чтобы можно M> было делать уплотнение памяти и содержать кучу в порядке. Это - M> принципиальный момент и необходимое условие. Без уплотнения кучи сборка M> мусора утрачивает всякий смысл. Но это фактически означает запрет M> указателей — операция *dst++ = *src++ становится неправомерной.
Заменой указателей на какого-то рода хэндлы это, IMHO, можно было бы
провернуть.
M> 5. Шаблоны в C++. Ужасная, невообразимая конструкция. Одних только M> синтаксических несуразностей несть числа. За счет этого, написать M> хотя-бы парсер C++ — задеча гигантской сложности. Здесь я вполне M> солидарен с Виртом — язык программирования должен легко парситься, в том M> числе и умственным мозгом. Но шаблоны предоставляют такое мощное M> средство оптимизации, которого нет ни в одном другом языке. Макросы и M> compile-time кодогенерация — это исконное, издавна существующее решение, M> которе тоже вполне оправдано.
M> Шаблоны же отличаются от макросов одной единственной вещью — исходный M> код шаблонов можно трассировать в отладчике, код макросов - M> принципиально нельзя.
Ишшо шаблоны кардинально отличаются от макросов учетом областей видимости и
возможностью специализации. Вторая позволяет организовывать рекурсию с
остановкой по условию, и как следствие — писать компайл-тайм программы. Вот
чего в них не хватает, так это возможности полноценно генерировать легко
читаемые имена (как макросами).
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, McSeem2, Вы писали:
К>>Интересно, получится ли в результате новая Java, D, или же что-то оригинальное?
MS>Не получится, по крайней мере так просто. Всему есть разумное обоснование — и в C++ и в Обероне и в C# и в Java. Вот некоторые доводы, спонтанные — чисто так, поток сознания.
MS>1. Работа с указателями. В C++ — это с одной стороны, беда — все настоятельно рекомендуют использовать авто-указатели или нечто подобное. Но господа-хорошие. Указатели существуют не только для new/delete, а еще и для непосредственной работы с ними, *dst++ = *src++. Если запретить указатели, мы запретим целый большой сегмент языка.
Взамен указателей на элементы массива (и вытекающей отсюда адресной арифметики) можно использовать другие концепции — диапазоны (с доступом по индексу либо с последовательным) и потоки чтения/записи (с последовательным доступом).
Хотя, конечно, синтаксис *dst++ выглядит очень компактно и привлекательно... но таит в себе ряд проблем.
В частности, итератор ввода (по Стандарту С++)
— должен быть единственным на свой домен, а обычная семантика пост-инкремента — это возвращение предыдущего значения, т.е. ещё одного итератора; значит, мы или отступаемся от Стандарта, или втихаря меняем семантику (возвращая или ссылку на самого себя, или прокси — указатель на предыдущую позицию)
— последовательность доступа (на запись) и инкремента — поочерёдно; между тем, синтаксис позволяет написать (*dst) без присваивания или (dst++,dst++,dst++) без разыменований.
Уже в С++ можно с помощью обёрток скрыть всю адресную арифметику (в т.ч. с итераторами) с глаз долой. Но багаж STL не позволит сделать это с лёгким сердцем.
Ещё бы синтаксис красивый придумать (на операторах, а не на функциях read(cursor), write(cursor,value) и т.п.)...
MS>2. c-smile, помнится, спрашивал, где в C++ is_pod_type(. . .). Это, конечно хорошо, но что с этим делать? В compile-time это уже получается макро-процессор со всеми вытекающими. А в run-time — RTTI так или иначе, то есть, самый натуральный reflection. Это дорого.
RTTI — можно отключить.
MS>3. Сборка мусора. В C++ это принципиально невозможно. Чтобы автоматическая сборка мусора стала возможной, надо обеспечить на уровне языка принципиальную перемещаемость всех объектов — чтобы можно было делать уплотнение памяти и содержать кучу в порядке. Это — принципиальный момент и необходимое условие. Без уплотнения кучи сборка мусора утрачивает всякий смысл. Но это фактически означает запрет указателей — операция *dst++ = *src++ становится неправомерной.
Ну почему утрачивает? При достаточно частом обслуживании и грамотно спроектированной куче, фрагментация не будет страшна. (Разумеется, любую систему можно изгваздать правильно подобранной бенчмаркой; но в большинстве случаев — обойдёмся).
А адресная арифметика, предположительно, ушла нафиг ещё раньше.
MS>4. Generics в C#. Не надо их ругать. Их концепция вполне хороша и замечательно вписывается в парадигму программирования на C# вообще — их можно легко трассировать, нет килобайтных сообщений об ошибках, они легко экспортируются и т.д. — все в runtime, только синтаксис похож на шаблоны.
MS>5. Шаблоны в C++. Ужасная, невообразимая конструкция. Одних только синтаксических несуразностей несть числа. За счет этого, написать хотя-бы парсер C++ — задеча гигантской сложности. Здесь я вполне солидарен с Виртом — язык программирования должен легко парситься, в том числе и умственным мозгом. Но шаблоны предоставляют такое мощное средство оптимизации, которого нет ни в одном другом языке. Макросы и compile-time кодогенерация — это исконное, издавна существующее решение, которе тоже вполне оправдано. Шаблоны же отличаются от макросов одной единственной вещью — исходный код шаблонов можно трассировать в отладчике, код макросов — принципиально нельзя.
Шаблоны — это не макросы!
Да, синтаксис там страшный; но это, во многом, результат неудачного скрещивания C-style синтаксиса типов (самого по себе нетривиального) и бедной консоли. Не хватило ещё одного вида скобок, позаимствовали непарные знаки < и >.
Уж лучше бы просто пользовались круглыми, или какими-нибудь диграфами наподобие [{ / }].
Разнообразное метапрограммирование — я бы очень хотел оставить в языке.
Ну может быть, нужно пересмотреть инструментарий, потому что в нынешнем виде MPL это постройка Кижей без единого гвоздя. Примерно как программирование на машине Тьюринга.
Какие-то распространённые вещи можно вынести в синтаксис. Например, констрейнты.
template<class T>
class Foo
: private enable_if< some_constraint<T>, some_void_base >::type
// нафига мне нужно наследоваться от чего-то там ради этого constraint'а ?
{
. . .
};
template<class T>
int foo(T x,
enable_if< some_constraint<T> >::type* _ = NULL
// нафига мне этот фиктивный параметр?
)
{
. . .
}
Причём, в случае функций, он мог быть не только на время компиляции, но и на время исполнения (как в Прологе либо в Эйфеле).
MS>6. Замшелая традиция раздельной компиляции/компоновки. Это то, что мне больше всего не нравится в C++ — какая-то ослиная упрямость — вот должен быть компилятор и должен быть компоновщик. Для Си или Фортрана это еще правомерно. Но для C++ — должен быть единый модуль — некий компилинкер, который понимает и исходники и объектники и библиотеки. Тогда бы проблема экспорта шаблонов исчезла сама собой и можно было бы вернуться к Сишной схеме — есть бинарные библиотеки и есть заголовки к ним, без раскрытия деталей имплементации. А код методов шаблонов — да пожалуйста, пусть он лежит в объектниках, хоть в исходном виде (утрирую). Компилинкер его всегда в состоянии до-компилировать их в реальный код и выдать диагностику, если что не так. То же самое — с inline. Почему я обязан писать код inline-метода в .h файле? Я хочу его писать в .cpp файле и помечать как inline — тоже в .cpp файле. А файл определения класса вообще не должен знать, что там inline, а что — нет. А это тоже означает, что inline-функции надо помещать в библиотеки в исходниках. Отсюда опять же вытекает парадигма единого компи-линкера для C++, который бы, в частности, понимал формат библиотек на Си, Фортране и других традиционных структурных языках.
Боюсь, с инлайнами не всё так просто.
Двухслойный компилятор, безусловно, вещь полезная (первый слой, frontend, разбирает синтаксис, а второй, backend, — из удобного бинарного представления рожает объектный код со всеми оптимизациями и т.п.)
Может быть, можно ввести ещё одну ступень: для всех уже доступных определений в модуле создавать объектный код, а для внешних — оставлять синтаксический (откладывая полную компиляцию на стадию сборки).
MS>7. JIT-компилятор никогда не сможет предоставить таких же эффективных средств оптимизации, как просто компилятор, хотя бы в силу того, что в том же MSIL не существует такого понятия, как inline, по крайней мере в том виде в каком оно существует в C++.
, и вот чего подумал.
К>Вирт, фактически, вытряс из Паскаля и Модулы все проблемные места. Остался лишь синтаксис. К>То есть изначально Оберон проще своих предшественников, обеднев на излишние фичи. К>Зато поверх этой платформы стало легко делать различные клоны.
К>Интересно, получится ли в результате новая Java, D, или же что-то оригинальное?
Кажется, что нужно новое. Может быть это будет C++ синтаксис для простых операторов и XML обертка вокруг нее для описания структуры: методов, классов, свойств. Тогда и самодокументирование и полный reflection для исходных текстов. Может дать будет не принципиально какой язык использовать внутри XML обертки.
Здравствуйте, henson, Вы писали:
H>Кажется, что нужно новое. Может быть это будет C++ синтаксис для простых операторов и XML обертка вокруг нее для описания структуры: методов, классов, свойств. Тогда и самодокументирование и полный reflection для исходных текстов. Может дать будет не принципиально какой язык использовать внутри XML обертки.
Здравствуйте, McSeem2, Вы писали:
MS>7. JIT-компилятор никогда не сможет предоставить таких же эффективных средств оптимизации, как просто компилятор, хотя бы в силу того, что в том же MSIL не существует такого понятия, как inline, по крайней мере в том виде в каком оно существует в C++.
А можно узнать почему? Что мешает JIT-у тоже делать inline?
Здравствуйте, McSeem2, Вы писали:
MS>7. JIT-компилятор никогда не сможет предоставить таких же эффективных средств оптимизации, как просто компилятор, хотя бы в силу того, что в том же MSIL не существует такого понятия, как inline, по крайней мере в том виде в каком оно существует в C++.
У джита как раз больше возможностей по инлайну, т.к. все хранится в MSIL. Да и постоянно совершенствуется.
В конце коцов инлайн можно проводить и на этапе компиляции прямо в MSIL. (Помоему у борланда есть нечто подобное).
Так что инлайнить можно в 2 этапа.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, McSeem2, Вы писали:
MS>>7. JIT-компилятор никогда не сможет предоставить таких же эффективных средств оптимизации, как просто компилятор, хотя бы в силу того, что в том же MSIL не существует такого понятия, как inline, по крайней мере в том виде в каком оно существует в C++.
S> У джита как раз больше возможностей по инлайну, т.к. все хранится в MSIL.
В условиях GC — не факт.
Здравствуйте, Кодт, Вы писали:
MS>>2. c-smile, помнится, спрашивал, где в C++ is_pod_type(. . .). Это, конечно хорошо, но что с этим делать? В compile-time это уже получается макро-процессор со всеми вытекающими. А в run-time — RTTI так или иначе, то есть, самый натуральный reflection. Это дорого.
К>RTTI — можно отключить.
Неет. Как мне тут справедливо напомнили, им надо параметризовать те же шаблоны. А то сейчас в нашем тулките приходится писать так:
В результате выбор стратегии сваливается в runtime и сводится к if(Copy::isDeep). . ., то бишь, к проверке на константу.
К>Ну почему утрачивает? При достаточно частом обслуживании и грамотно спроектированной куче, фрагментация не будет страшна. (Разумеется, любую систему можно изгваздать правильно подобранной бенчмаркой; но в большинстве случаев — обойдёмся).
В идеале, уплотнение должно происходить на аппаратном уровне, совершенно прозрачно для любого языка. Оно, конечно и сейчас так происходит, но только на уровне "макрокосма", крупными мазками. Но до того, чтобы обслуживать всякую мелочь пузатую — пока что далеко. И вот тогда и проверку на пропарывание памяти для каждого аллоцированного кусочка можно вынести на аппаратный уровень. Но это пока что непозволительная роскошь, хотя не знаю — может быть на каких-нибудь IBM архитектурах с аппаратной Java-машиной все это уже и есть. Мечта же — иметь аппаратное управление памяти, доступное из любого языка, хоть из Си. А вот освобождать ресурсы полностью автоматически, или вручную (как в Си) — это уже может диктовать сам язык.
К>Шаблоны — это не макросы!
- Но позвольте, конь так не ходит...
— А как же он по-вашему ходит?!
Это, на самом деле, как посмотреть. Вот, делаю ошибку — забыл определить "operator <":
#include <map>
struct S
{
S() {}
S(int va) : v(va) {}
int v;
};
int main()
{
std::map<S, S> v;
v[S(0)] = S(1);
return 0;
}
Получаю совершенно роскошную диагностику аж из шести ошибок, и ни одной явной ссылки на первоисточник ошибки (хочу, чтобы компилятор меня лицом ткнул в struct S). Вот с этой точки зрения, поведение шаблонов в точности соответствует поведению макросов (не Сишного препроцессора, конечно же). Ну это пример утрированный. Но в том же BOOST бывает совершенно нетривиально раскрутить все эти многоэтажные матюги, чтобы докопаться до сути.
В C# путукшсы (ой — generics), было принято стратегическое решение полностью освободиться от недостатков шаблонов. Освободились, концепция стройная и красивая. Но вместе с водой выплеснули и ребенка — все доступные из шаблонов возможности оптимизации. Эх, опять скатываюсь в священные войны — пожалуйста, не обращайте внимания.
А еще мысль такая. C++ приобрел популярность именно из за своей кучерявости. Ситуация похожа на ситуацию с естественными языками — в любом естественном языке есть великое множество противоречий, иносказаний и нелогичностей. Но люди пользуются именно естественными языками, никакие Эсперанты с их чистыми концептами и рядом не лежали по популярности. То же самое и с компьютерными языками — концептуальный Паскаль держится исключительно усилиями товарища Борланда, да и то только потому, что Борланд "испортил" его, привнеся элемент энтропии.
Так вот, любой язык — это всегда компромис между выразительными возможностями и строгостью. На Эсперанто написать поэму — получится скучно и невыразительно. Аналогичные проблемы возникают и с концептуально чистыми языками программирования — они просто скучны. Где фантазия? Где — полет мысли? Один сплошной "технологический процесс". А программист при этом просто стоит у станка и занимается совершенно тупой работой — распускает доски на брус. А я хочу быть мастером-краснодеревщиком и создавать красоту.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, McSeem2, Вы писали:
MS>>>7. JIT-компилятор никогда не сможет предоставить таких же эффективных средств оптимизации, как просто компилятор, хотя бы в силу того, что в том же MSIL не существует такого понятия, как inline, по крайней мере в том виде в каком оно существует в C++.
S>> У джита как раз больше возможностей по инлайну, т.к. все хранится в MSIL. GZ>В условиях GC — не факт.
Тут недавно очень удивился появлению Inline в Delphi. Проскакивали статьи где была оптимизация именно проинлайнивание методов еще на этапе генерации в MSIL борландом. Кроме того учитывая, что MSIL это свего рода подготовленные исходники то потенциальной возможности оптимизации больше. Правда не всегда он оптимизирует как надо.
Правда и нагрузка на оптимизацию кода для GC ему нужна в отличие от натива.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Перекуём баги на фичи!
.
.
