Язык программирования Алмаз
, или коротко язык A
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.207] |
|
|
| Страницы: (7) 1 [2] 3 4 ... 6 7 все ( Перейти к последнему сообщению ) |
Язык программирования Алмаз
, или коротко язык A
|
Сообщ.
#16
,
|
|
 |
Их пишешь ты сам или ты хочешь учить других своему языку? Это прямо как у Буча - ООП круче процедурного подхода, потому как меньше ошибок. Т.е. рекламный слоган, а не ответ на вопрос. Так в чем ссуть-то? Это будет С++ с очень строгой типизацией и запретом преобразования? Или это будет своя грамматика? И в чем все-таки преимущества этого языка? Пока я не понял и согласен с Флексом - вместо велосипеда пиши безглючные программы... |
|
Сообщ.
#17
,
|
|
 |
Flex Ferrum, если то, что на С++, очень рутинно выглядит, то бывает проще создать над-язык, и из него транслировать в C++... bison, yacc, lex -- вот примеры. Для библиотеки Qt существует moc.
Но эти инструменты не универсальны, они ориентированы лишь на определенный класс задач. Для того, чтобы "ошибок было меньше", не язык создавать надо, а инструмент, который будет проверять на предмет наиболее распространенных ошибок. Но и такой есть -- splint, не знаю лишь, для плюсов ли он... |
|
Сообщ.
#18
,
|
|
|
|
Цитата Flex Ferrum @ prografix, а может быть попробовать научиться на С++ более надежные программы писать? Да и что ты понимаешь под "более надежные программы с меньшим количеством ошибок"? Тут уже, по моему, все от кривизны рук программиста зависит, а не от мощности транслятора/компилятора... Да, конечно, от программиста много зависит, но как заметил ошибки бывают у всех ( в разном к-ве ). Примеры ошибок которые может отловить компилятор - использование неинициализируемой переменной, выход за пределы массива. -юсртыхэю Цитата Kutushut @ Их пишешь ты сам или ты хочешь учить других своему языку? Это прямо как у Буча - ООП круче процедурного подхода, потому как меньше ошибок. Т.е. рекламный слоган, а не ответ на вопрос. Так в чем ссуть-то? Это будет С++ с очень строгой типизацией и запретом преобразования? Или это будет своя грамматика? И в чем все-таки преимущества этого языка? Пока я не понял и согласен с Флексом - вместо велосипеда пиши безглючные программы... Я пишу программы на С++ и мне нужен инструмент для того чтобы писать их с меньшим к-вом ошибок. Если этот инструмент будет нужен не только мне, то я его с удовольствием представлю. На остальные вопросы отвечу завтра. |
|
Сообщ.
#19
,
|
|
|
|
Цитата Kutushut @ Так в чем ссуть-то? Это будет С++ с очень строгой типизацией и запретом преобразования? Или это будет своя грамматика? И в чем все-таки преимущества этого языка? Пока я не понял и согласен с Флексом - вместо велосипеда пиши безглючные программы... Что будет ещё не ясно т.к. нет окончательного проекта. На первых порах цели следующие: 1) убрать неопределённости характерные для С 2) ввести контроль за использованием неинициализируемых переменных 3 ) контроль за выходом за пределы массива |
|
Сообщ.
#20
,
|
|
|
|
Цитата Ho Im @ если то, что на С++, очень рутинно выглядит, то бывает проще создать над-язык То ли он играет в партизана, то ли цель у человека - тулзой закрыть свои баги. Имхо для этого новый язык не нужен... Цитата prografix @ Я пишу программы на С++ и мне нужен инструмент для того чтобы писать их с меньшим к-вом ошибок. Мне кажется это несколько странным... Когда я трезво оценил свой уровень владения С++, я начал усиленно учиться, а не создавать тулзы для облегчения жизни. Не скажу что сейчас этим разочарован. Цитата prografix @ Что будет ещё не ясно т.к. нет окончательного проекта. Как ты пишешь-то без проекта? Пойду язык напишу, но даже не знаю что за язык?  Цитата prografix @ 1) убрать неопределённости характерные для С Можно их просто не использовать. Цитата prografix @ 2) ввести контроль за использованием неинициализируемых переменных Если ты объявляешь переменную без инициализации gcc c Wall ругается. VC 7.1 кажется тоже. Цитата prografix @ 3 ) контроль за выходом за пределы массива C++ - надо использовать STL. Хотя если используешь массивы - действительно полезная фича. Все же мне кажется тебе стоит делать парсер, который проверяет код на C++ - так оно нагляднее и другим может быть полезно. |
|
Сообщ.
#21
,
|
|
|
|
Kutushut
Я понял, что ты мне советуешь, но остался при своём мнении ( как обычно и бывает ). Поэтому продолжаю разработку в том виде, как я её представляю. По мере готовности буду выкладывать информацию. Кстати, Страуструп стал делать С++, потому-что С его не устраивал. А меня не совсем устраивает С++. |
|
Сообщ.
#22
,
|
|
 |
