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

Собираюсь разработать новый язык программирования Алмаз и реализовать транслятор для него на С++ и в С++. Основная причина сделать более надёжный язык по сравнению с С++, т.е. такой чтобы в одних случаях не давал ошибаться, а в других позволял быстро обнаружить ошибку. Буду выдавать информацию небольшими порциями.
Смешанной арифметики в этом языке не будет. Все приведения типа только явные.

Цитата prografix @ 20.05.05, 07:45

Собираюсь разработать новый язык программирования Алмаз и реализовать транслятор для него на С++ и в С++. Основная причина сделать более надёжный язык по сравнению с С++, т.е. такой чтобы в одних случаях не давал ошибаться, а в других позволял быстро обнаружить ошибку. Буду выдавать информацию небольшими порциями.
Смешанной арифметики в этом языке не будет. Все приведения типа только явные.

Подобный язык уже есть, он называется - Java...

Alex221
Не знал, что там всё так строго.
В языке А будут следующие арифметические типы:
знаковые целые - int8, int16, int32, int64,
беззнаковые целые - uint8, uint16, uint32, uint64,
с плавающей точкой - float32, float64, float80.
Для преобразования типов предназначены встроенные функции названия которых состоит из символа подчёркивания и имени типа. Например,
int64 a;
int32 b;
a = _int64 ( b );
В случае если приведение некорректно будет бросаться исключение.

Сообщение отредактировано: prografix - 20.05.05, 11:43

Так-с! Visual C++ 6.0 это хорошо!

Цитата

Для преобразования типов предназначены встроенные функции названия которых состоит из символа подчёркивания и имени типа. Например,
int64 a;
int32 b;
a = _int64 ( b );
В случае если приведение некорректно будет бросаться исключение.

А как насчет сивольных типов? и их преобразования?

Цитата maxim84_ @ 20.05.05, 12:09

А как насчет сивольных типов? и их преобразования?

Основная идея, что символьный тип эквивалентен одному из беззнаковых целых.
Например, 'a' имеет тип uint8. Но если поддерживать unicode, то тогда будет uint16.
Над деталями пока размышляю.

так секунду... ты хоть примерчик покажи как с ними работать! а то что я не совсем пойму...

maxim84_
Давай этот вопрос разберём позже, а сейчас вот что. Я представляю работу с транслятором так. Будет некоторое приложение в Windows, окно которого состоит из двух частей. При загрузке файла ( исходника ) он появляется в левом окне, а при нажатие на заданную кнопку ( или пункт в меню ) этот исходник транслируется в текст на другом языке, который появляется в правом окне. В нашем случае это будет: язык А -> С++. Сообщения об ошибках появляются тоже в правом окне. Причём это приложение можно будет использовать для разных пар языков. Возмёшься его сделать? ( Только основу, без трансляции ). Я в это время сделаю сайт, куда буду выкладывать документацию.

в смысле основу? т.е. сам редактор?

а дебугер будет?

слушай а почему в С++ модет лучше а asm? так код можно оптимизировать на любой прцессор.

Добавлено 21.05.05, 09:54
а еще вопрос! как делать с поддрежко MFC или все ручками писать?? я пока начну на MFC

Добавлено 21.05.05, 10:05
а вот че еще забыл! делать поддержку проектов или по только открывать по одному файлу. т.е. сделать как VB или что то типа старых языков типа QBasic -где возможность работать только с одним фалом?

Сообщение отредактировано: maxim84_ - 21.05.05, 10:05

Цитата maxim84_ @ 21.05.05, 09:45

в смысле основу? т.е. сам редактор?

Да.

Цитата maxim84_ @ 21.05.05, 09:45

а дебугер будет?

Пока нет. Всё равно на выходе будет С++, а не исполняемый код.

Цитата maxim84_ @ 21.05.05, 09:45

слушай а почему в С++ модет лучше а asm? так код можно оптимизировать на любой прцессор.

Потому-что 1) так проше 2) С++ универсальнее, чем ассемблер ( не завязан на железо ) 3) оптимизировать код - это другая задача, пусть ей занимаются Microsoft и т.д.

Цитата maxim84_ @ 21.05.05, 09:45

Добавлено 21.05.05, 09:54
а еще вопрос! как делать с поддрежко MFC или все ручками писать?? я пока начну на MFC

Добавлено 21.05.05, 10:05
а вот че еще забыл! делать поддержку проектов или по только открывать по одному файлу. т.е. сделать как VB или что то типа старых языков типа QBasic -где возможность работать только с одним фалом?

С MFC проще. Пока по одному файлу.

ок, задача ясна.....

Цитата prografix @ 21.05.05, 07:54

Будет некоторое приложение в Windows

А чего сразу виндос? Вдруг язык будет интересен широким массам пингвинеров?

Цитата prografix @ 20.05.05, 07:45

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

Цитата prografix @ 20.05.05, 07:45

Все приведения типа только явные.

Читал-читал... Слушай, а зачем изобретать "новый велосипед"?
Имхо лучше сделать хитрый парсер, который будет проверять соответствие типов. И "в поддержку" к нему - спецификацию какие типы рекомендуются к использованию. Все преобразования типа () парсером переделывать в static_cast<>() и проверять соответствие типов. По-моему будует очень полезная тулза.

