А посмотреть мона ?

А стоит?
http://spellbuild.h12.ru/download/python.rar

"Приложению не удалось запуститься, поскольку d3dx8d.DLL не был найден"

P.S. Кстати, надо будет потом кой-какие алгоритмы у себя поправить, а то там не все оптимально реализовано...

Тут нужна Debug-версия DX8+. Если линковать обычную, то размер увеличивается в 10 раз. Пока не придумал, как с этим справиться
PB-версия использует DX7, а это немного другое дело.

А ты тоже под 7ой пиши.

Это надо MSDN читать и DX7 SDK искать. Мне сейчас лень да и пыль веков неохота ворошить. Я лучше Мегамейз буду писать - там вся библиотека уже написана.

А мне вот лень искать Debug-версию DX8

Я перекомпилировал и перезалил проект. Вся проблема в том, что библиотека d3dx?.lib линкуется только статически, а без нее текст не выведешь . Динамическая линковка добавилась в 2005 году, но выкачивать очередной SDK в 200 Mb мне пока не на что.

"Ошибка передачи данных: Connection refused"

Хош пришлю DX7 SDK

"Python.EXE - обнаружена ошибка. Приложение будет закрыто"

Неудивительно. Я его плохо написал, по-олимпиадному -- без обработки ошибок. Править не буду, не стоит оно того.

Хрона, посмотрел змею. Напомнила QBasic. Очень походит на досовскую игрушку. И проблемы те же - отсутствие таймера, постоянная перерисовка - на старом компе очень заметно.

Мой гад ползучий
На Дельфи. Писал 2 часа. Рассчитывал на 1. Никакой оптимизации по объему нету. Небольшое мерцание тоже есть - экономил время, поэтому перерисовывается все поле.

Есть немало похожих элементов, хотя я написал до разглядывания твего кода.

Ну во-первых таймер там есть, не надо. Просто реализован кривовато... Ну, лень мне было голову ломать . Старая машиная ? PII 350Mhz достаточно старая машина ? А разработка шла, ориентируяс имеенон на него. Насчет постоянной перерисовки: в целом, она не обязательна, конечно... Но мне говорили, что так следует, вот я и...


1) Я не люблю оконный режим, т.к. DX в нем сильно тормозит. У тебя разницы нет, т.к. ты через GDI все делаешь. Тоже вариант, но я считаю это извращением. Кстати ! Надо заранее приготовленные Image'ы всталять, а не рисовать каждый раз квадратики\кружочки - FPS повышает.
2) А вот посмотри, сколько у тебя ПОЛЕЗНОГО кода в исходнике, и сколько мусора ? И на размер .EXE глянь.

Размер ты сильно не уменьшишь он всегда такой у борланда, он подключает все что надо и не надо...

А вот в пурике всегда подключается только то, что используеться .

Крист говорил, что где-то можно выкинуть всю фигню.

А мне вот, этим и заморачиваться не надо.

Celeron 433.


Может иногда это и полезно. Твоя ошибка в Clear. Если его не вызывать, моргания не должно быть.


Все, что не сгенерировано автоматически.


А если бы я написал на C#, размер exe был бы меньше твоего. Правда, требовал бы .NET Framework размером в сотни МБ. А в Delphi гнаться за размером себе дороже - тут он проигрывает.


Если писать на WinAPI, можно достичь размера в районе PB. К тому же есть KOL - промежуточный вариант. В принцыпе, компиллятор не пихает ничего лишнего, но есть очень много вещей, выкидывание которых потенциально может быть опасным.

А как иначе, если там идет обмен буферов ?

Моргания не будет если проводить обновление экрана во время обратного хода луча развертки монитора. Правда как это должно выглядеть на ЖК я не знаю.

Да вроде стоит enable synchronization...

у мну нормально все и не моргает

Да в том-то и дело ! У меня тоже все в порядке !

К слову: на что влияет размер компилятора?

Это загадка? На время его загрузки по сети.

обьясни популярно

Зависит от языка.

По-моему только на размер компилятора.

Ну, не всегда все так просто. Допустим, что компилятор представляет собой саммодифицирующюся программу, которая создает .EXE путем сохранения своей измененной версии... Тогда его размер очень даже влияет на размер создаваеммых им программ.

чаще всего это у программ установок

Не только.

я сказал чаще всего

Хрона, давай свою версию

Вот. Только она:
А) Нестандартная, немного.
Б) Неоптимизированная совсем. Сейчас чего-то неохота, может быть потом...

ты чето не то выложила.

Да не, они опускаются... только медленнее . А упор сделан на осколки... Ну, я же предупредила.

Я первый раз запустил Borland c++ 3.1
И хочу просто чтобы программа вывела обычный текст на экран, но она дает ошибку
Взгляните на скрин пожалуйста
http://files00100.narod.ru/0111.GIF

ошибка 1: че были ошибки при установке? это случается когда копируешь инсталлятор больше одного раза. отсутствуют заглавные файлы.
ошибка 2: все из-за ошибки 1
ошибка 3: вообще-то перед именем функции указывают тип возвращаемого значения (void - ничего не возвращает)

Добавлено ([mergetime]1161013660[/mergetime]):
и еще замечание: версия 3.1 - это дос-среда

