Язык программирования Алмаз , или коротко язык A

[prografix]

Цитата Kutushut @ 01.07.05, 07:59

Цитата prografix @ 01.07.05, 07:20

мне кажется, что некоторые проверки без изменения языка сделать нельзя

Хм... На мой непросвященный взгляд слово "кажется" по такому поводу неуместно. Или проверки нельзя сделать (и тогда создание языка может быть оправданно), или можно их реализовать в рамках существующего, и тогда язык будет просто ненужной поделкой.

Вот один пример. У функции имеется ссылочный параметр на неконстантный объект и на этапе трансляции (компиляции) непонятно проинициализирован он или нет. Можно добавить в язык ключевое слово. Например, "old". Тогда если у такого параметра есть квалификатор old, то этот объект можно использовать без инициализации, а если нет, то он может быть непроинициализированным и использовать его без инициализации нельзя. В свою очередь функция вызывающая эту функцию у которой есть параметр с old, должна позаботится, чтобы параметр был проинициализирован.

[Kutushut]

prografix
А как же конструкторы и ООпроектирование?
Если мы передаем экземпляр по ссылке, он должен быть уже к этому моменту создан. Значит, был вызван конструктор, который создал объект в каком-то законченном состоянии. Если конструктор многоступенчатый и требуется оперировать методами объекта, чтобы его "доинициализировать" - значит, функция должна делать только это.
Мне кажется тут ключевым словом вопрос не решишь. Ну написал ты old, а передал туда все равно не то что надо. И в чем разница? Ты же все равно вызываешь какой-то конструктор перед передачей по ссылке.

[prografix]

Цитата Kutushut @ 04.07.05, 08:59

prografix
А как же конструкторы и ООпроектирование?
Если мы передаем экземпляр по ссылке, он должен быть уже к этому моменту создан. Значит, был вызван конструктор, который создал объект в каком-то законченном состоянии. Если конструктор многоступенчатый и требуется оперировать методами объекта, чтобы его "доинициализировать" - значит, функция должна делать только это.
Мне кажется тут ключевым словом вопрос не решишь. Ну написал ты old, а передал туда все равно не то что надо. И в чем разница? Ты же все равно вызываешь какой-то конструктор перед передачей по ссылке.

Речь идёт не о ООП, а о С++. Объект должен быть создан. Пусть этот объект имеет тип int.

void func1 ( int & i );
 
void func2
{
    int i;
    func1 ( i );
    ...
}

До вызова функции func1 этот объект непроинициализирован и значение его не определено. Моё предложение заключается в том, что в этом случае func1 будет иметь это ввиду. Другой вариант:

void func1 ( old int & i );
 
void func2
{
    int i;
    func1 ( i );
    ...
}

В этом случае компилятор выдаст ошибку, т.к. i непроинициализированo.
В общем язык должен по возможности не давать человеку ошибаться.
Тут у меня ещё не всё продумано. Это пока прикидка.

[Kutushut]

Цитата prografix @ 04.07.05, 11:08

int i;

Конструктор. Объект i создан, в соответствии со стандартом значение у i не определено, но сам по себе объект вполне работоспособен.
Дальше, если ты передаешь неконстантную ссылку в функцию -> ты будешь менять значение i. Если ты там напишешь i++, то как раз будет то, про что ты говоришь. Но ошибка-то не в том, что ты передаешь i в функцию (ты можешь просто написать i++, безо всяких вызовов), а в том, что ты выбрал не тот конструктор. Кстати, gcc выдает в таком случае предупреждение.
В твоем примере func1 должна возвращать i, а не вызываться с ним в качестве параметра имхо.

Кстати, а как быть с объектами, для которых конструктор без параметров вполне подходит? Они не пройдут такую проверку.

[prografix]

Цитата Kutushut @ 04.07.05, 11:49

Цитата prografix @ 04.07.05, 11:08

int i;

Конструктор. Объект i создан, в соответствии со стандартом значение у i не определено, но сам по себе объект вполне работоспособен.
Дальше, если ты передаешь неконстантную ссылку в функцию -> ты будешь менять значение i. Если ты там напишешь i++, то как раз будет то, про что ты говоришь. Но ошибка-то не в том, что ты передаешь i в функцию (ты можешь просто написать i++, безо всяких вызовов), а в том, что ты выбрал не тот конструктор. Кстати, gcc выдает в таком случае предупреждение..

Может быть зря выдаёт, если было задумано, что значение будет присвоено в func1.

Цитата Kutushut @ 04.07.05, 11:49

В твоем примере func1 должна возвращать i, а не вызываться с ним в качестве параметра имхо.

