PIC: Можно, я пока на Паскале?, если что, снесите в флудилку |
Здравствуйте, гость ( Вход | Регистрация )
PIC: Можно, я пока на Паскале?, если что, снесите в флудилку |
10.12.2011, 20:15
Сообщение
#21
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
В чём упростила? В чём вообще там "особая паскалевская идеология" и чем она принципиально отличается от сишной? Чем вообще принципиально ЯП С отличается от ЯП Паскаль? Кроме синтаксиса, конечно. Дык, в синтаксисе и дело-то. Ну не получается у меня мысленно проговаривать то, что по умолчанию подразумевается под пробелом или парой запятых подряд, на месте которых в случае, отличном от умолчания, что-то должно было бы быть. Пишущему это жизнь облегчает. Но я собираюсь читать после написанное, для проверки... Паскаль - многа букафф, но я нормально набираю на клаве, быстро. А зрение не очень, отдельно точку-запятую могу и проглядеть. Что до строгости - когда-то они отличались, но с тех пор Си много взял от Паскаля, если не ошибаюсь? Что попало чему попало уже не присвоишь, так? Значит, можно после и на Си, просто пока кажется легче так, как получается... |
|
|
10.12.2011, 20:16
Сообщение
#22
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Кстати, сегодня уже можно смело вместо С подставлять С++, т.к. этот ЯП уже уверенно и прочно занял все ниши С. А зачем? ПМСМ, не всегда это надо. Мы же уже где-то это обсуждали... Пока нет большого количества наработок, коллектива разработчиков, дядиных отработанных классов или сложной иерархической системы, С++ никаких преимуществ по отношению к С не имеет. Да и грамотно разработать класс дано не каждому. |
|
|
10.12.2011, 21:40
Сообщение
#23
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Большие реки начинаются с малых ручейков. © Паскаль Блез, сирота. Цитата «Человек, несомненно, сотворён для того, чтобы думать: в этом и главное его достоинство, и главное дело жизни, а главный долг в том, чтобы думать благообразно. И начать ему следует с размышлений о себе самом» Паскаль, «Мысли», 146 «Пусть не корят меня за то, что я не сказал ничего нового: ново уже само расположение материала; игроки в мяч бьют по одному и тому же мячу, но не с одинаковой меткостью. С тем же успехом меня могут корить и за то, что я употребляю давным-давно придуманные слова. Стоит расположить уже известные мысли в ином порядке – и получится новое сочинение, равно как одни и те же, но по-другому расположенные слова образуют новые мысли» Паскаль, «Мысли»,22 А что по этому поводу говорил товарищ Си ? |
|
|
10.12.2011, 22:00
Сообщение
#24
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Вы какой паскаль имеете в виду? Стандартный образца 1983 года? А другого-то и нет. Цитата In 1983, the language was standardized, in the international standard IEC/ISO 7185... In 1990, an extended Pascal standard was created as ISO/IEC 10206. In 1993 the ANSI standard was replaced by the ANSI organization with a "pointer" to the ISO 7185:1990 standard, effectively ending its status as a different standard. Цитата В чём упростила? В чём вообще там "особая паскалевская идеология" и чем она принципиально отличается от сишной? Чем вообще принципиально ЯП С отличается от ЯП Паскаль? Кроме синтаксиса, конечно. Работа с boolean, множествами и строками на уровне базовых типов языка. Цитата Кстати, сегодня уже можно смело вместо С подставлять С++ Но это не для традиционных пикофф. |
|
|
10.12.2011, 23:32
Сообщение
#25
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Дык, в синтаксисе и дело-то. Ну не получается у меня мысленно проговаривать то, что по умолчанию подразумевается под пробелом или парой запятых подряд, на месте которых в случае, отличном от умолчания, что-то должно было бы быть. Ну, это дело привычки. У сях для начинающих неприятности от синтаксиса возникают на выражениях типа: int (*p[])(char * s); что в переводе на русский означает массив указателей на функцию, принимающую указатель на char и возвращающую int. С непривычки ломает, конечно. Вся фишка тут в том, что разбор выражения идёт не слева направо, а изнутри. Т.е. ищется самое внутренне подвыражение - в данном случае это имя p, от него и все танцы. Потом идёт разбор по правилам - сначала правые операторы, потом левые. В нашем случае справа оператор массива, значит р - это массив. Далее, справа ничего больше нет (скобка заканчивается), тогда смотрим налево - там оператор разыменовывания, т.е. наш объект имеет тип указателя, а т.к. это, как выяснилось выше, массив, то получаем массив указателей. В скобках разобрали, выходим за скобки, снова смотрим вправо - там оператор функции (скобки круглые), значит у нас это массив указателей на функцию с указанным типом аргумента. Ну, и финально - функция возвращает целое. Вуаля. Но никто не заставляет такие выражения сходу использовать. И без них можно писать успешные программы. И до таких объектов дело дойдёт. Больше там синтаксических извратов особо и нет. А вот семантических нюансов полно, я их и имел в виду. Одни нюансы на стандартных преобразованиях чего стоят. Над этим надо немного помедитировать. Что до строгости - когда-то они отличались, но с тех пор Си много взял от Паскаля, если не ошибаюсь? Что попало чему попало уже не присвоишь, так? Значит, можно после и на Си, просто пока кажется легче так, как получается... Скорее С взял не от Паскаля, а от С++. Обязательность прототипов функций, запрет на неявное преобразование указателей в числовые типы и обратно и прочее. Пока нет большого количества наработок, коллектива разработчиков, дядиных отработанных классов или сложной иерархической системы, С++ никаких преимуществ по отношению к С не имеет. Да и грамотно разработать класс дано не каждому. Это вы зря. Где уместен С, уместен и С++. Уже хотя бы за более строгий контроль типов и более удобные и безопасные языковые конструкции - например, возможность объявлять объект в точке первого использования, внятные перечислимые типы и т.д. Оверхеда С++ по сравнению с С не даёт практически никакого. Работа с boolean, множествами и строками на уровне базовых типов языка. И чем так boolean кашернее обычного целого типа с проверкой на ноль-не ноль? А вот работа со строками - это палка о двух концах, ибо оверхед, причём неконтролируемый. То же самое касается и массивов в Паскале, которые имеют рантаймные проверки на выход за границы. Да, это добавляет безопасности в некоторой степени (хотя ну кто будет в мелком МК анализировать что там за runtime error такая возникла), но безальтернативно жрёт ресурс. Куда более правильный подход в плюсах - хочешь юзать с проверками - велком, но знаешь за что платишь. Не нравится, не юзай или переделай имплементацию, благо сорцы все доступны. Что касается стандартов, то их наличие ни о чём не говорит. Стандарт 1983 года вводит язык, пригодный для какого-то обучения, но совершенно непригодный для практического использования. С более поздними стандартами не знаком, но есть подозрение, что и там дело не сильно изменилось в лучшую сторону, иначе некоторые фирмы не стали бы по собственной инициативе разрабатывать свои проприетарные реализации (Object Pascal и иже с ним), которые живут на одной платформе (т.е. ни переносимости, ни расширяемости). Сам по себе Паскаль принципиально мало отличается от С. Оба низкоуровневые императивные языки программирования. Но один был разработан для обучения, поэтому прост и незамысловат (чем и снискал популярность), второй был выдвинулся как средство разработки реальной большой ОС (UNIX), поэтому был более приспособлен к реальным задачам. Паскаль легко было бы развить до функционала С, для этого достаточно было бы ввести в него поддержку раздельной компиляции, работу с указателями, адресную арифметику и стандартные преобразования типов. Но это был бы тот же С с пасальным синтаксисом. Кстати, та же дельфа почти всего этого достигла, что подтверждает, что указанное реально вполне достижимо. Но это не для традиционных пикофф. Ну, если речь про них, то про плюсы умолкаю. |
|
|
11.12.2011, 3:10
Сообщение
#26
|
|
тот самый Группа: Мод Сообщений: 13629 Регистрация: 24.11.2009 Из: Харьковская обл., UA Пользователь №: 25 |
Паскаль легко было бы развить до функционала С, для этого достаточно было бы ввести в него поддержку раздельной компиляции, работу с указателями, адресную арифметику и стандартные преобразования типов. Но это был бы тот же С с пасальным синтаксисом. Кстати, та же дельфа почти всего этого достигла, что подтверждает, что указанное реально вполне достижимо. Тут фокус в другом. Во-первых, все указанное уже было там сразу, даже начиная с прадедушки модулы-2. Во вторых, есть грани, которые являются непреодолимым водоразделом, например, для чего нужны указатели? Если в Си под *ptr++ = value; понимается ни что иное, как запись в память по указателю с постинкрементом оного, то в Паскале этого не надо - вполне достаточно доступа к массиву через индекс, ибо компилятору хватит информации для того, чтобы оптимизировать обращения до уровня сишного. Только лишь потому, что паскаль - проблемно-ориентированный язык! Компилер паскаля легче заточить под платформу, да еще так, что он переплюнет си в крайних случаях, просто этим мало кто занимается, - именно из-за того, что там больше свободы интерпретации, ибо внешне похожие на си конструкции намного дальше от машинного представления. Помирить два направления может "D", но он какой-то взбаламученный Или, например, процедуры текстового вывода read/write. Кто сказал, что неопределенное кол-во аргументов обязательно будет передано через стек? Они ж ведь давно builtin. В общем, букафф много, мечтать не вредно. Питон какой-то...блин. Паскаль! |
|
|
11.12.2011, 5:48
Сообщение
#27
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Все интереснее и интереснее...
А я все стеснялся спросить, для чего вообще нужны указатели, а оно вона как... Вот почему я не понимал, для чего... внешне похожие на си конструкции намного дальше от машинного представления. «З цього місця, будь ласка, з подробицями, шановний Альфреде Юхимович.»© |
|
|
11.12.2011, 8:28
Сообщение
#28
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Тут фокус в другом. Во-первых, все указанное уже было там сразу, даже начиная с прадедушки модулы-2. То да не то. Такой низкоуровневой концепции там нигде не было, там везде использовалось то, что правильнее назвать ссылками. Во вторых, есть грани, которые являются непреодолимым водоразделом, например, для чего нужны указатели? Если в Си под *ptr++ = value; понимается ни что иное, как запись в память по указателю с постинкрементом оного, то в Паскале этого не надо - вполне достаточно доступа к массиву через индекс, ибо компилятору хватит информации для того, чтобы оптимизировать обращения до уровня сишного. Это очень узкая интерпретация, понятие указателя в С много шире. Указатель в С - это типизированный адрес, и работа с массивами - это только весьма ограниченная область применения указателей. Только лишь потому, что паскаль - проблемно-ориентированный язык! Компилер паскаля легче заточить под платформу, да еще так, что он переплюнет си в крайних случаях, просто этим мало кто занимается, - именно из-за того, что там больше свободы интерпретации, ибо внешне похожие на си конструкции намного дальше от машинного представления. Паскаль не более проблемно-ориентированный язык, чем С. И никого он там не переплюнет, т.к. как уже было сказано, языки эти одного калибра (уровня - низкоуровневые императивные). Паскаль выигрывает у С за счёт более простого синтаксиса, но проигрывает из-за [искусственной] ограниченности. Технически ничего не мешает довести Паскаль по возможностям до уровня С (только сегодня это уже никому не надо), а С - синтаксически до уровня Паскаля (только при этом потеряется совместимость, поэтому тоже никому не надо). Но резону уже нет, поэтому всё остаётся на своих местах, и реальность такова, что если хочешь иметь в арсенале кроссплатформенный эффективный язык - изучай С (а ещё правильнее - С++). Помирить два направления может "D", но он какой-то взбаламученный D - несколько другая тема. Этот проект - попытка пофиксить сложности языка С++ ценой потери совместимости. Именно последнее обстоятельство, ихмо, и ставит крест на широком использовании этого языка. Или, например, процедуры текстового вывода read/write. Кто сказал, что неопределенное кол-во аргументов обязательно будет передано через стек? Они ж ведь давно builtin. Вот тут, кстати, подход С/С++ куда более правильный - ни к чему включать в язык прикладные фичи, такие вещи надо реализовывать на уровне библиотек. Это сделает язык лёгким, а реализации гибко подходящими для разных целевых платформ. А иначе вон для PIC16 будьте добры и эти процедуры реализовывать, а то что это за компилятор такой, который не поддерживает встроенные средства языка. В общем, букафф много, мечтать не вредно. Питон какой-то...блин. Паскаль! Да, питон, кстати, замечательный язык. И много лучше паскаля подходит для обучения программированию. |
|
|
11.12.2011, 11:05
Сообщение
#29
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Это очень узкая интерпретация, понятие указателя в С много шире. Указатель в С - это типизированный адрес, и работа с массивами - это только весьма ограниченная область применения указателей. Он же не всегда был типизированным? Изначально это была просто возможность «делать что хочешь», в основном в плане типов? Когда результаты этого беспредела стали доставать - тогда и типизировали. А я все это время не отслеживал, но надо почитать - что там осталось из-за этого от изначальной концепции... А раньше, помнится, было иногда с ними как-то так: продолжай трахать Машу, но помни, что теперь на самом деле это Лена, поэтому получается, что ты трахаешь уже Таню. То есть концепция имен переменных иногда немного теряла смысл. |
|
|
11.12.2011, 12:49
Сообщение
#30
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
Он же не всегда был типизированным? Изначально это была просто возможность «делать что хочешь», в основном в плане типов? Когда результаты этого беспредела стали доставать - тогда и типизировали. Тут надо помнить, что С появился как внутренний язык для разработки ОС UNIX и использовался ограниченным кругом разработчиков, которые знали все нюансы про маш, лен и тань вдоль и поперёк. Когда оказалось, что язык получился, несмотря на изрядное количество подводных граблей, удачным и стал популярным, пришлось и пересматривать кое-что. Так появились уже современные правила с требованиями прототипов и контролем типов. А раньше, помнится, было иногда с ними как-то так: продолжай трахать Машу, но помни, что теперь на самом деле это Лена, поэтому получается, что ты трахаешь уже Таню. Ну, вообще-то С всегда был и остаётся портабельным макроассемблером, и первые реализации совсем недалеко ушли от обычных ассемблеров в плане контроля типов, где его нету в принципе. |
|
|
11.12.2011, 13:04
Сообщение
#31
|
|
ДИКТАТОР Группа: Мод Сообщений: 23809 Регистрация: 20.11.2009 Из: Житомир Пользователь №: 3 |
Ну, вообще-то С всегда был и остаётся портабельным макроассемблером, и первые реализации совсем недалеко ушли от обычных ассемблеров в плане контроля типов, где его нету в принципе. Ну, если остается - тогда это ему комплимент. Асм это хорошо для Пиков. Я ж не отказываюсь, просто думаю, как проще начать. АСМ я учу по любому, да и память хорошая, Лену с Таней обычно не путаю, \\* фломастером как-то умудряюсь метки ставить на нужных местах. Как там говорится - глаза боятся, а руки делают. orthodox, сделайте уже хоть что-нибудь на паскале. Раз всё уже куплено и готово. Ну а когда будет не хватать мощи (или красоты, но это в начале пути непонятно), то перейдёте и на Си. Ну и Си обычно генерит меньший код для одинаковых алгоритмов. По крайней мере до милениума так было. За нынешние компиляторы не ручаюсь. Ну, дык я и собираюсь. тут у мну мыслишка такая - сделать на Паскале, а после то же самое тупо перевести на Си, поглядеть какая будет разница и что можно по ходу переписывания сделать проще. После посмотреть на результат компилирования. |
|
|
11.12.2011, 13:59
Сообщение
#32
|
|
Adept Группа: Пользователи Сообщений: 522 Регистрация: 20.4.2011 Из: Novosibirsk Пользователь №: 346 |
тут у мну мыслишка такая - сделать на Паскале, а после то же самое тупо перевести на Си, поглядеть какая будет разница и что можно по ходу переписывания сделать проще. После посмотреть на результат компилирования. Вот это правильная тема, одобряю. Очень интересно узнать конкретный результат из первых рук. |
|
|
11.12.2011, 14:38
Сообщение
#33
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Вот тут, кстати, подход С/С++ куда более правильный - ни к чему включать в язык прикладные фичи, такие вещи надо реализовывать на уровне библиотек. Это сделает язык лёгким, а реализации гибко подходящими для разных целевых платформ. А иначе вон для PIC16 будьте добры и эти процедуры реализовывать, а то что это за компилятор такой, который не поддерживает встроенные средства языка. Здесь спорить не о чем. Безусловно, такой подход на сегодняшний день - самый оптимальный. С одним НО. Программист не должен плодить сущности без нужды. А с таким подходом можно легко к этому скатиться... Тут у меня была небольшая задачка. Я ее решил с помощью компилятора С, обсуждавшегося в соседней теме. Сейчас это дело оформляю. Могу поделиться результатами. Поскольку задачка проста, то она может быть учебным пособием. |
|
|
11.12.2011, 15:26
Сообщение
#34
|
|
Активный участник Группа: Пользователи Сообщений: 422 Регистрация: 11.5.2011 Пользователь №: 360 |
|
|
|
11.12.2011, 15:51
Сообщение
#35
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
|
|
|
11.12.2011, 15:55
Сообщение
#36
|
|
Активный участник Группа: Пользователи Сообщений: 422 Регистрация: 11.5.2011 Пользователь №: 360 |
|
|
|
11.12.2011, 16:05
Сообщение
#37
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
Я думаю уместен... поскольку важен не язык а мастерство владения оным Тумаю, чо большинство не ЫМБЫДЁРОВ здеся... сойдутся на АССАМБЛЕЕ...тьфу ты....на АССЕМБЛЕРЕ Я, таки, сошелся на С с тщательным контролем получившегося кода. И в отдельных случаях Ассемблерными подпрограммами. Иными словами, все, что может быть автоматизировано, должно быть автоматизировано. А все, что требует тщательности, должно исполняться ручками, т. е. на Ассемблере. |
|
|
11.12.2011, 16:25
Сообщение
#38
|
|
Активный участник Группа: Пользователи Сообщений: 422 Регистрация: 11.5.2011 Пользователь №: 360 |
|
|
|
11.12.2011, 16:39
Сообщение
#39
|
|
сундук Группа: Пользователи Сообщений: 4043 Регистрация: 21.11.2009 Из: Ростов-на Дону Пользователь №: 15 |
ессьсесьнно после дизасемблирования двоичного дампа программы? А что смеемся то? Именно так, поскольку при символьном воспроизводстве адресов дампа С-шные имена остаются. Далее все просто - сравниваем отдельные конструкции на С с тем, что получилось в результате компиляции и работы линкера в динамике, посредством симулятора. Именно таким образом работает компилятор С30 от Микрочипа. У него отсутствует промежуточная трансляция в Ассемблер, в отличие от компиляторов МСС18 и РIСС. |
|
|
Гость_MrYuran_* |
11.12.2011, 17:22
Сообщение
#40
|
Гости |
|
|
|
Текстовая версия | Сейчас: 29.3.2024, 13:24 |