MFC: is dead или еще нет?

ибо профессионалы программируют с помощью языка, а не на нём

W4FhLF
Хороший поэт. Не ваш родственник часом?

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

Може вам на ВБ все-же перейти? Там специальной целью стоит невозможность написания сложного кода.. Ну а понимаемость языка - прямое следствие опыта в нем. И не только хождения по главным аллеям, хорошо освещенным и облозунгированым, но и по боковым улицам и даже грязным переулочкам, тк там наварнее.

Ура ура, еще один поставил крест. Меньше конкурентов - больше моя востребованость и, соответственно гонорар.

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

/Скажем, выше приведеный код формирует процедуру разлочивания проги на основе пароля и некой другой инфы. Почему так? Не знаю.. Хоцца./

Сборка мусора без введения значительных ограничений в язык - задача далеко не банальная, что видно хотя-бы из неналичия огромного количества стоящих реализаций данного функционала за > 50 лет существования данной технологии. Кроме того, думаю, усилено критиковать одну из ведущих реализаций технологии несколько преждевременно. Особенно в свете вашей принципиальной неплевательности в сторону новых для вас вещей.

ЗЫ Линк немного по теме (хоть и не ветки. Може для обсуждения ГЦ связаных технологий всежу отдельный топик завести?)
http://alenacpp.blogspot.com/2007/11/c0x.html
(симпатичная девушка, правда?)

 

r90
сразу видно, человек знаком с ядром

 

_basmp_

вы спорите над аксиомами

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

 

r90

Молодец, выкрутился.
Пример показательный, особенно если чуть расширить и добавить в some_object поле type_id, то можно в одном списке хранить различные наборы данных или указатели на разные функции, в итоге можно получить некое подобие полиморфизма

Но я критиковал случай, когда человек выделяет указатель на единственный int и прибавляет к нему 7 байт. Это явный out of range.

 

W4FhLF

ты привязываешься по мелочам - вместо 7 можно взять и число выровненое по границе 4*x. я говорил о том, что весьма трудно с арифой укзателей говорить о СМ

 

rei3er

я не думаю, что человек спорит с аксиомами: что значит "простой код" - читабельный или оптимальный(по скорости, размеру). читабельный!=оптимальный, т.ч. человек прав.

 

rei3er

читаем тут
цитата:
Аксио́ма (др.-греч. ἀξίωμα — утверждение, положение) или постулат — утверждение, принимаемое без доказательства.
Те аксиома, как минимум, не абсолютна и оспариваема, что мы частенько и наблюдаем. Кроме того, утверждение о необходимости простоты к идеалу - уж точно не аксиома, что можно не ходя далеко увидеть на данном форуме в ветке A&O.

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

W4FhLF

По вашей реакции - ситуация описана крайне для вас редкая..

7 (или 29?) байт взято с потолка. Просто пример. Но ситуация int *p= getMem(<некий размер>)+<некое смещение>; взята не с потолка. Просто я не писал где и как это применяется, тк в данном случае это не важно. Начало выделеной памяти всегда можно вычислить, тк смещение - константа, а заводить дополнительный указатель + структуру где они лежать будут + указатель на структуру накладно и по памяти, и по коду, и, кроме того, это приведет увеличению потенциальной вероятности ошибки.

 

кстати, в некоторых программах встречается ситуация, когда указатель уменьшается на sizeof(что-у-нас-там). это для создания массивов, начинающихся с единицы в принципе, не совсем по стандарту, т.к. на некоторых системах (том же досе) можно получить "заворот", но под виндой и линухом - полет нормальный. можно даже вообще делать массивы типа от 66 до 69 и ведь это работает! и используется. пускай не очень широко.

 

kaspersky

Во, действительно хороший пример, где такое можно применить. Мне даже в голову не пришло
Но, всё-таки, если в какой-то момент мы меняем значение указателя и он указывает(извиняюсь, тавтология, с утра не смог придумать подходящего синонима ) на память нам не принадлежащую, то должны помнить об этом. А теперь представь проект несколько десятков тысяч строк, где таких вот трюков штук 50 по всему коду в разных местах. Хорошо, если программисты их снабжают комментариями, чтобы через год, когда придётся изменить функционал этой части, быстро во всё въехать. Я бы не приветстсовал подобное в таких случаях, лучше прибавлять константу к индексу.

В своих личных проектах ради бога, что угодно

 

W4FhLF
такое используется и в опенсоурсных проектах. после чего приходится ломать голову:

а) какого черта тут стоит free(p+sizeof(T)) ?!
б) какого черта у нас тут buf = malloc(3); // .... //, а тут for(a = 66; a < 69; a++) buf[a] = ... ?!

