Для меня программирование - искуство.

2Crip
Железки поменяли почти везде.
Дело скорее всего все таки в фоксе. Я даже знаю где и почему. Сегодня проверю - отпишу.

авторв большинстве случаев юноши со взором горящим общему делу только вредят.
Т.к. занимаются не делом а искусством

Человеку под ником 1024.
Я уже не юноша. Я программирую с середины 90-х. В то время хакерами называли не тех кто пишет "Сдесь был Вася Пупкин" на чужих сайтах, а тех кто реально понимал как программный код выполняеться в железе. Моему опыту программирования большинство может только позавидовать. Я писал проги на стольких языках, что пальцев на руках не хватит что бы перечислить их названия. Я могу написать клиента для БД или могу написать драйвер для сетевой карты. Вместо того что бы пить водку в подъезде я программил вечерами и ночами.
После этого ты будешь называть меня пренебрежительно юношей и указывать на маньячный горящий взгляд?. Все дело в том что некоторые пишут музыку или картины, а я программлю. Это мое творчество. И оно совпадает с моей работой на 100%.

Неужели обязательно на незнакомого человека всегда смотреть с высока? Мол я то знаю что я крут, а этот 100% менее крут чем я? Или многих обязательно нужно ткуть носом в сертификат MCSE что бы с тобой начали нормально разговаривать?.

Я не являюсь представителем никакой оффициальной организации, поэтому все что Я пишу на форумах являеться исключительно моим ИМХО. Нигде не написано иного. Кроме того все мое ИМХО обсуждаемо в рамках приличий.

На счет ломаеться. Лично для меня не вызывает сомнений что процедура деструктуризации объектов в FoxPro реализована некорректно. Естейственно разными ухищрениями можно добиться того, что это не будет сказываться на приложении. Сдесь я прошу обратить некоторое внимание на то, что я говорил не конкретно о своей программе а о недостатках FoxPro.

Пример: Есть форма. Есть свойство. В runtime присваиваем этому свойству ссылку на объект. Form.Close. Что происходит с формой? Часто она остаеться висеть частично разрушенной (это зависит от объекта и некоторых прочих факторов). Ее держит ссылка на объект. Скажите это нормально? НЕТ.

Нужен пример? скажите я сделаю.

По поводу:
авторну так и разговаривай нормально.


авторза полтора месяца автор "написал первую прогу
(достаточно серьезную)". Теперь у всех его юзверей стоит фреймворк NET 2 и
всё летает и прекрасно работает. А, да, он ещё за полтора месяца это всё
протестировал.

хорош свистеть


авторБУГАГА

ну так и писать надо - пол-года пробовал чёт писать на ц-диез. Понравилось.

а через 6 лет - 6 лет писал на ц-диез, сделал (столько-то) проектов,
(понравилось/непонравилось)


автор1) А у меня не вылетают! Странно, не правда ли :) Может в консерватории надо
чего-то подправить :)

авторБолее того - ты возможно удивишься, но "внутри" фокс вовсе не однопоточен

авторПросто смешно :) Без комментариев.

авторБа, да уважаемый сэр не может отделить ЯЗЫК C++ от среды программирования MS
VC++ ;)
Честное слово - после этого создаётся впечатление, что вы не далее как вчера
из-за студенческой скамьи встали...

автор
Извиняюсь за многословность, но уже достают пустые псевдо-рекламные
сообщения

авторGlavnoe ruki normal'no zatochennye i golova na plechah. I ne budet Fox po C5 viletat'. :))

автор
в большинстве случаев юноши со взором горящим общему делу только вредят.
Т.к. занимаются не делом а искусством

Может дело в Вас?

авторПример с формой на которую не удалена ссылка не канает, т.к. понятно почему
это может произойти и понятно что так делать не надо. Такие вещи обычно
решаются либо производителями среды ( исправление бага ) либо программистами
(не делать так). Аналогично как и в любых других средах типа дельфей. При
желании синий экран можно и в ВБ6 получить.

Я ведь и говорил про баг не так ли?.
К слову сказать ошибки доступа подобные C5 должны быть возможны только в компилирующих средах при доступе по nil указателям, или при некорректном использовании объектов в многопоточных приложениях. Интерпретатор должен сказать "Нету такого объекта" или что то вроде этого. То что валится runtime Fox'а и то что ошибка не привязана к коду, говорит о баге этого runtime. В сложных приложениях полюбому приходться хранить ссылки на объекты в разных местах. Я столько времени уже потратил на локализацию причин ошибки, что за это время успел бы написать небольшое многопоточное приложение на VS2005 и отладить его.


автормоё мнение - тебе сделали совершенно правильные замечания. Ты можешь с этим
не соглашаться.

Я не согласился и написал почему я не согласен. Где ответы на это содержащие чуть больше смысла чем "кривые руки"?

авторПример с формой на которую не удалена ссылка не канает, т.к. понятно почему
это может произойти и понятно что так делать не надо

Мне не понятно почему это должно происходить. Совершенно не понятно. Почему не надо? Где мне держать ссылки на объекты? в Global переменных что ли?

Естейственно я знаю что нужно делать в таких случаях в Fox'е. Но меня как программера на более низкоуровневых языках от этого тошнит.

авторБезаппеляционные заявления без всяких примеров раздражают.

