Здравствуйте, VladD2, Вы писали:
VD>Что же я изверг что ли? VD>Время то засек?
Неа. разве что только примерно...
я там где то дальше ответил с прикидками по времени. нет времени сейчас искать, сорри
CC>> Обычный косяк в MSDN... VD>Ой, МСДН-а ли? У меня в МСДН-е все ОК.
CC>> У меня их кста 2 шт (MSDN-а) так в одном написано что надо передавать указатель на значение а в другом что надо передавать значение в uiParam.
VD>Это ты заметил. А ты не обратил внимание на маразматичность ситуации когда нужно значение приводить к указаетелю? Ты считашь это нормальным?
Дело в том, что это не первый такой косяк... Я уже довольно много на такую хрень наталкивался. Так что можно сказать — это "особенность реализации"
CC>> SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE); CC>> SystemParametersInfo (SPI_SETFONTSMOOTHING, FALSE, NULL, 0);
VD>А запоминать исходный вариант кто будет? VD> Да и во втором случае ты не включашь стандартное сглаживаение, ты выключаешь его вовсе.
Дык а зачем? задача стояла включить. Да и выключаю я (предварительно кстати задав обычный режим сглаживания, его значение = 0) только потому, что у меня оно отключено и со включенным сглаживанием на ЭЛТ все выглядит ИМХО ужасно.
VD>А вот как выглядит тоже самое на базе АПИ которое спроектировано более размуно:
По мне так это не API а обертка...
VD>К сожалению, чтобы из убогого ВыньАПИ-стиля сделать то что я продемонстрировал приходится писать вот такие вот обертки:
[skipped]
по моему тут явный перебор... "слишком многа обуви!" (с)
Здравствуйте, VladD2, Вы писали:
VD>К дотнету.
Пардон, опшипся
VD>А тебя не напрягает, что в дотнете доступны горы кода нре доступные в С++?
неа, не напрягает совершенно. Они мне эти горы покуда не понадобились. Тех гор, которые накоплены в сях мне пока хватает с избытком. VD>WinFX — это управляемая библиотека. Этим все сказано.
Меня интересует возможность вызова этой библиотеки из неуправляемого кода.
CC>>Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет? VD>Когда как. Вот WinFX в основном реализован на C# (частично на МС++). Только на низком уровне используются неуправляемый код (для отрисовки примитивов).
Меня это интересует с точки зрения как ее юзать не из .нет, если все же микрософт похерит нормальный API (а мне для системного программирования он и нужен).
Здравствуйте, aik, Вы писали:
aik>Эта самая dotnet — она уже года 4 разгоняется (раздается и поддерживается). Я пока не замечаю победного шествования.
Я тоже. Просто всё это время на ней пишу, и почему-то проекты всё крупнее и их всё больше. aik>Да где уж там "забудут". Куча очень квалифицированного народу в msvc6 до сих пор сидит, не понимая на черта им дотнет. Переход msvc5->msvc6 проходил ГОРАЗДО шустрее, чем на msvc7(2003/2005).
Это да. Сегодня лично видел код перцев, недавно перелезших с плюсов — "декораторы", "визиторы", круто! Даже неудобно было говорить, что использование хотя бы Data Access Application Block сведёт всё к двум строкам кода. А во втором дотнете хватит и одной.
aik>Это заблуждение что весь мир программирует мышкой аддоны к офису и sql клиентов.
кто ж спорит!
Здравствуйте, CreatorCray, Вы писали:
CC>Дело в том, что это не первый такой косяк... Я уже довольно много на такую хрень наталкивался. Так что можно сказать — это "особенность реализации"
И я. Но называю это "Особенностями национальной халтуры".
VD>>А вот как выглядит тоже самое на базе АПИ которое спроектировано более размуно: CC>По мне так это не API а обертка...
А какая разница что там внутри? АПИ — это интерфейс к чему-то. SystemParametersInfo тоже не сама все делает. Она обращается к другим АПИ.
Я же говорю о качестве проектирования, а не о том что там под копотом.
А качество очень невысокое. Конечно бывает и хуже, но и это не притяно. На работу с таким АПИ тратится куча времени. Особенно много времени тратится при изучении.
Даже поиск нужной функции/интерфейса занимает уйму времени. На программы с таким АПИ приходится убивать в разы больше времени, нежели на анологичные но создающиеся с использованием добротного АПИ. Думаю, одно это уже подталкивает к выбору фрэймворков со стройным и удобным АПИ.
VD>>К сожалению, чтобы из убогого ВыньАПИ-стиля сделать то что я продемонстрировал приходится писать вот такие вот обертки: CC>[skipped]
CC> по моему тут явный перебор... "слишком многа обуви!" (с)
Ну, там до кучи еще много чего просто. Не выдерать же из работающего кода куски?
Хотя конечно траха не мало. Зато в итоге простой, читабельный код и безопасный код.
Собственно о том и говорю, что если бы АПИ Виндовс сразу проектировалось грамотно, то и таких монстров клепать не приходилось бы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, VladD2, Вы писали:
CS>Кончина подзатянулась,
CS>Ровно как два года сообщению.
С тех пор произошли некоторые перемены. А именно из Лонхорна перед тем как он стал Вистой убрали весь managed code, за исключением .NET FX. WPF & WinFX в основную поставку Висты не входит, только как дополнение. WinFS, вообще выходит позже. Explorer из managed переделался в native, как я когда-то и говорил
. Вывод можно сделать такой: Майкрософт попытался сделать как сам советует: "If you are starting a new project, we recommend that you write it in managed code, which will provide maximum benefit...", и у него не сильно-то вышло. Пришлось немного откатить до следующей версии Windows. К тому времени WinFX и все эти framework'и устоятся, выдержат не по одному сервис паку. Тогда и можно будет говорить о переходе с native и написании программ исключительно на managed коде.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, что тебе не хватает в ОДБЦ по сравнению с ОЛЕДБ?
Я c ODBC ни разу не общался, но исхожу из того, что это набор функций, которые управляют ресурсами через дескрипторы.
У меня приложения состоят из модулей. Модули должны как-то согласованно использовать общие ресурсы. В случае БД это подключение и транзакции.
Дескипторы этой согласованности не предоставляют, а компоненты OLEDB — как раз для этого и придумывались.
По-моему в ODBC сильно хромает масштабируемость системы типов.
В OLEDB же:
Навороченность интерфейсов, которая всех так сильно пугает, меня наоборот убивает своей дальновидностью Я в начале этого года соорудил в своем провайдере поддержку вложенных транзакций. Так вот внутренние объекты практически полностью продублировали структуру OLEDB-ных.
Многие вещи, которые изначально казались глупыми, наоборот повлияли на реализацию. Например, центральный метод для выполнения всех типов запросов ICommand::Execute. Обычно разделяют методы для выполнения запросов, возвращающих множества и не возвращающих множества. Пока не реализовал свой парсер SQL-запросов, было тяжко подвести всех под одну гребенку
А потом понял, что через IOpenRowset::OpenRowset тоже можно запросы выполнять. Полгода перестраивал хоровод объектов, управляющих выполнением запросов, отделяя интерфейсы от реализации. Но, в конечном итоге, получил такую конфету, что самому нравится. Новые фичи FB2, которые раньше бы меня свалили в кому, добавляются без проблем. Нет, проблемы конечно есть, но не такие страшные.
Обработка ошибок в OLEDB повлияла на мое понимание исключений — как без напрягов, с обеспечением локализации, доставлять информацию о произошедшем сбое. Так, что бы конечный пользователь (или программер), смог понять что не так. В провайдере больше 200 шаблонов сообщений об ошибках.
Я помню, с каким пылом я спорил с тобой относительно реализации точек уведомлений — так вот, только недавно, когда реализовывал уведомления о коммитах и откатах, понял как должна выглядеть реализация комовских точек подключений. И как обеспечить реентерабельность.
Структура интерфейсов. Хотя их и много, но основная идея заключена в создании коротких специализированных интерфейсов. Хотя, на мой взгляд, в наборе IRowset-подобных интерфейсов перестарались с наследованием.
Концептуальных ошибок, влиящих на устойчивость, я знаю только одну — передача COM-объектов в качестве параметров команды. Но это было сглажено качественной документацией.
Возможно, если сказать честно — мне прет не сколько эта технология, сколько мой подход к её реализации — C++ был заюзан под самое нехочу. Но тут надо отдать должное возможностям и самого сервера IB/FB.
КД>>И если раньше я жался насчет каждого вызова к провайдеру/сервер,
VD>Это ты вот тут расскажи: VD>История одной оптимизации
Да ну их в баню
VD>Ох уж эти аналогии. И почему ты ОЛЕДБ к внедорожникам отнес? Работает ОЛДБ при доступе к сиквелу медленее. Используется наверно уже тоже реже чем нэйтивный провайдер. Так о чем разговор то?
Да я не вообще OLEDB, а конкретно свой провайдер. Мы его юзаем везде, где только можно. Сейчас вот победили проблему с .NET (люблю я Борланд, но странною любовью). Маленький, но все таки еще один шаг к новом и светлому будущему, где пишутся по-настоящему интересные программы
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Я c ODBC ни разу не общался, но исхожу из того, что это набор функций, которые управляют ресурсами через дескрипторы.
C API и эмуляция ООП. Что же ты хочшь?
КД>Дескипторы этой согласованности не предоставляют, а компоненты OLEDB — как раз для этого и придумывались.
Да? С чего бы это?
КД>По-моему в ODBC сильно хромает масштабируемость системы типов.
Нет там таких проблем.
КД>Навороченность интерфейсов, которая всех так сильно пугает, меня наоборот убивает своей дальновидностью Я в начале этого года соорудил в своем провайдере поддержку вложенных транзакций. Так вот внутренние объекты практически полностью продублировали структуру OLEDB-ных.
А зачем?
КД>А потом понял, что через IOpenRowset::OpenRowset тоже можно запросы выполнять. Полгода перестраивал хоровод объектов, управляющих выполнением запросов, отделяя интерфейсы от реализации. Но, в конечном итоге, получил такую конфету, что самому нравится. Новые фичи FB2, которые раньше бы меня свалили в кому, добавляются без проблем. Нет, проблемы конечно есть, но не такие страшные.
Боюсь, что это не конфетка, а тортик. Тольк вот ингридиенты подвели. Сложность черезмерная и не нужная.
Я тоже рашьне думал, что так инадо. Но вот видимо с годами приходит озарение.
КД>Обработка ошибок в OLEDB повлияла на мое понимание исключений — как без напрягов, с обеспечением локализации, доставлять информацию о произошедшем сбое. Так, что бы конечный пользователь (или программер), смог понять что не так. В провайдере больше 200 шаблонов сообщений об ошибках.
Прочесть локаль пользователя и сформировать стрку.
КД>Возможно, если сказать честно — мне прет не сколько эта технология, сколько мой подход к её реализации — C++ был заюзан под самое нехочу. Но тут надо отдать должное возможностям и самого сервера IB/FB.
Я понимаю твою гордость и удовольствие. Ты действительно сделал огромный труд, и я не сомневаюсь, что сделал его хорошо. Но это никак не оправдывает того что тебе пришлось написать такие горы кода. И никак не оправдывает того, что без АДО использование твоего провайдера привращается в муку.
Попробуй написать родной АДО.НЭТ-провайдер. А потом опишешь ощущения. Боюсь, тебя постигнет разочарование. Ты поймшь, что все что ты с успехом поборол было всего лишь созданные другими бессмысленные припоны.
КД>Да ну их в баню
Не, в баню слишком радикально.
КД>Да я не вообще OLEDB, а конкретно свой провайдер. Мы его юзаем везде, где только можно. Сейчас вот победили проблему с .NET (люблю я Борланд, но странною любовью). Маленький, но все таки еще один шаг к новом и светлому будущему, где пишутся по-настоящему интересные программы
Ну, если это доставляет удовольстие...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
КД>>Навороченность интерфейсов, которая всех так сильно пугает, меня наоборот убивает своей дальновидностью Я в начале этого года соорудил в своем провайдере поддержку вложенных транзакций. Так вот внутренние объекты практически полностью продублировали структуру OLEDB-ных.
VD>А зачем?
Зачем что? Продублировали? Да кто его теперь уже знает Интерфейсы внутренних объектов я проектирую и тестирую отдельно. В случае транзакций, оказалось что все (в виде ITransaction, ITransactionLocal и их отношения) придумали до меня
В свете этого знания, такие интерфейсы как этот, вызывают у меня желание биться головой о стену.
VD>Боюсь, что это не конфетка, а тортик. Тольк вот ингридиенты подвели. Сложность черезмерная и не нужная.
Ага, у меня уже пару лет вся рожа в креме
VD>Я тоже рашьне думал, что так инадо. Но вот видимо с годами приходит озарение.
Ну что бы понять интерфейс, с ним нужно прожить очень долго. OLEDB, это еще ничего. Тут иногда встречаешься с более мощными шедеврами.
Например, недавно я порадовался набору dbExpress. Мой диагноз — нужно меньше курить траву. И ввести наркологический контроль при приеме на работу. Я бы его сжал если не 50, то на 30% однозначно.
КД>>Обработка ошибок VD>Прочесть локаль пользователя и сформировать строку.
Не все так просто. Локаль ты подставляешь не в точке генерации исключения. Но это не важно. Важно то, сколько усилий нужно приложить для инициализации объекта исключений. У меня можно в одну строчку. Я описывал
как это выглядит. Второе — ошибка, пока едет наверх, может включиться как составная часть другой ошибки, а может попасть в коллекцию. Для того что бы это граммотно спроектировать реализацию такого поведения исключений пришлось выпить не одну бутылку.
VD>И никак не оправдывает того, что без АДО использование твоего провайдера привращается в муку.
Я не использую ADO, при программировании на плюсах. Мои враперы дают более сжатый исходник и быстрый бинарник. Проверено временем У ADO есть ценные трюки, но я основные подсмотрел и слямзил
и в примерах на нашем сайте. Жаль, правда, что когда я её планировал и писал у меня не было моего текущего опыта
VD>Попробуй написать родной АДО.НЭТ-провайдер. А потом опишешь ощущения. Боюсь, тебя постигнет разочарование. Ты поймшь, что все что ты с успехом поборол было всего лишь созданные другими бессмысленные припоны.
ADO.NET это просто виток с начала. И явное разделение этого слоя на два уровня — на тот, который общается с сервером, и тот, который потом эти данные хранит на клиенте. Разумно, но не интересно. Особенно, когда напишешь репликатор и осознаешь технологию выгрузки/загрузки данных.
Это с одной стороны. С другой — проще вряд ли получиться. Я тоже когда то думал, что запросы я могу просто подготовить и выполнить. Увы, сейчас для каждого типа запроса (DDL, select, insert, execute procedure, start transaction, commit, rollback, точки сохранений и т.д. и т.п.) пишется специализированная поддержка. Как я уже писал, со временем начинаешь управлять таким огромным числом мелких деталей, что приходится переходить на многоуровневую реализацию. Иначе наступает смерть проекта. Трое уже померли. Я про конкурентов
Так что подобие твоего ADO.NET у меня работает внутрях провайдера Процентов 10 от общего объема работы.
Главное, постоянно помнить, что пишешь всего лишь провайдер, а не сам сервер
КД>>Да я не вообще OLEDB, а конкретно свой провайдер. Мы его юзаем везде, где только можно. VD>Ну, если это доставляет удовольстие...
Ну вот, записали в садомазохисты
OLEDB это фигня. Вот программирование на BCB3 вставляло гораздо сильнее — натуральная "игра в сапера". Правда, потом я все таки переполз на BCB5 — нервы не выдержали
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
VD>Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
Сергей Губанов с Обероном...
Влад с .NET...
Ничего личного... просто пописал на 1С... много думал...
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>А что тут думать — Антон Батенев с ЯБУН'ом ...
Д>а что это за страшный зверь такой?
Пользуйтесь поиском по сайту
Кстати мысль вот.
Первого апреля на RSDN создать конференцию на один день. Посвященную проблеме программирования на этом самом
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Anton Batenev, Вы писали:
AB>>Сергей Губанов с Обероном... AB>>Влад с .NET... AB>>Ничего личного... просто пописал на 1С... много думал... КД>А что тут думать — Антон Батенев с ЯБУН'ом ... КД>Ничего личного ...
ЯБУН — "язык бухгалтерский — универсального назначения", если что...
Перечитал еще раз фразу Влада, но подставил этот самый:
Когда появлися ЯБУН, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо.
[...]
VD>---------- VD>Leonardo Blanco VD>Windows Client Platform Group, Microsoft Corporation VD>This posting is provided "AS IS" with no warranties(Выделено мной. — ГВ), and confers no rights. VD>[/q]
Ну английским же по белому было сказано!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
вот почитал ветку и подумал — у MS — WinAPI, захотела — будем под .net писать и ни куда не денемся — вспомните хотя бы переходный период dos->win. Хоть я и не поклонни Java но обидно, что альтернативная платформа остается в тени... хотя ведь может ?? Очередной раз убеждаюсь — у кого деньги и рынок — тот владеет всем. Ситация почти как из поговорки "если гора не идет к Магомеду, то Магомед пойдет к горе" — почти про MS и dev .NET
Здравствуйте, DivnenkoIvan, Вы писали:
DI>вот почитал ветку и подумал — у MS — WinAPI, захотела — будем под .net писать и ни куда не денемся — вспомните хотя бы переходный период dos->win. Хоть я и не поклонни Java но обидно, что альтернативная платформа остается в тени... хотя ведь может ?? Очередной раз убеждаюсь — у кого деньги и рынок — тот владеет всем. Ситация почти как из поговорки "если гора не идет к Магомеду, то Магомед пойдет к горе" — почти про MS и dev .NET
Деньги и рынок — это бабушкина логика. Каждый получает ровно столько результатов, сколько усилий и ума он вложил.
по моему тут явный перебор... "слишком многа обуви!" (с) 