Kutushut
Лично мне нужно приложение в Windows.
По поводу преобразования типов по умолчанию. Вначале я хотел запретить все, а теперь думаю, что в случае преобразования без потери информации можно разрешить.

Цитата prografix @ 23.05.05, 07:06

Вначале я хотел запретить все

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

Цитата Kutushut @ 23.05.05, 09:13

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

Цель такая ( программа-минимум ) - сделать язык и транслятор с него на С++, т.к. мне нужны программы на С++. Новый язык нужен для того, чтобы писать более надёжные программы ( меньше ошибок ). Это минимум, но из того может получиться гораздо большее.

Цитата Kutushut @ 23.05.05, 09:13

Я так понимаю, это что-то для мат. обеспечения?
Потому как если, допустим, char не преобразовать к int, в поток его значение не выведешь...

Я думаю, что язык будет универсальным, как С++. Насчёт, второго предложения не понял. Тут расхождений с С++ особых не наблюдается.

prografix, а может быть попробовать научиться на С++ более надежные программы писать? Да и что ты понимаешь под "более надежные программы с меньшим количеством ошибок"? Тут уже, по моему, все от кривизны рук программиста зависит, а не от мощности транслятора/компилятора...

Цитата prografix @ 23.05.05, 10:46

мне нужны программы на С++.

Их пишешь ты сам или ты хочешь учить других своему языку?

Цитата prografix @ 23.05.05, 10:46

для того, чтобы писать более надёжные программы ( меньше ошибок ).

Это прямо как у Буча - ООП круче процедурного подхода, потому как меньше ошибок. Т.е. рекламный слоган, а не ответ на вопрос.

Цитата prografix @ 23.05.05, 10:46

Я думаю, что язык будет универсальным, как С++.

Так в чем ссуть-то? Это будет С++ с очень строгой типизацией и запретом преобразования? Или это будет своя грамматика?
И в чем все-таки преимущества этого языка? Пока я не понял и согласен с Флексом - вместо велосипеда пиши безглючные программы...

Flex Ferrum, если то, что на С++, очень рутинно выглядит, то бывает проще создать над-язык, и из него транслировать в C++... bison, yacc, lex -- вот примеры. Для библиотеки Qt существует moc.

Но эти инструменты не универсальны, они ориентированы лишь на определенный класс задач. Для того, чтобы "ошибок было меньше", не язык создавать надо, а инструмент, который будет проверять на предмет наиболее распространенных ошибок. Но и такой есть -- splint, не знаю лишь, для плюсов ли он...

Цитата Flex Ferrum @ 23.05.05, 10:50

prografix, а может быть попробовать научиться на С++ более надежные программы писать? Да и что ты понимаешь под "более надежные программы с меньшим количеством ошибок"? Тут уже, по моему, все от кривизны рук программиста зависит, а не от мощности транслятора/компилятора...

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

-юсртыхэю 23.05.05, 13:23

Цитата Kutushut @ 23.05.05, 11:08

Цитата prografix @ 23.05.05, 10:46

мне нужны программы на С++.

Их пишешь ты сам или ты хочешь учить других своему языку?

Цитата prografix @ 23.05.05, 10:46

для того, чтобы писать более надёжные программы ( меньше ошибок ).

Это прямо как у Буча - ООП круче процедурного подхода, потому как меньше ошибок. Т.е. рекламный слоган, а не ответ на вопрос.

Цитата prografix @ 23.05.05, 10:46

Я думаю, что язык будет универсальным, как С++.

Так в чем ссуть-то? Это будет С++ с очень строгой типизацией и запретом преобразования? Или это будет своя грамматика?
И в чем все-таки преимущества этого языка? Пока я не понял и согласен с Флексом - вместо велосипеда пиши безглючные программы...

Я пишу программы на С++ и мне нужен инструмент для того чтобы писать их с меньшим к-вом ошибок. Если этот инструмент будет нужен не только мне, то я его с удовольствием представлю. На остальные вопросы отвечу завтра.

Цитата Kutushut @ 23.05.05, 11:08

Так в чем ссуть-то? Это будет С++ с очень строгой типизацией и запретом преобразования? Или это будет своя грамматика?
И в чем все-таки преимущества этого языка? Пока я не понял и согласен с Флексом - вместо велосипеда пиши безглючные программы...

Что будет ещё не ясно т.к. нет окончательного проекта. На первых порах цели следующие: 1) убрать неопределённости характерные для С 2) ввести контроль за использованием неинициализируемых переменных 3 ) контроль за выходом за пределы массива

Цитата Ho Im @ 23.05.05, 12:56

если то, что на С++, очень рутинно выглядит, то бывает проще создать над-язык

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

Цитата prografix @ 23.05.05, 13:16

Я пишу программы на С++ и мне нужен инструмент для того чтобы писать их с меньшим к-вом ошибок.

Мне кажется это несколько странным... Когда я трезво оценил свой уровень владения С++, я начал усиленно учиться, а не создавать тулзы для облегчения жизни. Не скажу что сейчас этим разочарован.

Цитата prografix @ 24.05.05, 09:45

Что будет ещё не ясно т.к. нет окончательного проекта.

Как ты пишешь-то без проекта? Пойду язык напишу, но даже не знаю что за язык?

Цитата prografix @ 24.05.05, 09:45