Это были игрушечные примеры. Хотя, я считаю, что в любом случае должна быть "защита от дурака".

Цитата Kutushut @ 04.07.05, 11:49

Кстати, а как быть с объектами, для которых конструктор без параметров вполне подходит? Они не пройдут такую проверку.

Тут ещё надо подумать.

[Kutushut]

Цитата prografix @ 04.07.05, 13:03

Может быть зря выдаёт, если было задумано, что значение будет присвоено в func1.

В принципе не рекомендуется оставлять POD типы без инициализации. Правильно ругается. К тому же это предупреждение при -Wall, можно при желании на него не смотреть.

Цитата prografix @ 04.07.05, 13:03

Хотя, я считаю, что в любом случае должна быть "защита от дурака".

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

[prografix]

Цитата Kutushut @ 04.07.05, 13:33

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

Во-первых, не понял какие полезные свойства я отрубаю. По-моему всё полезное остаётся.
Во-вторых, по поводу инициализации int-а нулём. Есть мнение ( и я с ним согласен ), что в этом случае надо инициализировать его "нехорошим" числом, чтобы увеличить вероятность ошибки и тем самым скорее её исправить. Например, я применял значение -123456789.

[Kutushut]

Цитата prografix @ 05.07.05, 08:58

Во-первых, не понял какие полезные свойства я отрубаю.

Если я правильно понял - в твоем примере будет ошибка если указано old и вызван пустой конструктор. Это - ограничение.

Цитата prografix @ 05.07.05, 08:58

надо инициализировать его "нехорошим" числом

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

[amk]

В некоем учебном алгоритмическом языке (название не помню, к тому же он, кажется, имел диалекты) все(!) параметры предварялись одним из ключевых слов in, out или in/out. Таким способом декларировался способ использования параметра. В первом он мог быть любым вычисляемым зачением, во втором ссылкой на переменную (необязательно инициализированную), в третьем ссылкой на переменную, уже имеющую определённое значение.

C++ позволяет отделить только первую ситуацию. Кроме того, в нём невозможно конструирование объекта без его инициализации (кроме автоматических переменных встроенных типов и агрегатов C).

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

[trainer]

Цитата amk @ 09.07.05, 15:49

В некоем учебном алгоритмическом языке (название не помню, к тому же он, кажется, имел диалекты) все(!) параметры предварялись одним из ключевых слов in, out или in/out.

Это есть в IDL. Сделано это там по понятным причинам.

[prosto]

Как хорошо что я програмирую на Паскале


Хотя при динамическом создании удалении объектов и язык не спасает.
А почему автору не подходит идея препроцессора?, а вобще нужно сперва создать костяк языка(перво-описание),
а потом творить.

[Math]

Мда, точно людям делать нечего.

Вот пример нового языка D Programming Language
Советую изучить . Вдруг что полезное откроется.

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

[prografix]

Цитата Math @ 12.07.05, 15:35

Мда, точно людям делать нечего.

Обижаешь.

Цитата Math @ 12.07.05, 15:35

Вот пример нового языка D Programming Language
Советую изучить . Вдруг что полезное откроется.

За ссылку спасибо. Почитаю.

Цитата Math @ 12.07.05, 15:35

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

Со строками надо подумать. Всё-таки результатом у меня будет текст на С++.

-юсртыхэю 13.07.05, 07:50

Цитата prosto @ 12.07.05, 12:07

Как хорошо что я програмирую на Паскале


Хотя при динамическом создании удалении объектов и язык не спасает.
А почему автору не подходит идея препроцессора?, а вобще нужно сперва создать костяк языка(перво-описание),
а потом творить.

Костяк - это С++. А творить - это находить лучшее решение, чем в оригинале. Лучшее в смысле надёжности.

[Math]

Цитата prografix @ 13.07.05, 07:47

Обижаешь.

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

Как было в одной статье про маляра Шлемиеля написано, не продумав фундамент строят здание.

Мне видится, что, ИМХО, неперспективное это занятие в одиночку мастрячить свой язык программирования, свою операционную систему, ну и т.д. в таком духе.

[prografix]

Цитата Math @ 13.07.05, 08:07

Мне видится, что, ИМХО, неперспективное это занятие в одиночку мастрячить свой язык программирования, свою операционную систему, ну и т.д. в таком духе.

Во-первых, если я вынес обсуждение на форум, то уже не в одиночку.
Во-вторых, многие языки программирования были сделаны одним автором: Ричи ( С ) , Строуструп ( С++ ), Вирт ( целая куча языков ) и т.д.