Я лично в своём курсе функции, не возвращающие значения. называю процедурами. Потому что разница есть. Их нельзя использовать в выражениях. А ваш подход - это C-шная история
Не только сишная , но и большинства языков. И что кто-то будет пытаться использовать в выражениях то, что не возвращает значения? В чём практический смысл в начале обучения вводить ещё один лишний термин. Тем более мало того, к ним ещё вводят и термина подпрограмма. Итого кучу мусора в голове ещё до того, как человек начал писать код.
Видите - у вас - агрессивная вкусовщина. Это когда вы всех пытаетесь перестроить под себя и не принимаете альтернативных точек зрения.
Есть много разных подходов - в образовании и в обучении в том числе.
Кстати, ваш большой пост я совсем не понял. Прежде всего, я не понял, к какому посту он относится - вы его не цитируете. Я просмотрел несколько постов выше и убедился, что явно не к ним.
По тому что написано:
школьники воспринимают сразу оператор += (увеличить НА). Тут никакого дополнительного обучения не надо - лишь здравый смысл.
Объявление переменной с присваиванием - это базовый примитив:
var a := 0;
Он не требует дополнительного обучения - только здравый смысл.
Лямбда-выражения - чуть более сложный примитив. Наш опыт в обучении школьников говорит о том, что он вполне успешно учится прежде всего как параметр другой функции, в которую надо передать действие, преобразование или условие.
Конечно, можно учить по-всякому.
И где агрессивная? Это из вашенской микросекты постоянно говорят , что “вам с здесь на рады " и " ваш ответ керзнону” . С таким подходом любой будет отвечать , а большинство просто свалит с форума и микросекта останется микросектой.
Это когда вы всех пытаетесь перестроить под себя и не принимаете альтернативных точек зрения.
- Ненадо своих тараканов на меня валить . Я говорил о преимуществах своего подхода но не говорил, что нужно всем забывать про лямбда -фунции. Вы придумываете как обычно. Это меня тут сразу во враги-керзоны записали за инакомыслие. И так в каждом сообщении ваши микросектанты занимаются разнузданной травлей.
школьники воспринимают сразу оператор += Он не требует дополнительного обучения - только здравый смысл. Ага-ага, так и воспринимают без обучения. Что-то не видел.
Я вот впервые это читаю. И я здесь ни с кем не в объединении. У разработчиков языка есть свой взгляд на проблемы, пользователи форума же могут предлагать какие-то свои вещи.
Ещё раз - в этом топике специалист по химии обсуждает, как ему лучше применить PascalABC.NET для решения своей задачи. Обсуждение стало немного шире - как использовать PascalABC.NET взрослому специалисту в какой-то области, как обеспечить ему порог быстрого вхождения, какие темы надо рассматривать.
Так что давайте не отвлекаться от темы топика.
А зачем она нужна в таком виде? Чтобы путать? Вот свой язык вы же позиционируете, как обучающий, так? Потом люди привыкнут и будут так писать в других языках, где синтаксис другой. Где еще так пишут в промышленных языках? Вот, например, есть же у вас тернарный оператор сишный и это хорошо. Когда я писал о синтаксическом бардаке я имел в виду, в том числе, и такую путаницу.
Пришлось мне как-то на днях вспоминать этот ваш “новый” условный оператор и, знаете, я его не вспомнил. Написал
var min := x if x<y else y;
Да, это вариант, как в Питоне. Зато люди привыкнут, будут изучать Питон встретят такое и скажут: “о, я это уже знаю”. Разве это плохо? И пусть это мое оценочное мнение, но я считаю, что этот вариант читается лучше, потому что сразу видно, что min присваивается x, а не if. Ну или можно взять какой-нибудь другой вариант написания, из любого другого современного и популярного языка, если у вас, вдруг, неприязнь к Питону. Никакого хейтерства, ваш паскаль весьма интересен в плане новшеств. Но я считаю вы его сами же тут же и портите, в том числе и синтаксическим сахаром, который вы почему-то хотите привязать к синтаксису старого паскаля и/или дельфи.
Пожалуйста, вот современный язык Котлин, пробуйте:
fun main(args: Array<String>) {
val x = 5
val y = 7
var min = if (x < y) x else y
println(min)
}
Или это тоже “дурацкий” язык - причуда авторов? Запомните, пожалуйста, что кроме Питона ни в одном языке нет идиотической для понимания людьми, привыкшими к логике русского языка, конструкции вида "х если x < y иначе y"
. Так зачем Вы нам рассказываете, как она “хороша и удобна”?
Я полагаю, что Котлин — это не совсем популярный язык. Во-вторых: он не совсем для начинающих, даже если у этих начинающих первым языком был паскаль абц точка нет. В третьих: такую конструкцию там можно расширить блоками, чего нельзя сделать в здешней
val a = 10
val b = 20
val c = if (a > b){
println("a = $a")
a
} else {
println("b = $b")
b
}
В четвертых: Питон можно легко преподавать даже в средних школах, что и практикуется, а Котлин вы видели, чтоб где-нибудь в школах преподавали? В пятых: слово “дурацкий” это вы так говорите, я нигде такого не писал. И, наконец, лично мне, конечно, больше импонирует вариант Руби с короткой веткой:
a = 0
a += 1 if a.zero?
p a
вот еще пример с выходом по условию:
a = 0
while true do
p a
a += 1
break if a < 10
end
p a
А вашу условную операцию в каких других случаях можно использовать, кроме как присвоить по условию?
Наверное поэтому ваш язык в школах и не изучают. А если и изучают, то в стиле старого паскаля - три операции и два оператора.
Ну, школы - не единственная цель и не самоцель.
Бронислав, а с какой целью вы пришли на форум PascalABC.NET? Вот сейчас я имею в виду - после долгого перерыва?
Руби - замечательный язык кстати.
Котлин - язык, из которого мы берем многие идеи. Он сейчас очень активно развивается и является одним из основных языков разработки под Андроид.
Я считаю, что знаю с какой. Да и Вы тоже знаете. Практически - риторический вопрос.
Я вас понял. Желаю вам всего самого наилучшего и успехов вам с вашим паскалем.
Компилятор всего 1, поэтому пока нет смысла его проверять.
И платформа - тоже всего 1, это .Net . Одна из основных идей .Net - генерировать одинаковые бинарники под все ОС и битности процессора. А уже JIT компилятор, запускаемый прямо перед запуском самого кода - решит как оптимизировать код под конкретную платформу.
Ну, хоть это и не работает с $ifdef
, потому что он выполняется до создания бинарников - JIT проводит не только самые поверхностные оптимизации. Он так же хорош, к примеру, в обрубании не нужных веток if
. То есть в таком коде:
begin
if System.Environment.OSVersion.Platform = System.PlatformID.MacOSX then
begin
//ToDo код для MacOSX
end else
begin
//ToDo код для других ОС
end;
end.
System.Environment.OSVersion.Platform
вряд ли изменит своё значение после запуска .exe, а значит JIT может считать его константой. Хотя вообще я не проверял.
Выделяйте код так:
```
код
```
А то не читабельно.
По коду - вырежте cdecl
и всё будет работать.
Вы не правы. Без указателей невозможно работать с external
подпрограммами. Особенно если подпрограмма возвращает адрес.
Хотя оставлять такие подпрограммы “голыми” - тоже не правильно. У них всегда должна быть подпрограмма - оболочка, вызывающая external
подпрограмму и затем преобразующая тип во что то человеческое.
И, если принимается/возвращается не адрес, а дескриптор объекта - правильнее использовать или IntPtr
, или вообще свой тип записи-дескриптора, как то так:
cl_mem = record
public val: IntPtr;
public constructor(val: IntPtr) := self.val := val;
public static property Zero: cl_mem read default(cl_mem);
public static property Size: integer read Marshal.SizeOf&<IntPtr>;
end;
Какая нужда в .NET работать с программами, возвращающими адреса? Вызывать какие-то древние коды? Можно, конечно, искусственно что-то выдумать, потому что любой развитый язык до конца никогда не сможет противостоять тому, который #СамСебеЗлобныйБуратинка.
Я не писал, что с указателями в РАВС нельзя работать, “забудьте” - это были слова рекомендательного плана.
Посмотрите на MapBuffer
. Эта подпрограмма создаёт область памяти в RAM, через которую можно читать и редактировать память на GPU.
В external
подпрограммах такое повсюду. Хотя как я уже сказал, в правильном коде - голые external
подпрограммы не используются. Они всегда обёрнуты во что то более высокоуровневое.
К примеру, в случае MapBuffer
- стоит создать свой класс-обёртку для неуправляемой памяти. Вызывающую UnMap
в Finalize
и Dispose
. И предоставляющую основные методы чтения/записи значений и массивов в разных частях этой памяти.
Вот только высокоуровневый код - кто то должен писать. И вполне нормально когда это тот же человек, которые будет его использовать.
Странно рекомендовать человеку, уже работающему с external
подпрограммами - забыть один из основных типов для работы с ними. Такая рекомендация только показывает, что у вас мало опыта в области.
В области прямой работы с памятью GPU у меня не то, чтобы мало опыта - вообще его нет. Также, я не писал на Паскале драйверов устройств и не программировал на нем микроконтроллеры. Не считаю Паскаль наиболее подходящим для таких работ языком.
OpenGL
это только пример. Он нужен, потому что для графики что то да надо. И бывает, когда он остаётся одним из единственных вариантов.
Но external
подпрограммы не только для графики используются. Можно взять более общий случай:
OpenGL.dll это и есть драйвер. Конечно, он написан Не на .Net языке. Чтобы использовать его функционал в .Net - на каком то этапе должна присутствовать оболочка на .Net, использующая external
подпрограммы.
Смотря на код ТС - у него скорее всего своя неуправляемая .dll, в которой он держит низкоуровневый и быстрый код. Но всё на низкоуровневых языках делать - тоже плохо.
В таком случае - довольно логично сделать часть кода неуправляемым, а часть на .Net языке. Но, опять же, чтоб использовать эти 2 кода вместе -
на каком то этапе должна присутствовать оболочка на .Net, использующая
external
подпрограммы.
А перерегистрироваться не пришлось?
Мне не пришлось.
Мне не пришлось, но у меня выполнен вход через гитхаб-аккаунт