Большой Воронежский Форум Mobile

MadFish, не экстраполируйте свои дурные привычки в программировании на окружающих.

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

Сообщение от MadFish:
Пишешь небось на билдере (или вижуал васике) ? В формочки компоненты вставлял? Так вот интерфейс IDispatch ты получал как раз через IUnknown (тока за тебя это IDE сделала).

с этим я не работал [Ответ]

Сообщение от The_God:
не экстраполируйте свои дурные привычки в программировании на окружающих.

Есть правила хорошего тона в программировании, и я их придерживаюсь

Глупости... Ну при чем тут мои "дурные привычки в программировании" (кстати где ты их разглядел???) и твои хваленые "правила хорошего тона в программировании" (надеюсь ты не против что я на "ты"). Я лиш пытался объяснить, возможно не очень понятно, что огромный пласт реальных задач просто НЕЛЬЗЯ решить другими механизмами. Двоичные компоненты это лишь малая толика. Приводились примеры про потоки, СОМ, да банальный копи паст (в смысле буфер обмена) все работает с void * и другими методами именно из-за философии самих этих технологий это не решить. Нельзя каждый раз переписывать функции API чтобы клипборд правильно работал с типизированными данными void * механизм отделения данных от алгаритмов (следующий шаг после ООП). Его лишь надо грамотно использовать. А "правила хорошего тона в программировании" придуманы для студентов и школьников, чтобы структурировать кашу в их головах, не более того.

Сообщение от The_God:
с этим я не работал

С чем? с двоичными копонентами, или с билдером \васиком? Если с комобъектами то позволь тебе не поверить (во всяком случае судя по тому что ты неплохой программер на С++ ) ты наверняка писал проги не только для дос и *nix,а и для Win, и наверняка использовал визуальные формы, а не кодал в нотепаде на голом WinApi. Соответственно использовал визуальные компоненты (кнопочки списки может даже таблицы), вызывал из своих приложений ворд\ексель. Все это ты делал с помощью технологий COM и интерфейса IUnknown! Так что смело можешь сказать что используешь void * в своих программах. [Ответ]

Сообщение от MadFish:
используешь void * в своих программах

конечно использую, потомучто есть функции из всяких апей которым нужно передавать именно void* потомучто они уже написаны и с ними приходится мирится.
Я всеголиш против использования void* там где можно обойтись типизироваными указателями, пусть даже если кода станет немного больше. [Ответ]

The_God, Дело не в АПИ, а в философии. Банальная задача которую уже приводили. Организовать хранилище ЛЮБЫХ объектов. Все. Кроме void * решения нет, нравится или нет, но это так.
Но там где нет реально такой необходимости, данные надо жестко типизировать, тут я согласен.

PS. Посмотрел на твоем сайте, ты ведь с DirectX балуешься. Так ведь этож чистый COM и про IUnknown и IDispatch ты то уж должен был знать.... [Ответ]

Сообщение от MadFish:
в философии

согласен

Сообщение от MadFish:
Организовать хранилище ЛЮБЫХ объектов

ну если такое задание, написать массив void*, то придется писать.

Сообщение от MadFish:
с DirectX балуешься. Так ведь этож чистый COM и про IUnknown

да я видел что там всё от это ЙаНеизвестное относледовано, но это не пример для подражания чужих промахов в дизайне

Сообщение от MadFish:
А "правила хорошего тона в программировании" придуманы для студентов и школьников, чтобы структурировать кашу в их головах, не более того.

не согласен, есть правил, есть те кто их соблюдает и те кто считают что это необязательно, я отношу себя в первой группе. Существование программистов которые не соблюдают правила при создании программ увеличивает стоимость тех программистов, которые их соблюдают. [Ответ]

Сообщение от The_God:
да я видел что там всё от это ЙаНеизвестное относледовано, но это не пример для подражания чужих промахов в дизайне

ды мне кажеца это не промах, а больще для совместимости со всем подряд.... [Ответ]

..., ну я не могу... Один говорит промах в дизайне, другой совместимость...
Парни, почитайте про двоичные объекты, вам откроется доселе неизвестная мудрость!!!
The_God, Программист ДОЛЖЕН соблюдать правила-правила дорожного движения, уголовный кодекс, правило буравчика и второй закон Ньютона! Я прекрасно знаю, что на ПММ в башку вбивают кучу стереотипов (из функции только одна точка выхода, выход из цикла только по условию в заголовке, не юзать void*). Все это детский сад. Основная задача чтобы программа была легко читаема, логика понятна и не противоречива. Из себя я долго выбивал все эти "правила". Из своего опыта скажу (я использовал разные методы проектирования от RUP до экстремального программирования) лучшим для себя я считаю только одно правило. ПЕРЕД написанием программы берется лист бумаги и русским языком пишется алгоритм. А дальше, по правилам русского языка и литературы- в сочинении не должно быть тавтологий, слишком длинных предложений, и фактических ошибок. Короче если читать легко и понятно, то переводим в код(а сочинение будет коментами), если где-то непонятки то кусок переделать. Железно код получается читаем и легок в сопровождении.
Иногда приходится читать работы студентов. Так вроде все правильно, по шаблонам, но в условии цикла десяток логических выражений через анд\ор\хор да еще и вложенных. После выхода из цикла не понятно, а почему собственно вышли и нужно еще десяток проверок различных условий, хотя все по шаблонам, все по уму… [Ответ]