с заглавными все ок, просто ботва чаще всего такая бывает, надо вручную прописать путь к папкам lib и Include или скинуть все файлы из последней в bin

P.S. угу дос, а это под 3.1 похоже...может 4? хотя может и виндос оболочка...

на билдер похоже

Может я позновато, но внесу свои 2 цента в обсуждение C++ vs остальные языки.
Правильно было замечено, что каждый язык как правило ориентирован на определенные задачи (обычно и был разработан под них). С++ стоит немного особняком. Это полигон для технологий. Он совместим с C (а С - язык для написания ОС и низкоуровневых программ - те же Windows на 90% написаны на C) и реализует все основные постулаты ООП. Поэтому это, скажем так, универсальный инструмент, удобный тем, кто его ОЧЕНЬ хорошо знает.
Хотите программу на ООП - лучше выбирать более строгие языки (Java или тот же C#). Будет чуть медленнее, не везде работать (нужна JVM или Frame), но удобно и красиво. Хотите что-то быстрое и компактное - используйте Ассемблер (хотя современные компиляторы с C и C++ дают разницу в скорости с Ассемблером близкую к 0, а то и быстрее делают, т.к. компилятор в отличии от человека без проблем "держит в голове" как и для чего он регистры использует).
Лично я могу написать на С++ любую программу. Повторюсь, что в конкретных ситуациях другой язык может быть лучше, но лучше знать один язык очень хорошо, чем много языков "по чуть-чуть". И как часто в большой программе с множеством классов хочется интерпретировать массивчик байтов как массивчик двойных слов, например. В С++ это 10 символов кода, а попробуйте в Java. Или в программе на C иногда хорошо бы иметь универсальный интерфейс - так нет же, только copy & paste. А в C++ это один виртуальный метод.
Всегда бывают элементы, которые неудобно делать в том или инов языке. Так вот в С++ таких элементов минимум. В это-то и его сила.

Только достаточно много неудобств, громоздкостей, заплаток, идущих из прошлого, часто неинформативные/наведенные сообщения об ошибках; нет таких банальных вещей, как property, procedure of object, нельзя просто взять указатель на метод класса... Delphi мне больше нравится. Для обычных прикладных программ самое то.

пиши проги в дос и не ооп. тогда тебе не надо будет те вещи, что ты описал

Это ты о чем?


Не знаю - мне как-то все всегда было понятно. А вот какой-нибудь "Run time error 123456" в VB- конечно очень информативен.


Обычный метод. Есть даже идеология Get/Set. Ничего лучше чем собственный контроль того, что происходит - не знаю.


Если Object - объект класса, то не вижу проблемы. Если это какой-нибудь контрол Виндов, то какое это отношение к языку-то имеет?


Приведи пример где это "нельзя".


Какждый выбирает то, что ему кажется лучшим. Дело вкуса. Я уже писал, что в C++ я, например, знаю в какую ассемблерную последовательность комманд превратиться любая конструкция в C++. А вот Дельфи - это для меня кошмар. Мы месяц "состыковывали" в WoG внешнюю DLL (Билдер - читай Дельфи) с C++. Там все стандартные хэндлы черех ж... получаются.

Ну, о том, что .h может 2 раза прилинковаться и др. мелочи, сильно портящим первое впечатление о языке. Если привыкнуть, наверное, они не будут мешать.


В Delphi есть такая полезная штука. Это 2 указателя - на метод и на объект класса. Используется примерно так:
У TObj1 есть procedure TObj1.Proc1(param:int);
var aa:procedure(param:integer) of object;
aa:=Obj1.Proc1;
Т.е. как callback функция, только для объектов. Заместо всяких Event listener'ов, Signal-Slot'ов и т.п. такое средство языка.


нельзя написать (void*)(&MyObject.MyMethod), хотя, если описать тип с сигнатурой этого метода, возможно, выйдет.


Какие "все стандартные хэндлы"?

Вобще то в стандартные .h, проихводиться проверка через предирективы компилятора, при этом возможность линковать несколько одинаковых файлов, доказывает что С++ очень гибкмй язык, и в первую очередь зависит от мастерства и умения создателя.

кто-кто, а ты-то сорсы zvslib1.dll посмотреть можешь. вот и смотри, какие

Первое - это то, что сказал Bourn. Но есть и второе. При грамотном построении проекта все h файлы будут инклудиться ровно 1 раз на компиляцию одного cpp. Я студентов и этому в частности учу. Нельзя это считать неудобством - это правила языка. В том же Дельфи тоже не что хочешь писать надо.


Понятно. А чем C++ хуже? У методов класса так же можно взять адрес.
Пример:
class X{
public:
void f(void){}
};
void (X::*fp)(void); // вот указатель
fp=X::f; // вот адрес

X ox;
fp=ox.f; // а можно и так адрес взять

Вариантов не меньше.


См. выше. И сигнатур не надо.


Например, мне нужно было поставить обработчик мышиных сообщений в теле WoG. Само окно - в DLL на Билдере. Так вот нормальная работа с установкой своего суб-солбэка по хэндлу окна ничего не дала вообще. Пришлось извращаться. Именно поэтому долго диалоги из DLL болтались модальными глобально, а не в контексте главного окна WoG.