1) убрать неопределённости характерные для С

Можно их просто не использовать.

Цитата prografix @ 24.05.05, 09:45

2) ввести контроль за использованием неинициализируемых переменных

Если ты объявляешь переменную без инициализации gcc c Wall ругается. VC 7.1 кажется тоже.

Цитата prografix @ 24.05.05, 09:45

3 ) контроль за выходом за пределы массива

C++ - надо использовать STL. Хотя если используешь массивы - действительно полезная фича.

Все же мне кажется тебе стоит делать парсер, который проверяет код на C++ - так оно нагляднее и другим может быть полезно.

Kutushut
Я понял, что ты мне советуешь, но остался при своём мнении ( как обычно и бывает ). Поэтому продолжаю разработку в том виде, как я её представляю. По мере готовности буду выкладывать информацию.
Кстати, Страуструп стал делать С++, потому-что С его не устраивал.
А меня не совсем устраивает С++.

Цитата prografix @ 24.05.05, 09:45

1) убрать неопределённости характерные для С

А что конкретно ты имеешь в виду?

Цитата prografix @ 24.05.05, 09:45

3 ) контроль за выходом за пределы массива

Как ты себе этот контроль представляешь? В частности, вот в такой ситуации:

//...
void foo(int* someArray)
{
someArray[2345] = 100;
}
 
//...
 
int array[20];
foo(array);

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

Добавлено 24.05.05, 12:06

Цитата prografix @ 24.05.05, 12:01

Я понял, что ты мне советуешь, но остался при своём мнении ( как обычно и бывает ). Поэтому продолжаю разработку в том виде, как я её представляю.

Как бы не получилось, что закончив разработку и подняв свой уровень владения С++, ты бы не подумал про себя - "а нафига я все это сделал?"

Цитата prografix @ 24.05.05, 12:01

Кстати, Страуструп стал делать С++, потому-что С его не устраивал.
А меня не совсем устраивает С++.

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

Добавлено 24.05.05, 12:16

Цитата Flex Ferrum @ 24.05.05, 12:05

Как бы не получилось, что закончив разработку и подняв свой уровень владения С++, ты бы не подумал про себя - "а нафига я все это сделал?"

Я так понял - у каждого свой путь

prografix, кстати, а почему бы не взять C#?

Цитата

prografix, кстати, а почему бы не взять C#?

оооо, да!! вот это чудо мы еще не обсуждали!! лично мне он совершенно не равиться!! ни туда и не сюда! супер гебрид! :)фу...

prografix, а как будем делать парсинг модульный? т.е. редактор(один .exe) посылает содержимое страници в библу ну или в .exe?

Сообщение отредактировано: maxim84_ - 24.05.05, 12:36

Цитата maxim84_ @ 24.05.05, 12:34

prografix, а как будем делать парсинг модульный? т.е. редактор(один .exe) посылает содержимое страници в библу ну или в .exe?

maxim84_, я тебя не понял. Надеюсь приложение, которое ты делаешь, называется Translator? :-)

Цитата Flex Ferrum @ 24.05.05, 12:05

Цитата prografix @ 24.05.05, 09:45

1) убрать неопределённости характерные для С

А что конкретно ты имеешь в виду?

Вот три примера: 1) размер типов в байтах 2) char может знаковым, а может нет 3) результат оператора % когда один из операндов - отрицательное число зависит от реализации. В стандарте часто есть фраза, что что-то неопределено. Я понимаю, что это сделано для эффективности, но надёжность при этом страдает.

-юсртыхэю 26.05.05, 07:25

Цитата Flex Ferrum @ 24.05.05, 12:05

Цитата prografix @ 24.05.05, 09:45

3 ) контроль за выходом за пределы массива

Как ты себе этот контроль представляешь? В частности, вот в такой ситуации:

//...
void foo(int* someArray)
{
someArray[2345] = 100;
}
 
//...
 
int array[20];
foo(array);

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

Да, именно с такими случаями я собираюсь бороться. Детали пока прорабатываются.

-юсртыхэю 26.05.05, 07:28

Цитата Flex Ferrum @ 24.05.05, 12:17

prografix, кстати, а почему бы не взять C#?

Мне нужен именно С++. Кроме того, я считаю, что С++ - самый лучший язык современности. Но можно улучшить и его.

prografix
если

Цитата prografix @ 26.05.05, 07:00

Мне нужен именно С++.

то при чем тут

Цитата prografix @ 26.05.05, 07:00

убрать неопределённости характерные для С

?

Не пользуйся ими, пользуйся только средствами С++. Большинство проблем уйдет, особенно если ты будешь пользоваться исключительно стандартной библиотекой, а не самопальными велосипедами.

Ошибки уйдут на другой уровень, который новым языком все равно не охватишь. А когда ты вернешься к низкоуровневым способам (если вернешься) - ты не будешь делать все эти ошибки, которые делаешь сейчас

Добавлено 26.05.05, 07:34

Цитата prografix @ 26.05.05, 07:00

я считаю, что С++ - самый лучший язык современности

Мне тоже С++ нравится. Поэтому я его изучаю. Улучшать буду потом, когда буду все знать

Цитата prografix @ 26.05.05, 07:00

