OpenGL:
Можно, но это неудобно, т.к. не будет ни трейтов (и динамическую диспетчеризацию придётся писать руками), ни деструкторов (и, если в си можно воспользоваться либо attribute cleanup, либо goto, то тут ничего из этого нет), и с массивами придётся работать исключительно через unsafe, чтобы проверок индексов не было. Проще уж на чистом си или плюсах тогда, если цель - ни грамма оверхеда.

https://forum.sources.ru/index.php?showtopic=419518&view=findpost&p=3838381

JoeUser:
Исторически сложилось, что ассемблер и си - это языки, на которых писались все системные шляпы (оси и их компоненты). Для этого существует уже много наработок, подходов и состоявшееся комьюнити.

1) Когда выгодно использовать ассемблер?
Когда ты на 100% уверен, что твой код наиболее эффективен.
Как правило, это относительно мелкие, продуманные участки программы.

2) Когда лучше использовать Си вместо ассемблера?
Когда ты пишешь достаточно объемные участки кода, либо неспецифичные.
Тогда разумно полагаться на компилятор и линкер. Ведь они умеют неплохо
оптимизировать код. Простой пример. Ты пересобираешь ядро, мир *nix
системы. Пересобираешь именно под себя. Ты вправе задать компилятору
флаг, который укажет оптимизировать код именно под нужное тебе семейство
процессоров. В результате некоторые участки кода будут задействовать те
фичи, которые есть в твоем процессоре, и которые будут более удачным
решением, нежели ты их заменишь командами общего назначения.

3) Когда лучше использовать С++ (или Rust) вместо Си?
Когда ты осознанно можешь выделить так называемые абстракции с нулевой
стоимостью ("zero-cost abstractions"). Иными словами, используя абстракции
более высокого уровня, которые дают удобство программисту, ты должен
осознавать, что это повлияет на качество (скорость, потребляемые ресурсы)
несущественно, либо вообще не повлияет. В принципе это можно отнести
и ко всем языкам, но в языках более высокого уровня проще напороться на
незаметные на первый взгляд оверхеды.

4) Когда лучше использовать Rust вместо С/C++?
Тут скорее дело вкусовщины, практики, наличия комьюнити, наличие цели.
Лично мне Rust очень симпатичен. Но, если подворачивается практическая
задача, да еще есть и ограничение по времени - я даже не заморачиваюсь,
и начинаю ее решать, используя С++. Все просто - наличие практики. Так
даже сотня написанных хэлоу-ворлдов на Rust не сделают этот язык твоим
рабочим инструментом. Только реальный/реальные проекты, только время.
Отсутствие уже устоявшихся стереотипов в разработке на других языках
возможно даже будет бонусом.

Все написанное выше - ИМХО. Ошибаться право имею! :)

Добавлено 06.09.20, 05:50

В Rust, также как и в C++, ты можешь отдельные (наиболее требовательные) участки кода писать в стиле процедурного программирования, не так ли? Ну а если совсем уже невмоготу - использовать unsafe блоки. Тогда от оверхеда вообще можно избавится.

https://forum.sources.ru/index.php?showtopic=419518&view=findpost&p=3838375

ЫукпШ:
Чтобы система не сопротивлялась, надо её не загружать.
Поэтому я и предлагал - загрузим WINPE с внешнего носителя.

https://forum.sources.ru/index.php?showtopic=419503&view=findpost&p=3838370

Chilling0ut:
Ого, ничего себе.
Вот так доверяй всяким вакансиям

https://forum.sources.ru/index.php?showtopic=102647&view=findpost&p=3838368

ЫукпШ:
Хотелось бы узнать.
Можно предположить, что ограничение в 260 символов (MAX_PATH) - это для совместимости
со старыми системами. Не исключено, что теперь вообще никакого ограничения нет.
А если есть, то возможен более длинный путь.
---
Cделать такое просто - например пакуем группу файлов
вместе со структурой всех директорий в которые они входят.
А потом распаковываем всё это хозяйство в "глубокую" иерархию
уже существующих директорий.