Какой пример тебе нужен конкретно? На второй странице спросили код, но это было похоже на шутку. Больше никто ничего не спрашивал.

Кроме того слово "безапеляционные" означает что возражения не принимаються. Разве это слово можно применить к моим постам?

баг от фичи отличается тем что должен быть исправлен. Лечится установкой
сервиспаков.

Это да. Проблема в том что этот баг являеться следствием ограниченной функциональности объектной модели VFP. И после СП это вылезет еще где нибудь. Я начал с 5-го VFP и до сих пор с этим сталкиваюсь. Получается то что фокс не дает грамотно уничтожать объекты (нет реального деструктора), а сам при освобождении памяти допускает баги.

авторц-диез, кстати, не является низкоуровневым языком
автор на более низкоуровневых языках

Ладно народ. Извиняюсь перед теми с кем я был не заслуженно резок. Мне бы хотелось потихоньку закрыть эту тему, но я буду продолжать отвечать на посты. Еще раз извиняюсь, если наступил кому то на больную мазоль. Своим первым постом я только хотел сказать что опробовал C# и мне очень понравилась функциональность и удобство кодинга. Хотел обратить на dot Net ваше внимание. Не ожидал такой реакции.

Ну жтож, продолжим.

автортебе ж русским языком говорят - сборкой мусора и прочими системными вещами
занимается фокспрошная виртуальная машина. Это никакого отношения к
"объектной модели" не имеет. В хелпе не сказано что это происходить. Баг
должен быть исправлен разработчиками виртуальной машины (рантайма т.е.)

А я тебе не менее русским языком говорю что баг с C5 это одно, а отсутствие дестроера другое. Не надо путать две слабо связанные вещи.
Журнала FoxTalk у меня нету. Буду благодарен за ссылку.

автормазоль не в дотнете (такое сверхновое появляется примерно раз в пять лет,
ничего особенного, что-то лучше, что-то хуже) а в том что ересь какая-то
выдаётся за осмысленное мнение.

Какая ересь? отсутствие дестроера? невозможность в некоторых случаях нормально грохнуть объект? Ересь говоришь. А то что я с этой долбаной ошибкой трахаюсь столько времени, хотя ежу ясно что она не моя?(мою нить рассуждений по этому поводу можно откопать выше.) Я в том числе про это и веду речь. Что надежное, масштабируемое приложение на FoxPro писать труднее чем на VS2005. Это ИМХО. Доказательство вот : Я бы эту ошибку на C# локализовал, обошел бы и исправил за полчаса буть пусть бы она находилась в каком угодно потоке. А в Фоксе я обязан либо трахаться с ней либо ждать чуда в СП.

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

Под дестроером понимаеться метотод объекта, при вызове которого объект будет разрушен и выгружен из памяти. В общем случае это просто метод (метода) удаления объекта из памяти. В Delphi это метод Destroy(). В C# открытого дестроера тоже нету, но там есть грамотная реализация учета ссылок на объект и грамотная сборка мусора. Т.е. создав объект и рассунув к примеру десять ссылок на него по разным объектам (утрирую) можно быть уверенным что для того что бы мне этот объект грохнуть, мне надо освободить все ссылки на него и он сам мирно ляжет, предварительно выполнив тот код что описан в его деструкторе с тильдой. Причем ссылка на созданный общий объект никоим образом не может мешать уничтожению ссылающихся на него объектов (согласись, это ж бред).
Предполагаю что разработчики VFP собирались в Фоксе сделать что-то подобное но у них это плохо получилось (говорю без доли иронии). В итоге чтобы написать стабильное приложение мне приходиться сильно упрощать код. Что ведет к неудобству в кодинге и разбухании кода. Нет возможности нормально реализовать библиотеку классов на всю катушку используя принцип инкапсуляции. Вечно будут конфликты при уничтожении объектов. И даже если -(цензура)- и все заработает то итоговое приложение все равно изредка будет падать. Проверено мной не раз. Не пытайтесь меня уличить в том что я не соблюдаю порядок создания\уничтожения объектов или не вовремя очищаю ссылки на них. Я все это давно очень хорошо и давно впитал практически с молоком. На 386 компах я писал проги на всю катушку пользующие память видюхи, так что в доступе по nil указателям меня тоже обвинять не стоит. И еще раз повторюсь что мои проги на Delphi никогда не валились с ошибкой доступа к памяти, а ведь там все сложнее. Я просто констатирую факт что при сложной стьруктуре классов обязательно возникают проблемы с объектами. Все это я видел начиная с 5-го фокса. Возможно вы с этим не сталкивались (не верю я в это) потому что не слишком углубляли свои классы, не использовали в них коллекции объектов со ссылками на другие объекты. и.т.д.

Ребят не хочу я ссориться. Если для вас проблема дестроеров не стоит значит ее для вас и нету. и ладненько.

PS. Спасибо Равиль. Ты меня просто выручил. Я действительно мало общаюсь на проффессиональных программерских форумах. Пару лет назад меня можно было встретить на delphi.mastak.ru, но там я только отвечал на вопросы и дискуссий ориентированных конкретно на меня не возникало.

PPS foxwizard. Спасибо за ссылку. Давно хотел почитать журналы по Fox'у но ни одного не нашел.