1) размер типов в байтах 2) char может знаковым, а может нет 3) результат оператора % когда один из операндов - отрицательное число зависит от реализации. В стандарте часто есть фраза, что что-то неопределено. Я понимаю, что это сделано для эффективности, но надёжность при этом страдает.

Не только эффективности, но и портабельности. Тем более, что никто не мешает тебе typedef-ами ввести ряд платформенно-зависимых типов и пользоваться ими. Деление по модулу на отрицательное число - ну, гм, а ты что хотел? Тем более, что это зависит не от компилятора, а от того, как процессор переварит исходные данные. Ну а неопределенности - что и как нужно программировать, чтобы наступать на UB?

Цитата prografix @ 26.05.05, 07:00

Да, именно с такими случаями я собираюсь бороться. Детали пока прорабатываются.

А чем std::vector не угодил? В любом случае провека будет runtime...

Цитата Flex Ferrum @ 26.05.05, 09:39

А чем std::vector не угодил? В любом случае провека будет runtime...

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

Цитата prografix @ 26.05.05, 11:31

А хотелось бы на этапе компиляции.

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

Цитата prografix @ 26.05.05, 11:31

А ещё у вектора нежелательно брать адрес элемента. Конечно, если не менять размер, то будет всё нормально, а вдруг кто-то поменяет?

Конечно, нежедательно. В общем случае и у массива (переданного по указателю) нежелательно брать адрес элемента - ведь его тоже могут элементарно удалить или отресайзить.

а может C#

Тьфу! Совсем запутался. Ты вроде Язык Дейкстра создавал? Ну... а что, бросил чтоли? Или как? Сначала бы его доделал, а потом уже и Алмаз Тем более язык Дейсктра уже описан и реально существует.
Так можно подумать что пройдет еще пол годика и у нас еще какой язык будет появляться?

Да и (хотя вопрос уже задавали) как ты хочешь Си++ улучшить? Ты говоришь в общих чертах: уберу то, добавлю это, прикручу еще кое-что и...будет все Ок.
Ты в чем то сравниваешь себя с Страуструпом, но я не думаю что он писал Си++ как ты..."Давайте напишем язык! Си слишком плох, пишем сразу транслятор, так быстрее!". Я думаю, что сначала нужно создать проект языка так сказать. Описать конструкции, принципы...хотя бы основываясь на уже готовом стандарте Си++. Потому следовало бы определить...нужно ли все это? Может быть твои навороты нужны в 1 из 1000 случаев?
А ты не знаю еще чего из себя будет представлять язык хочешь писать транслятор... ну не глупо ли?
Потом может быть и правда Си++ лучше изучить? Не думаю что ты его знаешь на отлично... хотя я могу ошибаться.
Потом часть того что ты говоришь можно реализовать опять же на Си++ сделав нужные классы...которые уже реализовали.
Если тебе хочется сделать проверку на выход из границ массива на этапе компиляции, то сделай просто прогу которая бы это проверяла...останется тот же Си++. Хотя как тебе уже сказали, что стоит быть неконстантному индексу...как все бессмысленно. Например Delphi делает таку проверку. Если я сделаю массив в 10 элементов и обращусь к 11 написав прямо array[11] то он меня обматерит, а если я сделаю так:
a := 11;
array[a];
То все пройдет... ИМХО чтобы сделать проверку такую для неконстантных идексов нужно проработать все ситуации в программе компилятору самостоятельно....а это уже трудновато. Да и потом может быть стоит писать код так чтобы не было этих ошибок? Ведь в таких случаях кроме программера никто не виноват...

Цитата p_kolya @ 31.05.05, 14:00

Тьфу! Совсем запутался. Ты вроде Язык Дейкстра создавал? Ну... а что, бросил чтоли? Или как? Сначала бы его доделал, а потом уже и Алмаз Тем более язык Дейсктра уже описан и реально существует.

Давай обо всём по порядку. Да, я действительно собирался делать Дейкстру, но при этом понимал, что он изначально не годится для практики. А делать собирался для того, чтобы набраться опыта для следующего языка, который отвечал бы требованиям сегодняшнего дня. А потом решил не тратить время, которого у меня мало и сразу перейти к новому языку. Если будут желающие сделать Дейкстру - я буду рад.

Цитата p_kolya @ 31.05.05, 14:00

Так можно подумать что пройдет еще пол годика и у нас еще какой язык будет появляться?

Не думаю. Алмаз ещё проектируется и может развиваться в любую сторону.

Цитата p_kolya @ 31.05.05, 14:00

Да и (хотя вопрос уже задавали) как ты хочешь Си++ улучшить? Ты говоришь в общих чертах: уберу то, добавлю это, прикручу еще кое-что и...будет все Ок.
Ты в чем то сравниваешь себя с Страуструпом, но я не думаю что он писал Си++ как ты..."Давайте напишем язык! Си слишком плох, пишем сразу транслятор, так быстрее!". Я думаю, что сначала нужно создать проект языка так сказать. Описать конструкции, принципы...хотя бы основываясь на уже готовом стандарте Си++. Потому следовало бы определить...нужно ли все это? Может быть твои навороты нужны в 1 из 1000 случаев?
А ты не знаю еще чего из себя будет представлять язык хочешь писать транслятор... ну не глупо ли?

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

Цитата p_kolya @ 31.05.05, 14:00