https://forum.sources.ru/index.php?showtopic=419503&view=findpost&p=3838362

Oleg2004: ЫукпШ
Спасибо з совет...Я как раз с помощью "rmdir /s /q dirName" все таки почти все убил...Но какими усилиями, туды его...И из под 7-ки сопротивлялась, и из под 10-ки стояла насмерть эта папка...при этом показывала чудеса по размерам - перенес на внешний все 52 Гига - осталось 13 гигов...потом осталось 2 гига, которые ничем не удалаемы ну никак...ну и хрен с ними, 2 гига можно себе позволить мусора.
В общем помучался ооочень как...

Да, эта проблема решилась на удивление просто...файла переименовываются почему то без проблем, после чего и удаляются. Вопрос в другом - как винда такое себе могла позволить? Каким образом имена в 303 символа могут появиться в файловой системе NTFS ???

https://forum.sources.ru/index.php?showtopic=419503&view=findpost&p=3838354

Akina:
Обычно это приколы дефендера, который начинает сканить накопитель на предмет разжиться свежими вирусами. Реже виновен эксплорер со своим созданием эскизов, ещё реже - индексирование.

https://forum.sources.ru/index.php?showtopic=419527&view=findpost&p=3838353

Евгений Епишков: Требуется разработать модуль для CMS OpenCart, позволяющий:
- парсить цены на определённые товары на сайтах конкурентов;
- собирать и выводить информацию как в таблицы, так и в карточки товаров на сайт;
- иметь удобную форму ввода;
- автоматически сравнивать информацию из прайс листов с результатами парсинга;
- получать уведомления в установленной форме;
- не перегружать сайт и не конфликтовать с другими модулями на нём;
- легко интегрироваться на сайт, иметь возможность точной настройки, чистый, читаемый код.

Если заинтересованы - готов выслать и обсудить готовое ТЗ.

Разработка ведется под руководством главного веб-разработчика сайта.
Язык – PHP.
Понятные требования и промежуточный контроль результатов.

Модуль пишется для запускающегося сайта маркетплейса.
Стоимость стартовая, обсуждается на основе ТЗ, как и сроки.

Любые подробности – по запросу.

Жду вашего ответа
по телефону: +7(906)265-79-24, Евгений (WhatsApp, Telegram);
или эл.почте: epishkov.e.s@mail.ru.
Заранее спасибо

https://forum.sources.ru/index.php?showtopic=419530&view=findpost&p=3838347

korvin: Кстати, возможно, в интеграционном тесте лучше не мокать субкомпонент, или добавить к мокнуты ещё тесты с использованием реального инстанса субкомпонента, иначе некоторые изменения не отловятся тестами

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838344

D_KEY:
Во, кажется это ответ на мой вопрос :)
Осталось понять, как правильно писать интеграционные тесты в C++ :D
А то я так понимаю теперь, что у меня всегда были юнит-тесты, которые пишут разрабы, и системные, которые пишут qa.

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838343

korvin:
Э, ты путаешь тёплое с мягким, тип проверки зависит от типа теста и не зависит от уровня тестируемого компонента в системе. Работу целиком проверяют end-to-end и системные тесты. Как только ты принял решение выделить из высокоуровневого модуля под-модуль, сначала ты должен поменять тесты соответствующим образом, в этом же суть TDD: любое изменение начинается с тестов, т.е. сначала нужно убедиться, меняется ли архитектура/требование, потом отразить изменения в тестах, если нужно и только потом — в реализации.

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

– если ты делаешь инверсию зависимости для этого субкомпонента, то твой изначальный тест суперкомпонента нужно разбить на два:
1) юнит-тест, который будет мокать/стабать интерфейс зависимости и проверять корректность входа/выхода суперкомпонента
2) интеграционный, который также будет мокать/стабать интерфейс зависимости, но проверять само взаимодействие, т.е. например, убеждаться, что суперкомпонент при каком-то входе вызывает метод интерфейса зависимости, нужное количество раз с правильными параметрами

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

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838342

