lsor

Анимешные скринсейверы: http://mega-soft.ru/prg3138.html http://mega-soft.ru/prg3193.html http://mega-soft.ru/prg3203.html http://mega-soft.ru/prg3204.html

Странно? Да на 90-е пришёлся пик популярности спектрума в бывшем Союзе. 486-й и в 1997-м купить было не столь дешево, кстати. Я тогда только мечтал о нём и гадал, как бы мне на него накопить. А спектрум мне купили в 1994-м. Тогда это ещё было возможно. Так что всё правильно, уйма народу начала свой путь с него именно в 90-е. А хотя вы же москвич? У вас, наверное, в 90-е уже пентиумы котировались, у нас же под Питером они не сильно были распространены в качестве персональных...

Sinclair ZX-Spectrum 48 K. ;)

Так чистый вид и не нужен. Нужны функции в концепции паскаля. Чтобы с паскалем, а не с си совмещались и не приходилось в явном виде с указателями работать. Так я о том и говорю. ^_^ Да понятно это всё. Но для этих целей можно и завести глобальную переменную. А вот чтобы сделать функцию с внутренним флагом, что она уже вызывалась, придётся загромождать класс переменными флагов. Вот нужно мне, чтобы при первом обращении к функции создавался файл, а во всех остальных он дописывался. Так я в самой функции класса пишу static FirstStart=true, а так мне нужно в самом классе заводить такую переменную. Но это ладно, но ведь разделяемая переменная в классе ещё и нарушает идеологию. Она не очень-то логична. Все переменные у объектов свои собственные, а вот эта особенная и одна на всех. Было бы логичнее чтобы и static переменные функций и классов были собственностью объектов этих классов.

Оно, увы, нужно. Оно мышление развивает. Программиста ценить надо не по полноте знания языка, и не по количеству известных ему языков, нет. По полноте анализа каждой ситуации - вот по какому качеству нужно ценить программиста. Так вот эти "специалисты" - такими способностями не обладают. Их среды "кое-как, но работает" не развивают. Вообще, как писал Станислав Лем: разум отнюдь не узкая специализация, а напротив, как можно более высокая. Нет, я же не занимаюсь Delphi или Builder'ом. Я вот чем занимаюсь (лся... :) ): http://www.mega-soft.ru/prg3143.html

Вопрос не о том. Вопрос о том, почему копия FreeUID не создаётся для каждого объекта класса, а одна на всех. Но разве VCL покрывает все функции Win API? (Сорри, но я не использую среды типа "кое-как, но работает", я под Windows пишу на VC6 и MFC+Win API, потому очень плохо знаком с VCL, но вспоминается, что там не все API функции представлены) Ну ругаться-то зачем? ;) А вообще, есть одна проблема: серьёзных программистов на самом деле чёрта-с-два сыщешь - в основном "специалисты" по SDK попадаются. Всё-то они знают о всех конструкциях и структурах makefile и настройках компиляторов, но вот доходит до дела и все их знания не помогают им, скажем, модифицировать программу для установки вечной жизни или разработать алгоритм анализа текста с использованием автоматов, или сделать игровую программу или ещё что. На самом деле, это большая проблема... Библиотечными функциями пользоваться умеют, а своё создать - нет, не научены. :angry: Вот что на самом деле грустно-то...

На самом деле, речь шла о том, у кого синтаксис кривее. :) Возможно, это дело вкуса. :)

В классе? Но если я ввёл переменную, значит она мне нужна. А вот этого я, как пользователь языка, вообще знать не желаю. :) Я назначил как массив объектов. Вот пусть компилятор и думает за меня. ;) А std::vector коряво выглядит. Да и я может, stl и использовать не желаю? Я вообще, так и свою могу написать библиотеку.

Вот из Википедии: В Мас его выбрали потому, что сообщения и объекты на уровне языка - вот что очень нужно оконной ОС. А я про паскаль под Mac OS и не слышал... бывает ли он вообще? А у Вирта они были? Я не помню, но вроде как и нет. Да и спешка в том, что всё, что с указателями нужно делать - так это распределять динамическую память. И больше ничего! А всё остальное - это извращение.