Потом может быть и правда Си++ лучше изучить? Не думаю что ты его знаешь на отлично... хотя я могу ошибаться.

По поводу моего знания С++. Я пишу на нём программы начиная с 90-го года. А до этого писал на С. А до этого на Фортране, ...

Цитата p_kolya @ 31.05.05, 14:00

Потом часть того что ты говоришь можно реализовать опять же на Си++ сделав нужные классы...которые уже реализовали.
Если тебе хочется сделать проверку на выход из границ массива на этапе компиляции, то сделай просто прогу которая бы это проверяла...останется тот же Си++. Хотя как тебе уже сказали, что стоит быть неконстантному индексу...как все бессмысленно. Например Delphi делает таку проверку. Если я сделаю массив в 10 элементов и обращусь к 11 написав прямо array[11] то он меня обматерит, а если я сделаю так:
a := 11;
array[a];
То все пройдет... ИМХО чтобы сделать проверку такую для неконстантных идексов нужно проработать все ситуации в программе компилятору самостоятельно....а это уже трудновато. Да и потом может быть стоит писать код так чтобы не было этих ошибок? Ведь в таких случаях кроме программера никто не виноват...

Человеку свойственно ошибаться и если машина может это обнаружить, то надо этим воспользоваться.

Цитата prografix @ 01.06.05, 08:38

А потом решил не тратить время, которого у меня мало и сразу перейти к новому языку.

Может следует абстрагироваться от реально существующего ЯВУ? А реализовывать >>>транслятор из мета-языка в реальные ЯВУ<<<?

Думаю, не стоит. Универсальность имеет как плюсы, так и минусы ( эффективность ).

Сообщение отредактировано: prografix - 01.06.05, 10:28

Насколько я помню (из какой-то его книги), Страуструп разработал язык C++ не потому, что ему не нравился язык С, а для того, чтобы расширить круг решаемых задач. Сам Страуструп тогда занимался имитационным программированием, и ему приходилось работать с большим количеством объектов, каждый из которых обладал какими-то свойствами. Язык C хорошо подходит для целей системного программирования, но в таких приложениях код получается тяжеловесным. Понятие ООП программирования уже существовало и существовали объектно-ориентированные языки программирования (в частности упоминались языки Smalltalk и Simula). Первый интерпретируемый, второй не подошёл по каким-то другим причинам. Понятие класса введено именно в Simula. Первоначально был разработан язык «C с классами» и был разработан препроцессор, транслирующий его в стандартный C (работал после обработки потока стандартным препроцессором). Его основная работа заключалась в замене классов на структуры, добавлении к этим структурам таблицы виртуальных функций, замене (декорировании) имён методов и функций (для обеспечения перегрузки имён), вставке ссылки на объект класса для которого вызван метод и т.п. Позднее, с развитием языка, поменялось название и был создан полноценный компилятор.

amk
Всё верно, только я писал, что "С его не устраивал", а не "ему не нравился язык С".

В настоящее время я пишу лекситический анализатор и размышляю о синтаксисе. Сейчас думаю, что все объявления будут префексными. Например:

int[5] arr; // массив
double ( int ) func; // функция
int * () * [9] * ptr; // указатель на массив указателей на функции вовращающие указатель на int

Вариант с массивами используется в С#. А такого объявления функций ещё не встречал. Это делается для того, чтобы облегчить объявление такого сложного типа, как в третьем примере.

Цитата prografix @ 09.06.05, 08:09

int[5] arr;

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

int arr5[5], arr10[10];

Ты считаешь, что это:

Цитата prografix @ 09.06.05, 08:09

int * () * [9] * ptr;

очевиднее чем

int* (*ptr[9])();

ИМХО, вам, уважаемый автор, делать нечего

Можете показать проекты, которые вы пишите с 90-х годов прошлого века, которые принесли лично вам доход превышающий $1K/проект?

Цитата Flex Ferrum @ 09.06.05, 08:18

Цитата prografix @ 09.06.05, 08:09

int[5] arr;

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

int arr5[5], arr10[10];

Вопрос пока открыт, но скорее всего да.

Цитата Flex Ferrum @ 09.06.05, 08:18

Ты считаешь, что это:

Цитата prografix @ 09.06.05, 08:09

int * () * [9] * ptr;

очевиднее чем

int* (*ptr[9])();

Да. Считаю. И так считаю не только я, но и Страуструп. Только он предлагал постфиксную запись.

-юсртыхэю 09.06.05, 11:13

Цитата RaD @ 09.06.05, 09:29

ИМХО, вам, уважаемый автор, делать нечего

Ошибаетесь. Времени как раз не хватает. Приходится выделять на этот проект по несколько минут в день.

Цитата RaD @ 09.06.05, 09:29

Можете показать проекты, которые вы пишите с 90-х годов прошлого века, которые принесли лично вам доход превышающий $1K/проект?

Не могу - это секрет. Вообще-то я уже 15 лет работаю над одним проектом, который мне приносит 1К в месяц. Если интересует моё творчество смотрите мой сайт.

Сообщение отредактировано: prografix - 09.06.05, 11:17

Цитата prografix @ 09.06.05, 11:04

Да. Считаю. И так считаю не только я, но и Страуструп. Только он предлагал постфиксную запись.

А по-подробнее и со ссылками?