Цитата prografix @ 1) убрать неопределённости характерные для С А что конкретно ты имеешь в виду? Цитата prografix @ 3 ) контроль за выходом за пределы массива Как ты себе этот контроль представляешь? В частности, вот в такой ситуации:   //... void foo(int* someArray) { someArray[2345] = 100; } //... int array[20]; foo(array); с учетом того, что foo и фрагменты кода, ее использующие, могут быть в разных еденицах трансляции. Добавлено Цитата prografix @ Я понял, что ты мне советуешь, но остался при своём мнении ( как обычно и бывает ). Поэтому продолжаю разработку в том виде, как я её представляю. Как бы не получилось, что закончив разработку и подняв свой уровень владения С++, ты бы не подумал про себя - "а нафига я все это сделал?"  |
|
Сообщ.
#23
,
|
|
|
|
Цитата prografix @ Кстати, Страуструп стал делать С++, потому-что С его не устраивал. А меня не совсем устраивает С++. Тут могу только пожелать удачи. Но я вижу некоторую разницу. Страуструп внедрял новую концепцию, ты же говоришь про то, что язык не дает тебе программировать без ошибок. Описания (я уж не говорю про формальное) языка ты тоже не даешь. Надеюсь, у тебя все же выйдет что-нибудь путное Добавлено Цитата Flex Ferrum @ Как бы не получилось, что закончив разработку и подняв свой уровень владения С++, ты бы не подумал про себя - "а нафига я все это сделал?" Я так понял - у каждого свой путь |
|
Сообщ.
#24
,
|
|
|
|
prografix, кстати, а почему бы не взять C#?
|
|
Сообщ.
#25
,
|
|
 |
Цитата prografix, кстати, а почему бы не взять C#? оооо, да!! вот это чудо мы еще не обсуждали!! лично мне он совершенно не равиться!! ни туда и не сюда! супер гебрид! :)фу...prografix, а как будем делать парсинг модульный? т.е. редактор(один .exe) посылает содержимое страници в библу ну или в .exe? |
|
Сообщ.
#26
,
|
|
|
|
Цитата maxim84_ @ prografix, а как будем делать парсинг модульный? т.е. редактор(один .exe) посылает содержимое страници в библу ну или в .exe? maxim84_, я тебя не понял. Надеюсь приложение, которое ты делаешь, называется Translator? :-) |
|
Сообщ.
#27
,
|
|
|
|
Цитата Flex Ferrum @ Цитата prografix @ 1) убрать неопределённости характерные для С А что конкретно ты имеешь в виду? Вот три примера: 1) размер типов в байтах 2) char может знаковым, а может нет 3) результат оператора % когда один из операндов - отрицательное число зависит от реализации. В стандарте часто есть фраза, что что-то неопределено. Я понимаю, что это сделано для эффективности, но надёжность при этом страдает. -юсртыхэю Цитата Flex Ferrum @ Цитата prografix @ 3 ) контроль за выходом за пределы массива Как ты себе этот контроль представляешь? В частности, вот в такой ситуации: //... void foo(int* someArray) { someArray[2345] = 100; } //... int array[20]; foo(array); с учетом того, что foo и фрагменты кода, ее использующие, могут быть в разных еденицах трансляции. Да, именно с такими случаями я собираюсь бороться. Детали пока прорабатываются. -юсртыхэю Цитата Flex Ferrum @ prografix, кстати, а почему бы не взять C#? Мне нужен именно С++. Кроме того, я считаю, что С++ - самый лучший язык современности. Но можно улучшить и его. |
|
Сообщ.
#28
,
|
|
|
|
prografix
если Цитата prografix @ Мне нужен именно С++. то при чем тут Цитата prografix @ убрать неопределённости характерные для С ? Не пользуйся ими, пользуйся только средствами С++. Большинство проблем уйдет, особенно если ты будешь пользоваться исключительно стандартной библиотекой, а не самопальными велосипедами. Ошибки уйдут на другой уровень, который новым языком все равно не охватишь. А когда ты вернешься к низкоуровневым способам (если вернешься) - ты не будешь делать все эти ошибки, которые делаешь сейчас Добавлено Цитата prografix @ я считаю, что С++ - самый лучший язык современности Мне тоже С++ нравится. Поэтому я его изучаю. Улучшать буду потом, когда буду все знать |
|
Сообщ.
#29
,
|
|
|
|
Цитата prografix @ 1) размер типов в байтах 2) char может знаковым, а может нет 3) результат оператора % когда один из операндов - отрицательное число зависит от реализации. В стандарте часто есть фраза, что что-то неопределено. Я понимаю, что это сделано для эффективности, но надёжность при этом страдает. Не только эффективности, но и портабельности. Тем более, что никто не мешает тебе typedef-ами ввести ряд платформенно-зависимых типов и пользоваться ими. Деление по модулу на отрицательное число - ну, гм, а ты что хотел? Тем более, что это зависит не от компилятора, а от того, как процессор переварит исходные данные. Ну а неопределенности - что и как нужно программировать, чтобы наступать на UB? Цитата prografix @ Да, именно с такими случаями я собираюсь бороться. Детали пока прорабатываются. А чем std::vector не угодил? В любом случае провека будет runtime... |
|
Сообщ.
#30
,
|
|
|
|
Цитата Flex Ferrum @ А чем std::vector не угодил? В любом случае провека будет runtime... А хотелось бы на этапе компиляции. Может пройти год, а потом произойдёт ошибка. А ещё у вектора нежелательно брать адрес элемента. Конечно, если не менять размер, то будет всё нормально, а вдруг кто-то поменяет? |
1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,0569 ] [ 14 queries used ] [ Generated: 18.07.25, 01:21 GMT ]