информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Портрет посетителяВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
при чем тут редактор? 24.09.16 14:35  Число просмотров: 1512
Автор: dl <Dmitry Leonov>
Отредактировано 24.09.16 14:40  Количество правок: 2
<"чистая" ссылка>
> Если сочинять что-то класса редактора с огромным
> количеством окон с документами и связанных с ними объектов,
> то - да.

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

> А как там с многопоточкой? Под VC6 с объектами
> синхронизации жуткая путаница. Но я плохо себе
> представлляю, как эти "Авгиевы конюшни" вообще разгрести.

На любой вкус. Можно по-прежнему пользоваться APIшными потоками и APIшными же объектами синхронизации, можно тонкой оберткой вокруг них в MFC (и какая там путаница, три с половиной основных объекта синхронизации, области использования явно выделены). Можно использовать стандартный std::thread, можно взять PPL (parallel patterns library).
<site updates>
[lj] студийное 18.09.16 18:43  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
студийное
http://leonov.livejournal.com/442118.html

После установки последнего апдейта к третьему апдейту 2015-й студии поддержку C++ и MFC в ней приходится восстанавливать ручками, без этого соответствующие проекты становятся просто неактивными (столкнулся на основной машине, потом проверил на рабочей). Это они здорово придумали.


Полный текст
Чёта я не понял... 19.09.16 14:37  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 19.09.16 16:18  Количество правок: 1
<"чистая" ссылка>
Они забыли включить в дистрибутив обновления автоматическое развертывание последнего vcredist.exe? Или у них lib'ы для MFC сгенерированы не для тех версий dll, что прописаны в манифестах обновления, так что WinSxS шлёт лесом при запросе нужных версий dll?
нет, там что-то поглубже vcredist было 20.09.16 23:04  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Там не простая ошибка загрузки библиотеки на старте приложения была, а в Solution Explorer'е неактивные проекты и предложение установить недостающие компоненты.
А зачем? 19.09.16 06:30  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Если у тебя проекты в C++ с MFC нужно что-то сежЕе VS6? Она что, код не эффективный дает?
Все плюшки 11-го C++ и многие 14-го. 20.09.16 23:05  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Так какие плюшки? 21.09.16 14:43  
Автор: Zef <Alloo Zef> Статус: Elderman
Отредактировано 21.09.16 14:48  Количество правок: 1
<"чистая" ссылка>
Я пробовал устанавливать новые версии и ничего, кроме гимороя с непривычным интерфейсом не поимел. Понятно, я программирую в есьма специфической сфере - неболльшие утилиты для связи с контроллерами, для которых нет OPC-сервера или из-за громоздкости или ограниченной функциональности не подходит SCADA. Одно время пытался написать свой графический редактор, но не хватило желания тратить время в общем-то впустую. И вот я почесал репу пришел к выводу,что ни - для обычной моей работы, ни для того редактора мне ничего. кроме C++ и MFC гн гадо. Одно время я поднанялся писать прогу для КБ измерительных приборов, по условию - на Борланд С и с толкнуллся с тем, что все его "плюшки" типа умных диаграм медленные до абсолютной неприменимости. Борланд строил график 15 минут, моя писулька на "голом" С - 1.5 секунды.

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

Т.е. в моем преедставлении смены версий среды разработчика не "плюшки", а гиморой на уровне переучивания летчика на другой самолет и, если конечный продукт не становится от этого "реактивным", то и не надо.
языковые 21.09.16 15:58  
Автор: dl <Dmitry Leonov>
Отредактировано 21.09.16 16:05  Количество правок: 4
<"чистая" ссылка>
Как минимум списки инициализации, лямбды, auto, range-based for // for(auto& o: objects){o->f();} вместо for(vector<myobject*>::iterator i = objects.begin(); i!=objects.end(); ++i){(*i)->f();}
Ну и всякие умные указатели, кортежи и bind, введенные в стандартную библиотеку (раньше их можно было, конечно, брать из boost, но я не уверен, что boost под шестеркой вообще взлетает).
Достаточно интересно, но в небольших проектах не принципиально 24.09.16 05:15  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Если сочинять что-то класса редактора с огромным количеством окон с документами и связанных с ними объектов, то - да.

А как там с многопоточкой? Под VC6 с объектами синхронизации жуткая путаница. Но я плохо себе представлляю, как эти "Авгиевы конюшни" вообще разгрести.
при чем тут редактор? 24.09.16 14:35  
Автор: dl <Dmitry Leonov>
Отредактировано 24.09.16 14:40  Количество правок: 2
<"чистая" ссылка>
> Если сочинять что-то класса редактора с огромным
> количеством окон с документами и связанных с ними объектов,
> то - да.

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

> А как там с многопоточкой? Под VC6 с объектами
> синхронизации жуткая путаница. Но я плохо себе
> представлляю, как эти "Авгиевы конюшни" вообще разгрести.

На любой вкус. Можно по-прежнему пользоваться APIшными потоками и APIшными же объектами синхронизации, можно тонкой оберткой вокруг них в MFC (и какая там путаница, три с половиной основных объекта синхронизации, области использования явно выделены). Можно использовать стандартный std::thread, можно взять PPL (parallel patterns library).
И, видимо, лучшая поддержка HighDPI? 22.09.16 14:29  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
это-то мне как раз без разницы :) 22.09.16 19:18  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Так M$ вуалирует тот факт, что ей насрать на собственное наследие — начиная от Windows API, и это выливается в выпиливание собственного кода, на этом построенного. 19.09.16 06:46  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 19.09.16 06:52  Количество правок: 2
<"чистая" ссылка>
А молодое поколение пусть осваивает среды, генерящие управляемый© код™, дотнеты, там всё под контролем ;)
Это бы еще хрен с ним, нотормоза от Нета - чудовищные. 20.09.16 14:01  
Автор: Zef <Alloo Zef> Статус: Elderman
<"чистая" ссылка>
Сравнивал сименсовскую ПЦС-ку с сименсовским же Скаутом. 1ая - на С++, 2е - Нет. 2е работает на столько медленно, что не успевает передавать данные в контроллер на скорости 19200.Т.е. запускается минут 10, вроде работаеет, контроллер видит, загрузку программы начинает, но виснет и через минут 15 выдает сообщение о невозможности записать переменные. На вдвое более быстром ноуте с гигом памяти все работат, но запускается прога так, что хочется слломать табуретку.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach