Несколько вопросов по FreePascal (скорее опрос некий)
Модератор: Модераторы
Несколько вопросов по FreePascal (скорее опрос некий)
есть у меня к вам несколько вопросов любопытства ради
1. Оправдано ли для вас использование индексации массивов не с нуля? Зачастую индексация ваших массивов начинается с нуля или же с других значений?
2. Часто ли используете множества, кроме объявлений массивов?
3. Используете ли var в параметрах функции или всё же предпочитаете указатели?
4. Пользуетесь ли ООП? Если да, то чем вас не устраивают модули? Какие вы видите различия между модулями и ООП?
5. Почему выбрали фрипаскаль, а не оберон, оберон-2 или компонентный паскаль?
1. Оправдано ли для вас использование индексации массивов не с нуля? Зачастую индексация ваших массивов начинается с нуля или же с других значений?
2. Часто ли используете множества, кроме объявлений массивов?
3. Используете ли var в параметрах функции или всё же предпочитаете указатели?
4. Пользуетесь ли ООП? Если да, то чем вас не устраивают модули? Какие вы видите различия между модулями и ООП?
5. Почему выбрали фрипаскаль, а не оберон, оберон-2 или компонентный паскаль?
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
1) вполне.
2) Нечасто.
3) не люблю ссылок.
4) Модули и ООП это абсолютно разные понятия. Модули это всего лишm правила по складsванию частей программы, а объекты ets. это конструкции языка.
5) нашел пакеты под свою систему только для fpc. Соответственно, не было даже выбора.
2) Нечасто.
3) не люблю ссылок.
4) Модули и ООП это абсолютно разные понятия. Модули это всего лишm правила по складsванию частей программы, а объекты ets. это конструкции языка.
5) нашел пакеты под свою систему только для fpc. Соответственно, не было даже выбора.
1. Чаще всего с 0 (тем более для динамических по другому и не бывает), но в некоторых случаях не с 0, особенно там, где так удобнее для конкретного алгоритма.
2. Не очень часто, но это в первую очередь из-за ограничения самого паскалевского множества.
3. Обычно все параметры помечаю как Const, Out, Var, либо без префикса. Указатели передают только в редких случаях, когда действительно нужно передать указатель в явном виде.
4. Модуль - это файл на диске. Класс (объект) - это элемент программы. Учитывая недостатки глобальных переменных, то там где есть функции и связанные с ними данные, то лучше класс. Если нужна просто процедура - обработчик, то можно использовать модули без классов, это иногда удобно, когда нужно обрабатывать классы, которые в свою очередь наследуются. Итого: и то и другое - это хорошо.
5. Исторически знал вначале Turbo Pascal, затем Delphi, затем Free Pascal, затем Lasarus. Про Модулу-2 знал давно (с начала 90х), но не имел хорошего дистрибутива. Про оберон узнал только во второй половине 200х.
2. Не очень часто, но это в первую очередь из-за ограничения самого паскалевского множества.
3. Обычно все параметры помечаю как Const, Out, Var, либо без префикса. Указатели передают только в редких случаях, когда действительно нужно передать указатель в явном виде.
4. Модуль - это файл на диске. Класс (объект) - это элемент программы. Учитывая недостатки глобальных переменных, то там где есть функции и связанные с ними данные, то лучше класс. Если нужна просто процедура - обработчик, то можно использовать модули без классов, это иногда удобно, когда нужно обрабатывать классы, которые в свою очередь наследуются. Итого: и то и другое - это хорошо.
5. Исторически знал вначале Turbo Pascal, затем Delphi, затем Free Pascal, затем Lasarus. Про Модулу-2 знал давно (с начала 90х), но не имел хорошего дистрибутива. Про оберон узнал только во второй половине 200х.
1. Да. Чаще с нуля.
2. Часто
3. По указателю передаю редко. По необходимости.
4. Постоянно. Не мешайте теплое с зеленым. Модули нужны для разбиения кода, разбрасывания его удобными частями, выделяя переиспользуемые части.
5. Он развивается, он позволяет легко перейти с Делфи, используя наработаные навыки и личные библиотеки кода. Оберон и прочее - это уже некая экзотика, о которой слышал, но ни разу не использовал и слабо представляю себе, где его используют. На фпц пишутся коммерческие проекты, на обероне - хз.
2. Часто
3. По указателю передаю редко. По необходимости.
4. Постоянно. Не мешайте теплое с зеленым. Модули нужны для разбиения кода, разбрасывания его удобными частями, выделяя переиспользуемые части.
5. Он развивается, он позволяет легко перейти с Делфи, используя наработаные навыки и личные библиотеки кода. Оберон и прочее - это уже некая экзотика, о которой слышал, но ни разу не использовал и слабо представляю себе, где его используют. На фпц пишутся коммерческие проекты, на обероне - хз.
2) объявление массива не использует множества. Для индекса используется интервал типа. Квадратные скобки или их триграф "(."/".)" являются частью синтаксиса, но не множеством. Возможно, понял неправильно и имелось в виду что-то другое?
dedm0zaj писал(а):1. Оправдано ли для вас использование индексации массивов не с нуля? Зачастую индексация ваших массивов начинается с нуля или же с других значений?
Стараюсь не использовать странные индексации массивов, поскольку прекрасно понимаю, что меня ждет при попытке перевести такой код на "не-паскаль"
dedm0zaj писал(а):2. Часто ли используете множества, кроме объявлений массивов?
Объявления массивов к множествам никакого отношения не имеют. Множества не использую из-за практической неприменимости этого типа в реализации паскаля.
dedm0zaj писал(а):3. Используете ли var в параметрах функции или всё же предпочитаете указатели?
Использую. Ибо var не есть замена указателям, у того и другого разные назначения.
dedm0zaj писал(а):4. Пользуетесь ли ООП? Если да, то чем вас не устраивают модули? Какие вы видите различия между модулями и ООП?
Здрасьте. Модули и ООП - абсолютно разные понятия. И путать их может какой нить фокспрошник разве. Да, пользуемся ООП.
dedm0zaj писал(а):5. Почему выбрали фрипаскаль, а не оберон, оберон-2 или компонентный паскаль?
Ви серьезно считаете, что есть выбор?
Вот это вами перечисленное, оно imho, кроме чисто академической значимости, хоть для кого нибудь представляет практический интерес? Вообще с точки зрения, что мне больше нравится - так вот мне больше нравится C#. А вот фрипаскаль - потому что есть куча старых текстов, которые периодически нужны и подогнать их под нынешний фрипаскаль проще и быстрее, чем практически заново переписывать под язык программирования другой идеологии.
dedm0zaj
1. Оправдано. Хотя и довольно редко этим пользуюсь. Иногда возникают случаи, когда нужно брать некий диапазон именно с ненулевым началом, чтобы не вводить дополнительную переменную и кода согласования её с индексом массива.
2. Не помню, когда последний раз использовал. Хотя помню, что когда-то использовал.
3. Поскольку я не любитель Си и на Паскаль перешёл вовсе не с Си, то использование var для меня вешь вполне естественная, если нужно перебаламутить какой-то параметр. Однако предпочитаю функции, которые на выходе дают нужный мне параметр.
4. Вопрос не понял. У меня к Вам встречный вопрос - а Вы сами то поняли, что сказали? Вы давно занялись программированием? Сколько дней назад?
5. Понравился синтаксис. Хотя нет, не так. Ко мне подошла сотрудница - юная и очаровательная девушка и попросила помочь ей с учебным заданием для института, которое она делала на TurboPascal.
Хотя я тогда этого языка не знал совершенно, но по синтаксису он оказался близок FoxPro, на котором я тогда работал. Поэтому разобрался довольно быстро.
Компилятор был доступен, в отличие от Оберонов и прочих Модулов с Адами.
1. Оправдано. Хотя и довольно редко этим пользуюсь. Иногда возникают случаи, когда нужно брать некий диапазон именно с ненулевым началом, чтобы не вводить дополнительную переменную и кода согласования её с индексом массива.
2. Не помню, когда последний раз использовал. Хотя помню, что когда-то использовал.
3. Поскольку я не любитель Си и на Паскаль перешёл вовсе не с Си, то использование var для меня вешь вполне естественная, если нужно перебаламутить какой-то параметр. Однако предпочитаю функции, которые на выходе дают нужный мне параметр.
4. Вопрос не понял. У меня к Вам встречный вопрос - а Вы сами то поняли, что сказали? Вы давно занялись программированием? Сколько дней назад?
5. Понравился синтаксис. Хотя нет, не так. Ко мне подошла сотрудница - юная и очаровательная девушка и попросила помочь ей с учебным заданием для института, которое она делала на TurboPascal.
Компилятор был доступен, в отличие от Оберонов и прочих Модулов с Адами.
dedm0zaj писал(а):есть у меня к вам несколько вопросов любопытства ради
1. Оправдано ли для вас использование индексации массивов не с нуля? Зачастую индексация ваших массивов начинается с нуля или же с других значений?
2. Часто ли используете множества, кроме объявлений массивов?
3. Используете ли var в параметрах функции или всё же предпочитаете указатели?
4. Пользуетесь ли ООП? Если да, то чем вас не устраивают модули? Какие вы видите различия между модулями и ООП?
5. Почему выбрали фрипаскаль, а не оберон, оберон-2 или компонентный паскаль?
1. Чаще всего или с нуля или по типу множества.
2. Не сказал бы что часто, но постоянно.
3. только var если возможно.
4. Да внутренний дизайн - 90% ООП кроме редких мелких процедур. Модуль - это более высокий уровень организации в общем-то _часть_ ООП.
5. Преемственность наверное- TP-DELHPI-FPC.
1. не оправдано, если только для совместимости с чемлибо
2. не использую
3. зависит от ситуации. var для простых переменных, указатель для сложных структур или если в вызывающую процедуру данный параметр уже пришел как указатель, ну и если нужно иногда NIL передавать
3. ООП пользую и к месту и не к месту. ИМХО это 2 совершенно разных человека)).
4. со времен TP паскаль казался простым и логичным, "оберон, оберон-2 или компонентный паскаль" в нашем колхозе про таких не слыхали
2. не использую
3. зависит от ситуации. var для простых переменных, указатель для сложных структур или если в вызывающую процедуру данный параметр уже пришел как указатель, ну и если нужно иногда NIL передавать
3. ООП пользую и к месту и не к месту. ИМХО это 2 совершенно разных человека)).
4. со времен TP паскаль казался простым и логичным, "оберон, оберон-2 или компонентный паскаль" в нашем колхозе про таких не слыхали
2. на счёт второго пункта признаю неправоту. множества там вовсе не при чём.
4. почему я сравниваю модули и ООП? сейчас объясню.
для начала хочу сказать, что буду оперировать такими понятиями, как абстракция и объект (не объект класса).
за объект я буду принимать некую конкретную сущность, за абстрактную - эммм... абстрактную сущность.
ну допустим класс это абстрактная вещь, а объект класса это уже вполне себе конкретная вещь, которую можно пощупать.
или, например, переменная это конкретная вещь, а её тип - абстракция.
теперь давайте возьмём один экземпляр класса. не сам класс, а экземпляр, т.е объект, полученный от класса. и рассмотрим его поближе.
из чего он состоит? он состоит из полей и методов. часть полей и методов (а зачастую - только часть методов) располагаются в зоне, видимой для внешней части программы, а другая часть - в невидимой. другими словами, объект класса имеет область привата и публичную область. и только. у класса есть ещё защищённая область, но она нужна при наследовании, а конкретный объект класса с наследованием уже не работает. классы наследуют друг друга, но не объекты класса.
полиморфизм также свойственен объектам класса, т.е перегруженность функций.
в итоге получаем, что для объекта класса свойственны инкапсуляция и полиморфизм, но не наследование.
теперь рассмотрим модуль. что мы имеем? модуль не абстракция. это вполне себе объект в виде файла.
когда мы пишем uses unit_1, то, грубо говоря, даём ссылку на файл с модулем - ссылку на конкретный объект.
у модуля есть зона, видимая для внешнего мира программы, и закрытая зона, как по аналогии с приватной и публичной зоной объекта класса. т.е выполняется условие инкапсуляции.
перегрузка функций также присутствует, что говорит о полиморфизме.
и есть даже некое подобие конструктора, т.е начальные действия модуля сразу после его вызова.
как видно, объект класса (не сами классы) и модули очень похожи. да не то, что похожи, они практически идентичны.
пожалуй по этой причине я сравниваю ООП с модулями.
но я продолжу свои рассуждения.
можно сказать, что классы это тип данных. об это говорит то, что классы объявляются в зоне type, и то, что класс указывается, как тип переменной при её объявлении.
класс это абстракция. тип данных это тоже абстракция. при объявлении переменной типа класса мы получаем объект - переменная-объект (объект класса).
как выяснили раньше, объект класса мало чем отличается от модуля. т.е, если сказать грубо, то класс это абстракия модуля, т.е класс это тип модуля.
новый тип в программировании - тип модуля, который почему то назвалии классами.
это буквально то же самое, что если бы мы могли сделать такое:
4. почему я сравниваю модули и ООП? сейчас объясню.
для начала хочу сказать, что буду оперировать такими понятиями, как абстракция и объект (не объект класса).
за объект я буду принимать некую конкретную сущность, за абстрактную - эммм... абстрактную сущность.
ну допустим класс это абстрактная вещь, а объект класса это уже вполне себе конкретная вещь, которую можно пощупать.
или, например, переменная это конкретная вещь, а её тип - абстракция.
теперь давайте возьмём один экземпляр класса. не сам класс, а экземпляр, т.е объект, полученный от класса. и рассмотрим его поближе.
из чего он состоит? он состоит из полей и методов. часть полей и методов (а зачастую - только часть методов) располагаются в зоне, видимой для внешней части программы, а другая часть - в невидимой. другими словами, объект класса имеет область привата и публичную область. и только. у класса есть ещё защищённая область, но она нужна при наследовании, а конкретный объект класса с наследованием уже не работает. классы наследуют друг друга, но не объекты класса.
полиморфизм также свойственен объектам класса, т.е перегруженность функций.
в итоге получаем, что для объекта класса свойственны инкапсуляция и полиморфизм, но не наследование.
теперь рассмотрим модуль. что мы имеем? модуль не абстракция. это вполне себе объект в виде файла.
когда мы пишем uses unit_1, то, грубо говоря, даём ссылку на файл с модулем - ссылку на конкретный объект.
у модуля есть зона, видимая для внешнего мира программы, и закрытая зона, как по аналогии с приватной и публичной зоной объекта класса. т.е выполняется условие инкапсуляции.
перегрузка функций также присутствует, что говорит о полиморфизме.
и есть даже некое подобие конструктора, т.е начальные действия модуля сразу после его вызова.
как видно, объект класса (не сами классы) и модули очень похожи. да не то, что похожи, они практически идентичны.
пожалуй по этой причине я сравниваю ООП с модулями.
но я продолжу свои рассуждения.
можно сказать, что классы это тип данных. об это говорит то, что классы объявляются в зоне type, и то, что класс указывается, как тип переменной при её объявлении.
класс это абстракция. тип данных это тоже абстракция. при объявлении переменной типа класса мы получаем объект - переменная-объект (объект класса).
как выяснили раньше, объект класса мало чем отличается от модуля. т.е, если сказать грубо, то класс это абстракия модуля, т.е класс это тип модуля.
новый тип в программировании - тип модуля, который почему то назвалии классами.
это буквально то же самое, что если бы мы могли сделать такое:
Код: Выделить всё
uses unit_1;
type
MyUnit = unit_1;
var
ObjMyUnit: MyUnit;
ArrObjMyUnit: array[1..10] of MyUnit;
dedm0zaj писал(а):это буквально то же самое, что если бы мы могли сделать такое
А поскольку мы такого сделать не можем, следовательно это не тоже самое.
Пользуясь неверной логикой можно найти что угодно где угодно.
Вы, главное, не забывайте, что class - это тип данных. С ним Вы делаете толькео те процедуры, которые применимы к типу данных. Например, приведение к типу. Вы с модулем то же самое можете сделать? Вот то-то.
Модуль - это всего-лишь дополнительный кусок кода, в котором может быть всё, что угодно. Но, самое главное, это не определённый тип, это - именно кусок кода и не более того.
Vadim писал(а):Вы, главное, не забывайте, что class - это тип данных. С ним Вы делаете толькео те процедуры, которые применимы к типу данных. Например, приведение к типу. Вы с модулем то же самое можете сделать? Вот то-то.
Модуль - это всего-лишь дополнительный кусок кода, в котором может быть всё, что угодно. Но, самое главное, это не определённый тип, это - именно кусок кода и не более того.
согласен с тем, что с точки зрения формальности языка это разные вещи.
но если взглянуть на суть, т.е то, зачем мы юзаем модули или объекты, то для меня это практически одинаковые вещи.
зачем я использую модули? чтобы выделить в определённое место логически завершённую часть кода, отвечающего за определённые действия. эта часть целостна сама по себе. в ней скрыта основная работа и открыт только интерфейс.
такой частью может быть окно, таймер, рендеринг, сцена и т.д.
а потом берём эти части и учим взаимодействовать вместе.
а что в объектах? да то же самое. суть их использовния та же.
мы используем одну суть разными методами.
может быть я чего то не допонимаю.
dedm0zaj писал(а):зачем я использую модули? чтобы выделить в определённое место логически завершённую часть кода, отвечающего за определённые действия. эта часть целостна сама по себе. в ней скрыта основная работа и открыт только интерфейс.
такой частью может быть окно, таймер, рендеринг, сцена и т.д.
а потом берём эти части и учим взаимодействовать вместе.
а что в объектах? да то же самое. суть их использовния та же.
Заблуждение.
Модули нужны исключительно для того, чтобы не запихивать в один файл всё подряд. И не обязательно один модуль предназначен для
dedm0zaj писал(а):чтобы выделить в определённое место логически завершённую часть кода
там могут располагаться некие объёмы именно логически незавершённой части кода. Например, коды клавиш клавиатуры. В коде основной программы это нагромождение цифросимволов выглядело бы уродством, затрудняющим сопровождение этого самого кода. А вот выделив их в отдельный модуль, в коде основной программы можно сразу глядеть в суть. Согласитесь, сами по себе коды клавиш, как их не разглядывай, никоим образом "логически завершённым кодом" не выглядят.
А вот класс (объект) - это действительно, логически завершённый кусок кода, который как раз и занимается тем, что берёт данные, обрабатывает их и выдаёт наружу. К модулям это применимо даже не в большинстве случаев.
Если бы это утверждение было верным, то не было бы необходимости в отдельных областях видимости в модулях, в интерфейсной части и части реализации.Vadim писал(а):Заблуждение. Модули нужны исключительно для того, чтобы не запихивать в один файл всё подряд.
Для "не запихивать" отдельное средство давно есть, включение файла, {$I somefile.pas}.
