И где агрессивная? Это из вашенской микросекты постоянно говорят , что “вам с здесь на рады " и " ваш ответ керзнону” . С таким подходом любой будет отвечать , а большинство просто свалит с форума и микросекта останется микросектой.
Это когда вы всех пытаетесь перестроить под себя и не принимаете альтернативных точек зрения.
Ненадо своих тараканов на меня валить . Я говорил о преимуществах своего подхода но не говорил, что нужно всем забывать про лямбда -фунции. Вы придумываете как обычно. Это меня тут сразу во враги-керзоны записали за инакомыслие. И так в каждом сообщении ваши микросектанты занимаются разнузданной травлей.
школьники воспринимают сразу оператор +=
Он не требует дополнительного обучения - только здравый смысл.
Ага-ага, так и воспринимают без обучения. Что-то не видел.
Я вот впервые это читаю. И я здесь ни с кем не в объединении. У разработчиков языка есть свой взгляд на проблемы, пользователи форума же могут предлагать какие-то свои вещи.
Ещё раз - в этом топике специалист по химии обсуждает, как ему лучше применить 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
А вашу условную операцию в каких других случаях можно использовать, кроме как присвоить по условию?
Компилятор всего 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 подпрограммы.