Сообщение от MadFish:
Все это детский сад

не согласен
переубеждать не буду [Ответ]

Сообщение от MadFish:
Основная задача чтобы программа была легко читаема, логика понятна и не противоречива.

хм а я думал главное - чтобы программа работала, а уже потом была читаема и etc.
Кстати насчет ПММ. У меня вот друг учится на ПММ. Как-то раз на первом еще курсе он пришел ко мне за помошью. Собственно задачка была простенькая. Начиналась она примерное так: вводится ряд положительных чисел... Я вставил проверку на положительность после ввода числа. Друг сказал, что это не надо, типа им сказали что принять, то что пользователь вводит всегда правильные данные (этакий сферический конь в вакууме), а вот лишние begin end, надо убрать и отступы с комментариями расставить.
А потом все жалуются - вот программисты не умеют писать безопасный код. [Ответ]

Сообщение от Pengvin:
главное - чтобы программа работала

Это условие по умолчанию, и мы его рассматривать не будем.
Безопастность кода(так же как и оптимизацию) надо накладывать уже ПОСЛЕ создания и написания четкого алгоритма решения задачи. И только в тех местах где это необходимо. Стоит трижды подумать, прежде чем изменять простую логику решения на более изощренную и неочевидную в угоду безопастности кода (ИМХО) [Ответ]

Сообщение от MadFish:
Стоит трижды подумать, прежде чем изменять простую логику решения на более изощренную и неочевидную в угоду безопастности кода (ИМХО)

безусловно. встраивать антиотладочные приемы, пользоваться упаковщиком на этапе разработчки - это маразм. Но не об этом, я хотел сказать о более просых вещах. Во время написания кода встроить проверку введенных данных - не такая уж и сложная задача, а она избавит от многих проблем в дальнейшем. Иногда бывает прет мысль, не отрываясь кодишь, забивая на всякие проверки возврата NULL и тд, а потом когда эта конструкция начинает неожиданно валиться от неправильно введенного имени файла или слишком длинной строки, имеешь нехилый геморрой, когда добавляешь условия проверки. [Ответ]

Сообщение от MadFish:
void * механизм отделения данных от алгаритмов (следующий шаг после ООП).

Имхо, бредовая мысль. void* отбрасывает нас назад к функциональному программированию, никакой это не следующий шаг. Есть более изящные и грамотные решения. STL, например, или Boost. Там алгоритмы тоже вообще ничего не знают о данных, но такой способ реализации более безопасен.

Сообщение от MadFish:
Организовать хранилище ЛЮБЫХ объектов. Все. Кроме void * решения нет, нравится или нет, но это так.

Согласен, на данный момент другого выхода из такой ситуации не вижу. Только вот в чем проблема: а нафига нужно такое хранилище? Что мне с ним делать? Единственное, что приходит в голову - типа свой менеджер памяти делать, но как нормально удалять эти void*? Какой деструктор вызывать? Т.е. надо где-то хранить информацию о типах? А не слишком ли гемморойно синхронизировать два хранилища, один с объектами, другой - с информацией о типах?
Ладно, у каждого свой метод создания себе проблем [Ответ]

Сообщение от SmallBo:
отбрасывает нас назад к функциональному программированию

В корне не согласен! Я не большой знаток функционального программирования, не могу сказать, что до конца понял дзен этой падиграммы, да и не уверен, что это шаг назад.
Но ты ИМХО имел в виду ПРОЦЕДУРНОЕ программирование. И вот тут я не согласен. Отделение алгоритмов от данных (когда алгоритмам начхать с какими данными они работают) а данные сами заботятся о своем существовании это, на мой взгляд, немаленький шаг вперед по сравнению с ООП, а не то что с процедурным программированием.

Сообщение от SmallBo:
Имхо, бредовая мысль. void* отбрасывает нас назад к функциональному программированию, никакой это не следующий шаг. Есть более изящные и грамотные решения. STL, например, или Boost. Там алгоритмы тоже вообще ничего не знают о данных, но такой способ реализации более безопасен.