D_KEY:
Это да. Но вопрос изначальных тестов. Они же исходят из высокоуровневых задач и будут проверять работу целиком. Соответственно, они должны будут или перейти на уровень интеграционных или, став юнит-тестами для самих высокоуровневых юнитов, перестанут проверять высокоуровневые задачи.

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838341

korvin:
Не обязательно, зависит от архитектуры. У тебя же высокоуровневая задача является некоторой композицией низкоуровневых, вот смотри, в моём примере, я переделал высокоуровневый сервис (относительно Accounts, Transactions, Compliance, Notifier) Transfer, чтобы он не включал зависимости внутрь себя, т.е. вместо

получилось

где Transfer хоть и реализует высокоуровневую логику посредством остальных компонентов, но расположен на том же (структурном?) уровне фактически.
Composer в свою очередь может быть абстрактным и тривиальным и иметь свои юнит-тесты. Естественно, можно сделать и интеграционные тесты (они ж не взаимозаменяемы с юнит-тестами), а на самом-самом верхнем уровне ещё добавить функциональные/end-to-end/системные тесты.

Добавлено 05.09.20, 11:47
Ну, собственно, если у тебя правильная инверсия зависимостей, то высокоуровневый модуль полностью независим от низкоуровневых и ты можешь писать нормальные юнит-тесты для него )

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838340

Chilling0ut:
Категоричесвки не согласен

https://forum.sources.ru/index.php?showtopic=102647&view=findpost&p=3838335

D_KEY: Вопрос к практикам. Вот начинаем мы какую-то новую штуку кодить по TDD. Мы начинаем же с самых высокоуровневых задач? Т.е. сначала пишем тест на высокоуровневую задачу, верно? Потом, при развитии, проверяемая такими тестами функциональность в любом случае будет раскидана по нескольким юнитам. Так вот вопрос, эти более ранние тесты становятся интеграционными? Ведь у каждого юнита появится свой тест.

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838334

Idarkainfiz: Уверяю вас.

---
Вторая часть не очень... скачать fifa, скачать фифа а также кряк для fifa 15 скачать fifa

https://forum.sources.ru/index.php?showtopic=419528&view=findpost&p=3838329

Gonarh: processexplorer + фильтр на диск

https://forum.sources.ru/index.php?showtopic=419527&view=findpost&p=3838328

ЫукпШ:
Назначить себе (или другому юзеру) все права
на папку и всё вложенное можно так:
"cacls dirName /T /E /P USER:F"
(а запретить "cacls dirName /T /E /D USER")
После этого:
"del /s /q /f dirName"
"rmdir /s /q dirName"
---
Но самое быстрое решение проблемы - это, вероятно, загрузить WINPE
с внешнего носителя.

Добавлено 05.09.20, 00:53

Это можно решить так:
explorer-ом переименуем директории, входящие в имя файла.
Например, "Windows" -> "w" и.т.п.

https://forum.sources.ru/index.php?showtopic=419503&view=findpost&p=3838327

Костик+: Привет, всем!

Подключаю через USB внешний HDD. Когда воспользовался им и пытаюсь отключить через трей внизу (как обычную флешку), то выскакивает сообщение, что не удаётся отключить устройство (ещё занято). Закрыл все программы на Windows, всё равно не возможно. При этом HDD гудит и мигает светодиод, будто идут операции чтения/записи.
Есть программа Unlocker (https://ru.wikipedia.org/wiki/Unlocker), которая позволяет выявить процесс, который держит открытым дескриптор и с файлом/каталогом нельзя сделать какие-то манипуляции (например, скопировать или удалить).
В связи с чем вопрос - есть ли подобная программа для HDD, чтобы можно было посмотреть, какие процессы не дают отключить его? Желательно, с возможностью "убить" эти процессы.


ОС: Win 7 x64

Да, раньше таким образом отключал винт и было всё ок.

https://forum.sources.ru/index.php?showtopic=419527&view=findpost&p=3838326

Sunless: Какой из языков сложнее - C или Rust?

https://forum.sources.ru/index.php?showtopic=419518&view=findpost&p=3838321