это, конечно, не самый красивый прием программирования, поскольку мы всегда должны помнить о том, что освобождать free(buf) уже нельзя, иначе все рухнет на хрен. с другой стороны, мы должны знать, что такой трюк есть, чтобы при встрече с ним не сильно растеряться...

кстати, при работе с локальными и статическими массивами это очень даже полезный трюк. можно забацать макрос MYARRAY(from, to), позволяющий создавать массивы а-ля паскаль, все равно их не надо освобождать...

переносил я как-то паскалевскую программу на си. а там ужас сколько этих массивов, начинающихся не с нуля и даже не с единицы. если переписывать весь код, это можно трупом лечь. выкрутился именно таким способов. играми с указателями. под виндой код на 100% надежен

 

kaspersky

Так я жешь о чём и говорю. Человек не может держать в голове много деталей одновременно, а чем сложнее код, тем больше таких деталей.

Мазохизм Не думал юзать STL-контейнеры? Для этого не обязательно менять парадигму на ООП, можно в общем-то сам код писать в С-style, но STL при этом юзать.
Если так напрягают конструкции типа vector<int> можно заюзать typedef'ы, а new и delete обернуть в malloc и free
Даже в драйверах уже не раз видел использование stl, их польза очевидна.

 

W4FhLF
> Так я жешь о чём и говорю. Человек не может держать в голове много деталей
> одновременно, а чем сложнее код, тем больше таких деталей.
держать детали - это еще пол-беды. это еще можно как-то...
хуже, когда приходится разбирать чужой код, так такие хаки можно легко принять за ошибку и "пофиксить" ее. однажды я на такое напоролся. ну и что? программа стала падать раз в несколько дней, т.к. освобождался (случайно) совсем посторонний блок, который в общем-то был не так сильно и нужен, да и когда освобождался то затирался не сразу, а с некоторой вероятностью. после чего было очень трудно отловить ошибку, вернув все на место. ну там правда была имитация паскалевских строк - первый байт - размер, дальше - сама строка. и там указатель был именно на первый байт строки, а (указатель - 1) - на байт длины. ес-но, сразу после выдения указатель увеличивался, а перед освобождением уменьшался. причем, коварство заключалось в том, что там был макрос fast_free, которому все и передавалось. сам free по тексту не использовался ни разу. ну и когда я там дописывал свой код, то передал fast_free указатель на реальный блок, а он сцука, уменьшил его на единицу. ну и...

> Не думал юзать STL-контейнеры? Для этого не обязательно менять
> парадигму на ООП, можно в общем-то сам код писать в С-style,
> но STL при этом юзать.
там требовалось переписать программу под C99, так что плюсы отдыхали.
и никакого мазохизма усе просто

 

Уважаемые професионалы, так с помощью чего посоветуете писать под Win в конце-коныов? MFC уже как я понял, dead. qt неоднозначный, но вроде тоже не всем хорош. WinAPI - ничего большого просто не напишеш. Шарп тоже мало чем годится по причине обязательного присутствия на машине НЕТ фрэймворк. Ну так что же юзать все таки? Чтоб и удобно, и перспективно?

 

>>Ну так что же юзать все таки? Чтоб и удобно, и перспективно?<<

wxWidgets?

 

Mozart

VCL.

 

Это то, что борланд предлагает? Делфи и спп билдер? Хм, ей-богу из всей этой кучи библиотек и технологий самое трезвое решение. Удобно, таки да, но чтоб сильно перспективно... Не знаю, не знаю. Наверно все таки посмотрю в сторону QT. Очень уж привлекает кроссплатформенность

 

Mozart
гую пиши на дотнете, а, вообще, никого не спрашивай - выбери удобный и работоспособный для себя вариант, а читать такие посты последнее дело

 

Угу, пару небольших проектов сделал с использованием MFC.
Не такой он уж и тошнотный, привыкнуть можно, Qt имхо все же похуже будет.

 

Много писал на mfc - сейчас вспоминаю как страшний сон. Верно подмечено выше - складывается впечатление, что она недоделанная и запутанная.

Для проектов на с++ c гуи использую wxWidgets (http://ru.wikipedia.org/wiki/WxWidgets).
QT - денег стоит (если разрабатывать коммерческое ПО).

wxWidgets - намного легче и мне больше нравится. Основной плюс (для меня, конечно - многие не считают это особым плюсом) она не отрисовывает
контролы сама, а использует встроенные в графическую полсистему существующие. Ну и кроссплатформенность выше, чем у QT.

З.Ы. А вообще для MFC действительно написано немеряно модулей/классов/библиотек. Так что при проектировании проекта надо просто посмотреть, на чем будет реально удобнее и бистрее сделать.

Кстате по поводу гуи приложений - есть такая штука: wxPython. Советую заценить. Очень быстро и локанично можно написать достаточно сложные программы.

 

А что скажете насчет WindowSystemObject (WSO)?