Не согласен. STL и Boost (контейнеры, итераторы etc) это решение для данных которые можно типизировать на этапе КОМПИЛЯЦИИ!!! (те можно развернуть темплаты в код). А когда типы хранимых данных определяются в момент исполнения, тут тебе ни Boost, ни STL особо не помогут. Ну разве что ты void* засунешь в контейнер

Сообщение от SmallBo:
Только вот в чем проблема: а нафига нужно такое хранилище?

Запросто. Есть хранилище двоичных объектов (ну к примеру набор плагинов в виде двоичных компонент). Сами объекты проектируются сторонними разработчиками, и определить их природу заранее нельзя.
Твоя задача сохранить и передать обрабатывающей процедуре (тоже стороннего разработчика) цепочку последовательно исполняемых плагинов. void ** самое простое решение.

Сообщение от SmallBo:
но как нормально удалять эти void*

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

Сообщение от SmallBo:
Т.е. надо где-то хранить информацию о типах? А не слишком ли гемморойно синхронизировать два хранилища

Два слова: фабрика классов ( COM) [Ответ]

неахота создавать тему, спрошу тут:

Сообщение от :
class mytype
{/**/};

class class1
{
int a;
virtual void f(){a++;};
};

class class2:class1
{
mytype* n1;
mytype* n2;
mytype* n3;
//конструктор
class2()
{
n1 = new mytype;
n2 = new mytype;
n3 = new mytype;
}
//деструктор
~class2()
{
delete n1;
delete n2;
delete n3;
};
};

int main()
{
class1* p = new class2;
delete p;
};

обязательно ли делать виртуальный деструктор в class1 ? [Ответ]

как хочеш

если не создаш ( вот как щас ) то ~class2() не вызывается -> утечка памяти ( не удалились n1 n2 n3 )

если создаш, то вызовится ~class2() -> и всё будет ровно

и про директиву public не забывай [Ответ]

Сообщение от The_God:
если не создаш ( вот как щас ) то ~class2() не вызывается -> утечка памяти ( не удалились n1 n2 n3 )

значит обязательно.....

Сообщение от The_God:
и про директиву public не забывай

компилятор напомнит... [Ответ]

Сообщение от :
class1
{
int a;
};
class2: class1
{
int b;
};

class1* p = new class2;
delete p;

в этом случае все корректно? [Ответ]

Сообщение от xxx-men:
в этом случае все корректно?

будет вызван деструктор класса class1, если бы в class2 динамически выделялась память, произошла бы её утечка. [Ответ]

Сообщение от The_God:
при хитром множественном виртуальном наследовании будут глюки при присваивании к void* а потом обратно.

слух, а как это победить? [Ответ]

не используй приведение к void* [Ответ]

Сообщение от The_God:
не используй приведение к void*

ok
вопрос по другому

Сообщение от :
class a;
class b;
class MyAB: public a,b;
class MyB: public b;

есть адрес MyB, b находица по томуже адресу. (правильно? )
есть адрес MyAB, где находица a и где находица b?
что будет если MyAB обьявить так: class MyAB: public b,a? [Ответ]

внутреннее представление классов зависит от компилятора,
даже порядок расположения полей класса не стандартизирован в С++, т.е в классах состоящих из непростых объектов порядок может быть изменён по усмотрению компилятора,

если ты програмиш опираясь на какието свои предположения о внутреннем сторении класса, то это ты делаеш на свой страх и риск, такая программа может перестать работать при переходе на другую версию компилятора или на другой компилятор. [Ответ]

Сообщение от The_God:
даже порядок расположения полей класса не стандартизирован в С++

хм.. интересно....
адрес обьекта + 17байт = желаемое поле, не всегда будет верно (как я понял)
со структурами дело обстоит так же?

Сообщение от :
class a
{
/*
тут много полей, методов
*/
int x;
} myObject;
int* px= &myObject.x;

это может быть опасно?
("дурной тон", "прямой массаж сердца" со всеми вытикающими в расчет не берем ) [Ответ]

Сообщение от xxx-men:
это может быть опасно?

не, там есть фишка что когда класс или струкрура состоит только из простых типов ( char, int, float и тп ) которые в книжках называются типы-POD ( и нет виртуальных методов ) , то такая структура или класс лежит в памяти как описана, чтоб можно было её из файла прочитать ну и вобщем чтоб было совместимо с С. Единственное что может быть добавлены байты для выравнимания полей струкруты\класса.

а когда в классе\структуре появляются виртуальные функции, наследования, сложные типы ( std::string например ) и тп, то уже расчитывать на то что знаеш как оно там внутри всё стало лучше не надо.

както так [Ответ]