Это уже из области фантастики. Причём, малонаучной. Какое мне дело до пространства имён класса? ;) Эта пять! :D А, может, на стеке точки входа в деструкторы ещё сохраним? Тоже вызовутся ведь. ;) А серьёзно, вопрос не о том, как это можно сделать, вопрос о том, ПОЧЕМУ ТАК. А это уже вопрос кривости реализации этого самого API. Учитывая, что он написан на Си, нет ничего удивительного, что возникают проблемы с паскалем. Действительно, в Win API количество указателей просто фантастическое. Но с другой стороны, раз уж мы полезли с паскалем в Windows, в Delphi стоило бы сделать полную внутреннюю обвязку Win API с уровня паскаля, а не заставлять программистов применять паскаль в качестве Си. Увы, нет. Си++ - это просто Си с классами. Настоящий объектно-ориентированный язык - это Objective C, который с Си++ имеет не слишком-то большую совместимость. Увы, я с ним не знаком, но судя по описаниям, это именно то, что очень удобно для работы с объектами. Не случайно Mac OS его использует. Боюсь, что они этому самому Delphi чужеродны напрочь. И ввели их в угоду необходимости в спешке.

Да, но она тоже имеет смысл. И в ряду случаев пройдёт, как битовая операция. И не заметите даже. Если не злоупотреблять, правда. Это, наверное, потому, чтобы исключить ряд ошибок с использованием указателей. А вообще, нужны ли вообще указатели в паскале? Зачем Delphi лезть на такой низкий уровень в принципе? Насколько я помню, в том же паскале нельзя намеренно в процедуру передать значения иного формата, без явного преобразования. А вот в Си++ приколы. Тоже очень неявные. Пример из книжки. Пусть есть класс Account; Пишем: Account *pact = new Account[10]; Ну создали мы массив из 10 элементов. А теперь его удалим. delete pact; Верно? Не-а. Деструктор вызовется только для первого объекта. Верно писать delete [] pact; Мда... И почему я, а не компилятор, должен за этим следить и явно указывать, что удаляется массив?

Делфи - это не синоним паскаля. Синтаксис паскаля - это не синтаксис делфи. Точно так же, как и синтаксис си - не синтаксис билдера (вас не смущало, что у вас класс окна неявно связан в билдере с функциями обратного вызова Windows? Средствами языка Си такое сделать невозможно - потому-то и появились макросы в MFC и метаобъектный компилятор в Qt). Что касается синтаксиса паскаля - он гораздо более ясный и чёткий, в отличие от незабвенного Си++, в котором наизвращались до того, что зачастую программы совершенно не читаемые без знания тонкостей. И это как бы ещё и без связки с убогой по синтаксису MFC. Вот смотрите, например, переменная с модификатором static, объявленная в самом классе является разделяемой со всеми объектами этого класса. Удивительно, правда? На кой чёрт это сделали? Это абсолютно не интуитивно и даже бессмысленно (потому что такие переменные очень удобно использовать в качестве флагов, а здесь эта возможность утеряна). И там как бы таких фишек много. I++, ++I, I+=A, if (a!=b && b!=c) (и попробуйте написать одну &). Там много гадостей. Невозможно, например, деструктору указать тип принимаемого значение void. Как и возвращаемого, впрочем. Вот зачем? Почему бы в целях унификации это не разрешить? Почему переменная в одних компиляторах живёт вне цикла, в котором была объявлена, а в других нет? Бред ведь.

Нет, не убогий. Убогий синтаксис в Си++.

А в чём же была проблема? Вылетели? Так это институтское задание было?

А что потом происходит? Выход из программы? P.S. Только не очень понял,а зачем вам паскаль да ещё и под DOS?

QNX 6.3. :)

Мда... Ну и нафига мою тему убили, а сообщения принесли сюда? Жалко было вторую тему о PSP оставить, да? -_- Назвал же "Простые игры для PSP" и привёл в ней свои разработки несложных игр. Ну какое это отношение имеет к теме обсуждения параметров PSP? И это при том, что вы здесь темы создаёте на каждый чих - для каждой PC игры практически индивидуальная тема. Ладно, ваши проблемы. Подкидной Дурак ссылка

Раз уж эта тема для игр, то я пожалуй, представлю здесь достаточно простые игры для PSP. Вдруг кому-то будет интересно. Все игры с исходными кодами. Все на PSP Slim идут. Проверял на 3.90 М33 (т.к. писал на ней :) ). Сокобан ссылка Пасьянс "Косынка" ссылка Пакмен ссылка Сапёр ссылка KrakOut ссылка Кубик Рубика ссылка Крестики-нолики в 3D ссылка По мере разработки, количество игр будет пополняться. Если мне лень не будет дальше заниматься созданием таких игр, конечно. :)