|
|
Oldring> Скажу, что мне очень сильно не нравится в C++ шаблонах
Oldring> на уровне идей. Полное отсутствие контроля типов. В
Oldring> итоге чтобы понять, какие требования предъявляются к
Oldring> параметрам, например, шаблона класса, нужно перепахать
Oldring> все методы этого класса.??? Вааще не понял!
template
class Buffer
{
...
private:
T Array[size];
...
}что тут непонятного? Какой контроль типов нужен? При инстанцировании
шаблона, когда будет указан конкретный тип, будет проведен и соответствующий
контроль типов. Что не так?Oldring> У нас, действительно, несколько разное представление
Oldring> о том, что значит "хороший" язык программирования. Я
Oldring> полностью согласен с Вашим утверждением о том, что если
Oldring> язык позволяет программисту писать так, как программист
Oldring> хочет - это хорошо. До тех пор, пока программист пишет
Oldring> лично для себя свой хобби-проект. Как человек, который
Oldring> в последнее время читает гораздо больше чужого кода,
Oldring> чем пишет своего, могу Вас заверить, что когда начинаешь
Oldring> читать много чужого кода, представления о том, что такое
Oldring> "хорошо" и что такое "плохо" в программировании сильно
Oldring> изменяются.Это все равно не проблема языка, а проблема управления программным
проектом. На любом языке можно написать безобразно и в плане читабельности, и в
плане безопасности кода. Если в проекте работает не один человек, если от
проекта требуется сопровождаемость другими людьми, то соответствующий
менеджмент этого проекта просто необходим. Сюда входит и coding style, и
документирование, и куча всяких внутренних соглашений - подозреваю, что Вы это
знаете лучше меня. :) Это единственный способ, гарантирующий качество.
Программисты - люди, человеческий фактор всегда доминирует и единственный
путь - это взять его под контроль. А язык программирования тут далеко не на
первом месте - "хороший язык помогает, плохой мешает, но не более того".Как Вы думаете, много написано проектов на С++? В составе команд
программистов. Не хобби, но профессиональных проектов.[...]
Oldring> То, что Вы раскопали внутренности реализации инструментария SystemC,
Oldring> вообще не имеет никакого отношения к этой семантике. Раз сказано, что
Oldring> при описании процесса нужно использовать конкретный макрос - значит,
Oldring> нужно использовать конкретный макрос, и никак иначе.Это где это сказано, что нужно использовать? Это просто в примерах
приводится, например, создание модуля на основе SC_MODULE, который есть макрос:#define SC_MODULE(user_module_name) \
struct user_module_name : sc_moduleЧто, например, мешает вместо
SC_MODULE(Slon)
{
...
};просто написать:
struct Slon : sc_module
{
...
};Просто в случае обертки из макроса получается короче и менее специфически
по синтаксису - более привычно для большинства.Oldring> И еще, минимально достаточное описание этого инструмента (раз
Oldring> это не язык - назовем его инструментом) должно однозначно
Oldring> указывать, что такое "точно такая же система в железе".
Oldring> Без этого нудного и всеобъемлющего описания это все
Oldring> приманка для неосторожных новичков.Думается, что попытки подвести все под общее основание обречены на
неудачу - всего не учтешь, в жизни все сложнее там, где казалось проще, и все
проще там, где казалось сложнее. Поэтому всякое полное формальное описание
красиво и стройно только на бумаге и в проекте. Когда дело доходит до
реализации, то вылезают всякие нюансы, требующие, чтобы их тоже учли. Поэтому
либо вся красота постепенно (возможно, частично) разменивается на
функциональность и получается рабочая система, либо красота остается и система
тоже остается... только мертвой, непригодной для практического использования.Oldring> Кроме того, необходимо накладывать жесткие ограничения
Oldring> на используемые конструкции С++. То, что Вы пишете про
Oldring> указатели - это очевидно, но, в то же время, крайне
Oldring> сложно формально описать, что с указателями можно делать,
Oldring> а что нельзя, чтобы синтезатор смог их синтезировать
Oldring> с разумной эффективностью.Зато не очень сложно описать то, что можно делать и каким требованиям они
должны удовлетворять. Остальное запретить. По ходу дела смотреть, какие еще
фичи можно добавить - и добавлять. Постепенно. Апробируя на практике. Это
реальный путь достижения эффективности и мощи. С++ как раз и шел по этому пути
и своей успешности во многом обязан именно этому.Oldring> Отмечу, что и для обычных языков программирования арифметика
Oldring> указателей - это
Oldring> зло,Автомобили - это зло, т.к. они служат одним из самых больших источников
человеческих жертв (ДТП) и наносят непоправимый вред экологии. Кто сегодня
готов отказаться от использования автомобилей?Oldring> так как существуют эффективные алгоритмы оптимизации, которые ею
Oldring> практически убиваются. Оптимизатор посто
Oldring> не может вычислить, на какие переменные в программе
Oldring> указатель _может_ ссылаться, и, соответсвенно, присваивание
Oldring> разыменованному значению такого указателя становится
Oldring> барьером, через который запрещено распространять информацию
Oldring> о выражениях в программе, совершенно не связанных (с
Oldring> точки зрения программиста) с этим указателем. Для обычной
Oldring> программы это только уменьшает эффективность трансляции,
Oldring> для железного синтеза это зло - смертельно.Не понял. Вот представим, что адресной арифметики нет. Просто нет. Как это
поможет оптимизации? Если какое-то средство не дает достичь желаемого
результата - не используйте его, только и всего.
Oldring> И я не согласен с Вашим утверждением о том, что какие
Oldring> системы моделировать на Верилоге - это вопрос вторичный.
Oldring> Существует множество языков моделирования систем, но
Oldring> только некотороые из них имеют синтезируемые в железо
Oldring> подмножества. "Verilog HDL is a formal notation intended
Oldring> for use in all phases of the creation of electronic
Oldring> systems." - IEEE Std 1364-2001.Речь шла о временах, когда язык создавался, т.е. 1983 год, когда в Верилог
был создан в фирме Gateway Design Automation. Создан как язык для симуляции
(моделирования).
E-mail: 
info@telesys.ru