Цитата Flex Ferrum @ 09.06.05, 11:35

Цитата prografix @ 09.06.05, 11:04

Да. Считаю. И так считаю не только я, но и Страуструп. Только он предлагал постфиксную запись.

А по-подробнее и со ссылками?

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

ptr: ->int; // указатель на int

Но совместимость с С оказалась важнее. Кстати, ты ошибся повторяя мой пример ( что не удивительно, там сам чёрт ногу сломит ). У тебя ptr массив, а не указатель.

Цитата prografix @ 09.06.05, 12:07

что не удивительно, там сам чёрт ногу сломит

Хм... Слушай, а оно надо, коль так? К "привычной" записи все уже привыкли и кое-как ее понимают. А ты хочешь еще непоняток подкинуть?

Цитата Kutushut @ 09.06.05, 12:44

Хм... Слушай, а оно надо, коль так? К "привычной" записи все уже привыкли и кое-как ее понимают. А ты хочешь еще непоняток подкинуть?

Все равно все нормальные люди typedef-ами пользуются. Потому и вопрос типа "напишите вот такой вот из... вращенный тип" может встретить резонный ответ - "а зачем?"

Я имел ввиду, что в существующей системе трудно разобраться. А я предлагаю более простую для понимания вещь.

Добавлено 09.06.05, 13:48
А мне ещё синтактический анализатор писать. Боюсь, что с существующей системой не справлюсь.

Цитата prografix @ 09.06.05, 13:46

А мне ещё синтактический анализатор писать. Боюсь, что с существующей системой не справлюсь.

Как раз для существующей системы синтаксический анализатор написать не сложно - главное правильно приоритеты учесть. Код такого анализатора приводится в библии от Кернигана и Ричи.

Цитата prografix @ 09.06.05, 13:46

Я имел ввиду, что в существующей системе трудно разобраться. А я предлагаю более простую для понимания вещь.

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

Цитата Flex Ferrum @ 09.06.05, 15:12

Цитата prografix @ 09.06.05, 13:46

А мне ещё синтактический анализатор писать. Боюсь, что с существующей системой не справлюсь.

Как раз для существующей системы синтаксический анализатор написать не сложно - главное правильно приоритеты учесть. Код такого анализатора приводится в библии от Кернигана и Ричи.

Есть ли этот источник в электронном виде?

-юсртыхэю 10.06.05, 07:39

Цитата Kutushut @ 10.06.05, 07:25

Цитата prografix @ 09.06.05, 13:46

Я имел ввиду, что в существующей системе трудно разобраться. А я предлагаю более простую для понимания вещь.

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

Я думаю, что не будет проблем с освоением нового синтакасиса. Ведь он будет проще, чем существующий.

Цитата prografix @ 10.06.05, 07:36

он будет проще, чем существующий.

Хм... То, что было в качестве примера - сложнее, чем существующий. Имхо Разве что объявления на отдельных строчках гут, в остальном не уверен что лучше.

Цитата prografix @ 10.06.05, 07:36

Ведь он будет проще, чем существующий.

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

Цитата prografix @ 10.06.05, 07:36

Есть ли этот источник в электронном виде?

Не знаю, наверняка есть. Поищи "Язык программирования С" указанных авторов.

Цитата Flex Ferrum @ 10.06.05, 10:52

Цитата prografix @ 10.06.05, 07:36

Есть ли этот источник в электронном виде?

Не знаю, наверняка есть. Поищи "Язык программирования С" указанных авторов.

Книгу нашёл http://ruler.h1.ru/cpp/bookc/index.htm Никаких исходников там нет.

Предлагаю написать Свой Собственный ВИНДОВС, продавать его, наживаться, а когда популярность спадёт, собрать соответствующую команду и начать выпускать Свои Собственные Глюки!

Цитата prografix @ 09.06.05, 08:09

В настоящее время я пишу лекситический анализатор и размышляю о синтаксисе. Сейчас думаю, что все объявления будут префексными. Например:

int[5] arr; // массив
double ( int ) func; // функция
int * () * [9] * ptr; // указатель на массив указателей на функции вовращающие указатель на int

Вариант с массивами используется в С#. А такого объявления функций ещё не встречал. Это делается для того, чтобы облегчить объявление такого сложного типа, как в третьем примере.

Недавно обнаружил, что для многомерных массивов в этом случае получится неприятная вещь: в объявлении размерности будут идти в одном порядке, а при использовании в другом. Поэтому лучше оставить вариант С++. Можно, конечно, сделать постфиксный вариант, как предлагал Строуструп, но он, мне кажется, смотрится непривычно и некрасиво.

Цитата prografix @ 28.06.05, 09:37

Поэтому лучше оставить вариант С++.

И сделать мега-парсер, который ловит баги в коде на С++

prografix, купи(ну или еще как приобрети ) себе Lint и работай дальше со спокойной душой

byte
С одной стороны - покупать не хочется, с другой - самому интересно сделать, а с третьей - мне кажется, что некоторые проверки без изменения языка сделать нельзя.

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

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

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

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

Без этого обоснования (и анализа существующих средств, как заметил byte) на мой взгляд никто в проекте участвовать не будет.

Один человек уже участвует ( кроме меня ). Надеюсь, скоро мы сделаем первый этап и представим результаты.

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

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

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

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

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

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

Цитата 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.
В общем язык должен по возможности не давать человеку ошибаться.
Тут у меня ещё не всё продумано. Это пока прикидка.

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

int i;

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

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

Цитата 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Цитата 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

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


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

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

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

Обижаешь.

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

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

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

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

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

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

Сделал сайт для описания языка Almaz
Пока там только описание лексем.
Что касается языка D, то впечатление от него у меня такое же, как и после знакомства с Java и C# - это ухудшенный вариант С++. В каких-то деталях я могу согласится, что это лучше, чем было, но в целом считаю язык стал хуже. Понятно, что это дело субъективное. Главное, что мне не нравится - это то, что меняется сама идеалогия языка. Когда я читаю Строуструпа ( а я много чего у него читал ), то мне всё понятно и в большинстве случаев я с ним согласен. А тут его доводы игнорируются.

Цитата prografix @ 16.07.05, 09:19

описание лексем

Что-то туманное описание какое-то. Не проще было взять из стандарта С++ ?

Цитата prografix @ 16.07.05, 09:19

Главное, что мне не нравится - это то, что меняется сама идеалогия языка.

Идеология. ИМХО для человека, создающего свой язык, многовато ошибок в постах...

В целом я все равно никак не пойму общих преимуществ А относительно С++. В топике различные аспекты, где плох С++ и несколько идей что бы сделать для его улучшения. Есть хотя бы полный список фич нового языка? А то что-то пока не верится в светлое будущее... По-моему это важнее лексем и подобных формальностей.

Почитал язык D, не вижу существенной разницы с возможностями C++. Многие из новых особенностей легко реализуются библиотеками и классами. Везде ссылки на реализацию особенностей в библиотеках, а не самом языке (похоже автор забыл (или не понял), что основой идеологии C++ является по возможности как раз миниммальное ядро языка), кое-что планируется включить в обновлённый стандарт (в основном в библиотеки), кое-что не особо и нужно, исключённые особенности и так без нужды не используются. Некоторые новые улучшения, вроде static if, реализуются во многих компиляторах уже лет двадцать.

Для начала я собираюсь реализовать небольшое подмножество языка ( без указателей, массивов, структур и т.д.).
Вот некоторые отличия от С++:
1) Названия арифметических типов содержат к-во бит ( int8, uint16, float32, ...)
2) Только явное преобразование типов
3) В условных операторах используется только логический тип
4) Переменная во внутреннем блоке не может иметь имя, такое же как и во внешнем
5) Отсутствие восьмиричных констант ( типа 0654 )
На сайте добавлен раздел Описание транслятора с исходниками для Visual C++ 6.0

prografix
Пока все фичи укладываются в стандарт С++ с примененным стандартом кодирования
2 и 3 - дело хорошее. Но кто мешает это делать в рамках обычного языка? Разве что совесть программиста. С остальным в принципе то же самое. Насчет 5 - не понял, а чем они мешают?

Цитата Kutushut @ 25.07.05, 12:14

prografix
Пока все фичи укладываются в стандарт С++ с примененным стандартом кодирования
2 и 3 - дело хорошее. Но кто мешает это делать в рамках обычного языка? Разве что совесть программиста. С остальным в принципе то же самое.

В С++ можно написать так, а можно иначе, а здесь иначе не получится.

Цитата Kutushut @ 25.07.05, 12:14

Насчет 5 - не понял, а чем они мешают?

Я не видел случая, чтобы ими кто-то пользовался и решил, что это анахронизм. К тому же способ записи неудачный.

Цитата prografix @ 26.07.05, 09:13

В С++ можно написать так, а можно иначе, а здесь иначе не получится.

Хорошо, не эти так другие проблемы вылезут. Исключительно имхо - нельзя сделать язык, на котором любой кодер, знакомый с синтаксисом, будет писать без ошибок.
Ты лучше придумай то, что дейстительно _нельзя_ сделать средствами С++ (или это требует _очень_ больших затрат) - тогда язык действительно будет чем-то новым.

Цитата prografix @ 26.07.05, 09:13

Я не видел случая, чтобы ими кто-то пользовался и решил, что это анахронизм. К тому же способ записи неудачный.

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

Поначалу все выглядело как язык для точных и безглючных вычислений (мое впечатление).
Сейчас получается какой-то шарп для начинающих.

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

prografix
ИМХО: Бесполезным делом занялся, убрать разнообразие из существующего языка, для упрощения транслятора/программирования, не есть креатив.
Нет вдохновляющей новизной идеи... в .NET'е исходники собираются в управляемый код, который оптимизируется под конкретное железо платформой... в ASP.NET'е исходник транслируется в библиотеку, из которой и собирается нужный процесс, по мере надобности.
Держи проблему: будешь обдумавать новый язык, учти необходимость run-time программирования... если концепция надёжности языка будет противоречить этой возможности, то свой язык пишешь самому себе.

Цитата prografix @ 26.07.05, 09:13

Я не видел случая, чтобы ими кто-то пользовался и решил, что это анахронизм. К тому же способ записи неудачный.

"Ты суслика видешь? Нет? И я не вижу. А он есть." (с) чья-то подпись. prografix, поверь, в С++ есть проблемы по-серьезнее чем те, которые ты описал. Ну и, в общем, согласен с Kutushut'ом. Лучше, например, реши проблему удобного сокрытия деталей реализации классов (то, что обычно идет в private-секции). А то, чем занят ты сейчас - "не будем прогибаться под изменчевый мир, пусть лучше он прогнется под нас." (с) А. Макаревич.

Добавлено 27.07.05, 07:37

Цитата prografix @ 25.07.05, 12:03

1) Названия арифметических типов содержат к-во бит ( int8, uint16, float32, ...)

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

Цитата prografix @ 25.07.05, 12:03

2) Только явное преобразование типов

Чем отрежешь огромный и широкоиспользуемый пласт языка. И это вместо того, чтобы научиться правильно этим пользоваться. Пример:

// Где-то есть функция:
void foo(const std::string& str)
{
//...
}
//...
//...
// В другом месте ты можешь спокойно написать:
foo("Some string");
// потому что std::string поддерживат неявное преобразование из const char*.

Если все преобразования делать явными, то тебе придется писать:

foo(std::string("Some string"));

и так каждый раз.
Если, например, хочешь запретить какие-то неявные преобразования - делай соответствующие конструкторы explicit и не добавляй в классы операторы преобразования. Зачем язык то для этого корежить?

Цитата prografix @ 25.07.05, 12:03

3) В условных операторах используется только логический тип

Нахрена, позволь спросить?

Цитата prografix @ 25.07.05, 12:03

4) Переменная во внутреннем блоке не может иметь имя, такое же как и во внешнем

Уууу... Батенька, да вы не совсем хорошо понимаете правила использования имен в С++, а также их областей видимости.

Цитата prografix @ 25.07.05, 12:03

5) Отсутствие восьмиричных констант ( типа 0654 )

"Не нравиться - не ешь".

Я всё же считаю, что восьмеричные числа в языке не нужны, а вот двоичные пригодятся. Сейчас посмотрел - в D они тоже есть ( типа 0b11011011 )

Цитата prografix @ 27.07.05, 12:08

Я всё же считаю, что восьмеричные числа в языке не нужны, а вот двоичные пригодятся. Сейчас посмотрел - в D они тоже есть ( типа 0b11011011 )

Восьмеричные цифры достались от процессоров с сисемой команд PDP... там восем регистров адресовались тройками бит...

когда-то сам писал свой первый скриптовый язык(точнее первую версию), хотел сделать более удобный, делал интерпритатором, оказалось, что удобнее не делать строго заданные типы переменных, с другой стороны мне не нравится скорость работы. В итоге эту версию я развивать не стал, а стал делать компилятор, сейчас он существует в light версии (скорость на уровне c). За основу я взял c, c++ и некоторые свои решения, придумывать думаю не имеет смысла. Хочу сказать одно, что написать действительно язык программирования высокого уровня сможет программист с высоким знанием, при этом ему это не нужно, так как знаний хватает оптимизировать написание программы на с/c++, что написание своего языка программирования не рационально, исключение составляют скриптовые языки.

Мы вообще по другому прикалывались. Работаем с буржуинами. Перевели плюсы (т.е. C++) на русский с помощью макросов. Коды ессно макросами и оформили. Отсылаем буржуям исходники - у них в итоге всякие зюки вылазят. И самое главное, все компилится Они потом долго матюгались. Даже русские слова слышались Жертвы русского национализма...

Да интересно если язык с++ разрабатывали долгие годы программисты, а не программист то у тебя
на разработку этого языку уйдет вся жизнь.

Rikkie, можешь показать пример такого чуда? :)

Ho Im, нету тут никакого чуда, просто куча #define . Запарился файло добавлять - не лезет, хоть и маленькое...

Любой серьезный язык программирования начинается с сайта и IDE.
А если серьезно, то почитайте "Дизайн и эволюция языка C++" Страуструпа. Если желание создавать язык не пропадет, желаю удачи. У меня лично сразу пропало.

Что-то очень язвительно получилось, самому неприятно. Сорри.

prografix, а ты знаком с какой-нибудь теорией относительно проектирования и разработки языков программирования? Или теорией трансляции?

Сообщение отредактировано: vst - 29.08.05, 19:02

Цитата Flex Ferrum @ 27.07.05, 07:32

"Ты суслика видешь? Нет? И я не вижу. А он есть." (с) чья-то подпись

(ц) фильм ДМБ

Цитата vst @ 29.08.05, 18:55

Любой серьезный язык программирования начинается с сайта и IDE.
А если серьезно, то почитайте "Дизайн и эволюция языка C++" Страуструпа. Если желание создавать язык не пропадет, желаю удачи. У меня лично сразу пропало.

Что-то очень язвительно получилось, самому неприятно. Сорри.

Если это ко мне, то я читал. Всё нормально. Хорошая книга. Желание не пропало. Вот только лень мешает и другие темы соблазняют. Буду делать потихоньку.

Цитата vst @ 29.08.05, 18:55

prografix, а ты знаком с какой-нибудь теорией относительно проектирования и разработки языков программирования? Или теорией трансляции?

Недавно стал интересоваться. Читаю понемногу.

Задача оттранслировать код из не более чем скрипта (потому, как язык программирования (ЯП) -- это компилятор а не редактор) под силам PHP скрипту.
Нексер заморачиваться на ЯП, если нужно получить правильный код на С.