Страницы: Пред. 1 2 3 4 5 6 7 След.
RSS
Возможности разработки взаимодействия с БД (выбор инструментов), Javascript ИЛИ VBScript
 
Цитата
bedvit написал: массив вы сами создаете и управляете памятью тоже сами (вручную или автоматически - контейнеры стандартной библиотеки  std:: ).  std::vector сам управляет памятью.
то, что очень облегчает жизнь (мне сейчас)... благодарю... - действительно, С++ выше уровнем, чем С...
Цитата
bedvit написал: Здесь есть важное правило, если вы выделяете память: NEW (malloc), вы должны ее и освободить: delete (free), если не передаете по указателю за пределы библиотеки.
вот теперь вспомнила (после вашего напоминания): :idea:  "на каждый new должен быть свой delete"... или как вы написали - отдавать во вне (если библиотека)... ok
Изменено: JeyCi - 29.10.2019 17:08:55
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал: race conditions - это плохо.
race conditions
Цитата
Самое интересное и непонятное в том, что ошибка возникает в случайные моменты времени, а при попытке дебага — не воспроизводится!
C++11/C++14 8. Race Conditions - 2018
Race Conditions versus Data Races
Цитата
Состояние гонки всегда есть, если в общие данные пишет хотя бы один из потоков, когда другие их читают или пишут
Цитата
Состояние гонки возникает тогда, когда несколько потоков многопоточного приложения пытаются одновременно получить доступ к данным, причем хотя бы один поток выполняет запись.
P.S.
Синхронная асинхронность в C++
std::async
Техника написания аналога await/async из C# для C++
msdn Asynchronous programming in C++
Изменено: JeyCi - 30.10.2019 19:31:38
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Все же отмечу:
1. Многопоточность и асинхронность - это не одно и то же.
Статья на Хабре
2. race conditions имеет отношение к многопоточности, асинхронность здесь как бы не причем :)
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: race conditions имеет отношение к многопоточности, асинхронность здесь как бы не причем
спасибо!, потому что страшные вещи пишут на wiki
Цитата
Race conditions were among the flaws in the Therac-25 radiation therapy machine, which led to the death of at least three patients and injuries to several more.[17]
действительно,  IT в медицине - может стать страшной вещью из руках непрофессионалов, выпускающих мед.оборудование по принципу "быстрее, мощнее и т.д."
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Мне понравилась аналогия, приведенная выше по ссылке:
Цитата
Вы готовите в ресторане. Приказ приходит для приготовления яиц и тостов.

Синхронный: вы готовите яйца, затем вы готовите тост.
Асинхронный: вы начинаете приготовление яиц и устанавливаете таймер. Вы начинаете приготовление тоста и устанавливаете таймер. Пока они оба готовятся, вы убираете кухню. Когда таймеры уходят, вы берете яйца с жары и тоста из тостера и обслуживаете их.
Многопоточный: вы нанимаете еще двух поваров, один готовит яйца, второй готовит тосты. Теперь у вас есть проблема координации поваров, чтобы они не конфликтуют друг с другом на кухне при совместном использовании ресурсов. И они стоят дополнительных денег (хотя и ассинхронные вызовы стоят денег, прим.от меня)
race conditions - это когда два повара одним ножом режут зелень в чашке, а третий повар в эту чашку заливает яйца (зелень он до этого уже порезал). Все потому, что они независимые и никто их не координирует и не синхронизирует (задача программиста это сделать). Весело, но результат работы программы далёк от ожидаемого.
Изменено: bedvit - 30.10.2019 22:44:44
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: Многопоточность и асинхронность -  это не одно и то же.
насколько я поняла:
многопоточность - это о ядрах CPU - и стэке вызовов, который там... для передачи параметров в функции... т.е. для мат. вычислений может ускорить... и для работы с функциями...
асинхронность - это о IO(Input/Output) потоках, которые можно разбивать на Tasks. которые в свою очередь по сути есть "буфер участков кода", 1й из которых будучи запущенным и завершённым передаёт управление снова на себя для следующего элемента в (условно) цикле... а 1-й Task 1-го элемента продолжается 2м Task'ом и т.д.... и это уже Идёт (НЕ Идёт?? :qstn: ) в фоне... удобно чтобы всё не подвисало - т.е. загнать процессы в фон и там их выполнять, пока, например, двигать окно по экрану (т.е. в главном потоке)... [IO - насколько понимаю - монитор... и др]
По результатам тоже встречала, что использование асинхронности не обязательно ускоряет выполнение кода... и тут хороший совет (в комментах вашего линка):
Цитата
Наиболее оптимальный сценарий оказался, если скорость создания задач была +- равна скорости получения результатов, тогда количество потоков равномерно.
Что в принципе и так написано в любой книжке: выравнивайте нагрузку
действительно, переводы на рус.яз. иногда бывают странными и не совсем понятными, чтобы различить thread и async... я честно говоря так и не поняла, почему C++ имеет std::async, а при работе с ней речь идёт о threads в англ.яз. источниках... thread я думала - это поток на ядро... так всё-таки о чём речь в этой (std::async) библе C++??  :qstn: ... о разных ядрах или разных IO??...
Цитата
А вот создание «напрямую» new HttpClient абсолютно ничем не поможет. Всё равно будет ограничение на количество параллельных сетевых соединений.
?? и есть ли смысл, например асинхронно грузить 500 линков из сети, парсить json-структуру и раскидывать их по текстовым файлам... писать в 1 файл, наверно, не стоит - чтобы не получить неожиданностей... хотя если использовать блокировку, то можно и в один асинхронно, синхронизировав потоки записи (последовательность обработки тех или иных файлов не принципиальна)... - потом всё это добро в удобоваримом виде закинуть в БД...
P.S.
также видела, линка не помню, - что Сервер не работает в мультипоточном режиме!... и наверно асинхронную выгрузку разных SQL-запросов с сервера MS SQL Server (находящемся на дом. ПК, не в сети) тоже не организовать??... или как-то можно ускорить выгрузку нужных данных в текстоввики?.. хотя даже на сервер в сети - видела вроде есть ограничения - 2 подключения от одного юзера...хотя зачем 2, если SQL Server не работает в многопоточном режиме?... я ведь, наверно, никак не смогу подключиться от имени разных юзеров (ограничение до 10 для MS SQL Server Express) - чтобы за раз прогнать, например 10 запросов на выгрузку из БД разных SQL'запросных результатов Асинхронно?..
помню ответ
Цитата
не работает, не возможно
Изменено: JeyCi - 01.11.2019 16:00:47
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Понимание приходит с практикой. В теории, без практики сложнее разобраться.
Цитата
JeyCi написал:
500 линков из сети
Цитата
JeyCi написал:
можно ускорить выгрузку нужных данных в текстоввики?.
Скорость сети и HDD, даже SSD на порядки медленнее чем ЦП, кеши разных уровней и даже обычной ОЗУ. Зачем эта куча потоков, что бы в кеше SSD это ждало очереди на запись в файл? Одного потока хватит на десяток SSD :) Многопоточность эффективна для работы с единым кешем ЦП или с ОЗУ. Помоему даже вся переферия (ваши мышка, клава, принтер и т.д), опрашиваются последовательно системой. Мышь 125 герц (станд.) и т.д. скорости ЦП хватает делать это в один поток. Могу где-то упускать, поправьте где.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: для работы с единым кешем ЦП или с ОЗУ. ... скорости ЦП хватает делать это в один поток
верю...
думаю скорость очень сильно съедается при создании текстовиков (при загрузке)... и считывании из этих же текстовиков (при парсинге в PowerQuery, да и самом парсинге)...
попробую обрабатывать на Python - там вроде генераторы поинтереснее обычных способов чтения файлов... Оптимизация производительности...
также python сам парсит json своими силами - что также является его ++ом..
в отличие от того же JavaScript (который надо завернуть хотя бы в .hta - для какого-никакого интерфейса - чтобы встроенными средствами распарсить json'ы... ну или JavaScript API for Office 2016 (как указывала ранее) - не тестировала...
да и подгружает из сети Python норм по скорости...  - IDE PyScripter...
не идеал (т.к. пакетами грузит), но пример
при загрузке пакетами - для дальнейшего парсинга надо отслеживать конец response'а... можно по-простому, чтобы потом парсить:
грузит полностью и раскладывает в json-структуру

?? просто думаю, связываться ли с асинхронностью, т.к. вижу по сети, что не всегда даёт выигрыш в скорости... хотя возможность не замораживать окно - приятная деталь этого процесса...
ОТТЕСТИРОВАЛА:
касательно подгрузки из i'net модуль requests не даёт выигрыша по сравнению с VBA: примерно одинаковая скорость (~2,5min)...
касательно подгрузки из i'net модуль aiohttp НЕ на всех сайтах ОК (хоть и ~5sec): НО при большом количестве запросов (~400) к сайту - Access Denied на многие линки (хоть и не все) ...

===
p.s.
Python StreamReader тоже, наверно, считывать может быстрее, чем PowerQuery (для дальнейшей загрузки в excel/access потом)... просто, может и читать и парсить не придётся, если Python'ом сразу на лету приводить data в удобоваримый вид... на все нюансы, понятно, кода ещё писать и писать... просто смущает, что язык интерпретируемый... - стоит ли связываться, чтобы зависеть от чужих библиотек?...
?? или уже сразу на C++ делать и компилировать..
на Borland6 - http норм, для https надо, наверно, уже RAD Studio (там и json библа есть)... или искать библы и доставлять...
в любом случае ООП ещё изучить придётся... и Архитектуру!, чтобы потом не рефакторить, после моего ещё нулевого ООПа  8)
Изменено: JeyCi - 20.02.2020 15:14:13
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:   python сам парсит json  своими силами
для C++ всё находится - The Boost C++ Libraries - и python, и lambda, и regex, и даже json (в Boost.PropertyTree)... std::async поискать... но что-то из Coroutine есть - может оно...
на сайте и справка есть - пример для json
p.s.
и даже поддержка Borland 6 в v1.39 - ещё не тестила
p.p.s
https-загрузка есть в Borland - меню Indy. нет в меню FastNet (это только для http)
Изменено: JeyCi - 02.11.2019 10:53:11
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал: Одного потока хватит на десяток SSD  Многопоточность эффективна для работы с единым кешем ЦП или с ОЗУ
bedvit. поняла... значит наша чтение/запись из/в файл не ускорится... а если туда не писать, а сразу кидать в БД - то время по сути займёт только INSERT INTO - т.к. эта операция небыстрая становится, когда БД индексирована, потому что пересчитывать индексы... ок...
===
значит, многопоточность стОит выстраивать при работе со стэком и кучей - чтобы был толк от наличия 2-х и более ядер...
===
параллелизм - не очень интересная вещь - т.к. код просто уступает управление в цикле  в указанной точке, сохраняя контекст и, следовательно, может быть возобновлён позже... что по сути тоже пошаговое выполнение, только рывками... хотя для некоторых задач ок, чтобы, например, потом собрать всё(данные) из заранее выполненных частей(данных)... ну, или для каких др задач, которых у меня по сути ещё не было... действительно
Цитата
bedvit написал: Понимание приходит с практикой
- ок, может когда и встретятся задачи, для которых удобен параллелизм...
===
а сфера применения асинхронности:
Цитата
Асинхронное программирование – мощный инструмент, но он не полезен для всех типов программ. Например, если вы пишете программу, которая вычисляет число Пи с точностью до миллионных знаков после запятой, то асинхронный код вам не поможет. Такая программа связана с процессором, без большого количества операций ввода-вывода. Однако, если вы пытаетесь реализовать сервер или программу, которая выполняет ввод-вывод (например, доступ к файлам или сети), использование асинхронных функций Python может иметь огромное значение.
как раз для Пи - думаю, многопоточность больше подошла бы...
===
да и для асинхронности нужна асинхр. библиотека... например,
Цитата
в Python aiohttp может дать результат в ~2 раза быстрее, чем requests библ (т.е. модуль в python) - это связано с тем, что HTTP GET выполняется асинхронно...
спасибо вам за моё понимание... ок, теперь есть над чем подумать о скорости
Изменено: JeyCi - 02.11.2019 19:59:10
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
параллелизм - не очень интересная вещь - т.к. код просто уступает управление в цикле  в указанной точке, сохраняя контекст и, следовательно, может быть возобновлён позже... что по сути тоже пошаговое выполнение, только рывками...
Это неверное определение.
Цитата
JeyCi написал:
как раз для Пи - думаю, многопоточность больше подошла бы...
Здесь важна именно математика, а не язык программирования. Дело в том, что есть разный класс задач, которых хорошо паралеллятся, слабо и никак. Алгоритм числа Пи (писал давно довольно шуструю программку на С++ с расчетом любого количества знаков после запятой), паралеллится плохо. Для того, что бы посчитать следующий блок цифр, нужно знать предыдущий. Здесь же опять математика и алгоритмы.

А вот, к примеру, поиск простых/всех делителей натурального числа, паралеллится очень хорошо. Там же и алгоритм и код есть. Можете посмотреть.
Изменено: bedvit - 03.11.2019 12:36:04
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: Это неверное определение.
:oops: было очень наворочено объяснение кода в статье - Начало работы с асинхронными функциями в Python ...
===
наверно, действительно, есть объяснение попроще:
Параллелизм в Python – Введение
Цитата
Что такое параллелизм? Проще говоря, параллелизм – это возникновение двух или более событий одновременно
или такой вариант - Простое параллельное выполнение кода с помощью concurrent.futures...
наверно, в Python'e что только не обзывают параллелизмом...  :(
возможно слово "concurrent" лучше отражает смысл явления?.. -но тоже по сути управление и процессами, и потоками смешали в одном модуле (по сути библе)... намешали чего-то:
Параллелизм в Python – Темы
Цитата
Чтобы глубже понять функциональность потоков..........
а переходишь там же на Реализация потоков
Цитата
В Python ... реализуют потоки в программе: • модуль <_thread>
... это при всём том, что вроде в каком-то языке видела библу типа "thread.." для работы с несколькими CPU...  :sceptic:
===
наверно WIKI расставляет всё на свои места - Thread
Цитата
Multithreading is a widespread programming and execution model that allows multiple threads to exist within the context of one process....The threaded programming model provides developers with a useful abstraction of concurrent execution. Multithreading can also be applied to one process to enable parallel execution on a multiprocessing system.
Parallel computing
Цитата
Parallel computing is closely related to concurrent computing—they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency (such as bit-level parallelism), and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU).
благодарю за поправку... всё равно на рус.яз ресурсах всё как-то смешано
p.s.
я в предыдущем посте, наверно, наткнулась на concurency - потому и такой вывод получился..... а wiki вот как пишет (как подчеркнула в последней цитате)
Изменено: JeyCi - 03.11.2019 16:07:55
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал: Здесь важна именно математика, а не язык программирования. Дело в том, что есть разный класс задач, которых хорошо паралеллятся, слабо и никак.
математика понятно... но плюс к ней ещё и структура кода, полагаю... переменные для функций ведь передаются в стэк... значит 2 ядра = имеем 2 стэка... чем больше, тем лучше для такого рода задач (где переменные передаются в стэк)
Изменено: JeyCi - 03.11.2019 15:54:52
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
bedvit,
назрел (возможно) последний интригующий вопрос - Алгоритмический...
Join'ить рекордсеты мы не можем, поэтому всегда join'им на стороне сервера...
просто откопала какие-то Пересечения в Python - для массивов (через лямбда-выражение), множеств, массивов с пом. словаря - какой-то экзотический, словарей... сам же модуль records только если пакетом из PyPI, но этот пакет вряд ли умеет выполнять пересечение (хотя бы) ИЛИ (ещё лучше) ВСЕ ВИДЫ JOIN'ов... (возможно, есть смысл поискать в др. пакетах PyPI...
===
:qstn: Как с JOIN'ами алгоритмически выгоднее обойтись в C++ ??
если хочется с'join'ить 2 рода данных (по сути из json-файлов, но можно json'ы распарсить и в др. контейнеры) ещё до загрузки в БД... с'join'ить и закинуть в БД по сути отВПРенные рекорды... и интересно наличие вариантов для всех видов JOIN'ов - Inner, Left, Right, Full... какие промежуточные контейнеры для этих целей можете посоветовать (или напрямую из JSON структур) или, может, какие библиотеки, или/и какие Алгоритмы??...
Цель: ускорить (по сравнению с Power Query) - возможно за счёт работы напрямую с памятью... и добиться главной цели программирования
Цитата
Хорощий интерфейс - это невидимый интерфейс
т.е. убрать из посредников Power Query и всю предзагрузочную (в БД) обработку выполнить в памяти (в частности join'ы если нужны "до похода в сервер")... интересует скорость и удобство такого рода задач (join) в языке C++??...  :oops: ответ на этот вопрос развеет всю мою настороженность в адрес нового языка - так хочется выбрать C++ в противовес Python'у... (хоть в Python и удобно с json'ами работать, но с join'ами - пока встречаются велосипеды, иногда костыли)
p.s.
а может C# удобнее?..
(хотя, конечно, полностью откомпилированный проект на C++ удобнее, чем JIT-компиляция проекта C#)
Изменено: JeyCi - 07.11.2019 07:31:52
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
кстати и Окна и на C++, и на Python - можно оформить
p.s.
в Python'е есть и  библиотека графического интерфейса Tkinter
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: ?? просто думаю,  связываться ли с Python
хм, однако
Цитата
Python - удивительно удобный язык с единственным недостатком - медленный
... полагаю, по этой причине в нём постоянно придумывают какие-то life-hucks... e.g. Python | Which is faster to initialize lists
===
а в С++ с IO можно разобраться -
Быстрый ввод / вывод для конкурентного программирования
Ввод / вывод из внешнего файла в C / C ++, Java и Python для конкурентного программирования
p.s
Написание кода C / C ++ эффективно в конкурентном программировании
p.p.s.
но вопрос #164 всё равно остаётся на повестке дня... ??
Изменено: JeyCi - 18.11.2019 06:33:03
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, сформулируйте вопрос, на который вы хотите получить от меня ответ (если у меня будет ответ, я отвечу).
Цитата
JeyCi написал:
Как с JOIN'ами алгоритмически выгоднее обойтись в C++ ??
JOIN, в том понимании, в котором пишите вы это термин из SQL. Этих JOIN множество: inner, left, rignt, full и т.д.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: JOIN, в том понимании, в котором пишите вы это термин из SQL
именно в этом смысле... сделать без SQL... тупо использовать бинарный поиск для каждой записи (распарсенной из 1-ого json) для сопоставления с записью из др распарсенного json -- полагаю, вариант очень плохой -- записей исходника от 10000...
интересен алгоритм, библы, контейнеры для этого дела (Join) на С++?? что можете посоветовать?..
или вы предпочтёте это делать на С#? ... -- вероятно, на LINQ ?
(ВАЖНО: данные [структуры json] ещё не в БД и готовятся для записи в БД из текстовых файлов или строк, взятых из сети через oHttp.GET, -- выполнить join на этапе до загрузки в БД :oops: на дом. пк, без сервера в сети)
===
полагаю, можно рассмотреть вариант промежуточного сохранения распарсенных исходников в csv... а из csv - join'ить силами SQL... и потом INSERT INTO
===
:excl:  но интересует вариант без SQL и без промежуточных файлов... а сразу с'join'ить в памяти
===
P.S.
Python может сам объект json (без парсинга и перекладки в др контейнер) фильтровать, сортировать, поиск в нём делать - в самом объекте json... но не join'ить... как и ADO с рекордсетами...
интересует, как алгоритмически можно выполнить join максимально быстро... возможно есть вариант на С++?
(честно говоря, интересны все или хотя бы для затравки - просто пересечение Inner? лучше Left!?;
full outer join - вероятно, самый сложный, чем просто пересечение по ключам, т.к. ещё найти ключи отсутствующие в каком-либо из двух наборов -- но тут уж, полагаю можно найти разность, т.н. реляционную, и добавть в выборку, выполненную для inner)
Изменено: JeyCi - 07.11.2019 14:58:43
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
хотя, действительно:
Цитата
JeyCi написал: тупо использовать бинарный поиск для каждой записи... -- полагаю, вариант очень плохой
запустить этот поиск асинхронно или параллельно - если хватит памяти - полагаю, можно получить прирост производительности... хотя, будет ли здесь большая нагрузка на стэк при запуске каждого из 10000 элементов на поиск - полагаю, зависит от архитектуры, которую выстроим в коде (насколько задействуем маленький стэк)... хотя сам по себе стэк быстрый - быстрее, чем он не прогонит все эти элементы никто - запуская их в функцию бинарного поиска... имхо
Цитата
JeyCi написал: интересен алгоритм, библы, контейнеры
здесь, полагаю, тоже всё банально, как в python
а) - есть всё те же множества (set), и в алгоритмах - всё то же пересечение(set_intersection) их и разность(set difference) их... надо просто правильно создать 2 ммножества (ключей и item'ов) на каждую выборку (которые надо Join'ить)... и правильно применить указатели
б) если на vector'ах -
надо просто правильно создать vector на каждую выборку (которые надо Join'ить) и правильно применить указатели на индексы Эл-тов в них для поиска ключей в др массиве (vector'e) и массиве item'ов от этих ключей... и бегать по вектору для поиска... или методом бисекции... или начиная с C++ v.11 - lambda-expression find_if, предварительно sort...
в) да и словари(map) имеются в C++...
вобщем, надо писать, замерять время отработки и делать выводы  :)
Цитата
bedvit написал: (если у меня будет ответ, я отвечу).
спасибо, что даёте время поискать и подумать самой   8)
p.s.
для интереса - в NET - Под капотом у Dictionary и ConcurrentDictionary
С# - How to join 3 tables with lambda expression
Inner Join Using LINQ With Lambda
LINQ Lambda Left Outer Join and Right Outer Join
Изменено: JeyCi - 08.11.2019 08:54:48
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: всё банально, как в python
а главное отличие C++ от Python'a (в придачу к скорости) -
мне подумалось, в том, что яз C++ - это стандарт, который принимается от версии к версии... а библы (модули) PyPI для Python'a - это просто репозитарий практикующих программистов (которые пишут под себя и делятся с сообществом, не парясь о всесторонней универсальности своих наработок)... имхо
в любом случае, bedvit прав:
правила хорошего тона - создавать качественный продукт и писать к нему толковую специализацию и документацию для user'ов... и конечно же - преемственность - чтобы новый код не ломал код прежней версии и implicitly не вынуждал юзеров прежней версии перекраивать свои наработки на базе предыдущей версии... например предыдущей версии библиотеки
Изменено: JeyCi - 08.11.2019 09:44:29
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
В С++ есть  Контейнеры.
На любой вкус и цвет, под ваши задачи.
В Conway's Game of Life использовал std::unordered_map. Поиск, вставка и удаление выполняются за константное время. Для моих целей - это был самый быстрый контейнер.
Еще довольно интересен такой контейнер concurrent_unordered_map - позволяет параллельно-безопасно выполнять операции присоединения, получения доступа к элементу, доступа к итератору и обхода итератора. Т.е. можно использовать в несколько параллельных потоков. К сожалению, в моей задаче, сам алгоритм не позволил распараллелить нормально расчёты. В вашем, возможно, это получится.

Цитата
JeyCi написал:
но интересует вариант без SQL и без промежуточных файлов... а сразу с'join'ить в памяти
здесь я не понял, что вы хотите. Потому как нужно понимать, в памяти какого процесса (программы) лежат данные, в каком виде, и куда их дальше нужно отправить, есть ли доступ к этому процессу и т.д. Или это будет своя библиотека, тогда в память нужно подгружать данные извне - файл, API другой программы и т.д.
Изменено: bedvit - 08.11.2019 11:05:39
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал:  памяти какого процесса (программы) лежат данные, в каком виде, и куда их дальше нужно отправить, есть ли доступ к этому процессу и т.д. Или это будет своя библиотека, тогда в память нужно подгружать данные извне - файл, API другой программы и т.д.
сначала думала о библиотеке для подключения к vba (по примеру вашей сортировки) - скидывать json-строку в качестве BSTR для обработки (парсинг в out array - regexp'ом или библиотекой json в RAD Studio), потом на стороне VBA переложить массив в рекордсет и updat'ить бд... хотела всё это в Access из vba...
===
но потом подумала, что IO из файлов или даже запросы http для взятия этих данных из сети - всё равно лучше сделать асинхронно, раз уж есть возможность... иначе это долго на голом vba... поэтому, наверно, пока отдельным модулем в библиотеке для vba - подгрузка из сети (или чтение из файлов)... и только потом передача строки для парсинга json'ов... [здесь передача в др модуль библиотеки, о котором думала сначала (выше в этом посту) - только пока непонятно как передать на обработку др библой, но наверно, стандартно! - прописав все References в начале - задействовать библу для разбора json-строки/объекта уже здесь в др модуле библиотеки])
===
:excl:  а ведь, действительно, - на хорошую идею вы натолкнули: сразу 1 элемент (из одного типа распарсенного json) берём в рекордсет, 2й (из др типа распарсенного json) по ключу потом rs.find и дописываем в нужные поля... Эврика! - а то я что-то потерялась с этим Join... вобщем потом этот рекордсет в БД... но перекладку массива в рекордсет и передачу рекордсета в БД пока вижу только из vba... библу для работы с SQL ещё не видела в C++ ?!...
:) ХОТЯ через ADO подключились ранее на этой ветке в Borland'e - ЗНАЧИТ можно и из C++  :idea:
===
Вобщем, планировалась библа для vba... но по ходу смотрю - можно и какое скромное окошко сделать Application на С++, чтобы по кнопке сразу брать из сети данные (парсить по ходу) и  формировать рекордсет из 2х типов файлов и загонять в БД...
... можно скинуть в текстовики (но уже они будут в удобоваримом виде для БД - например, csv)... потом импортировать из БД (интересуют Access или MS SQL Server)... как-то так
===
Цитата
bedvit написал:   concurrent_unordered_map  - позволяет ... можно использовать в несколько параллельных потоков.
благодарю... наверно, пока на потоки делить всё-таки не буду, чтобы работало на любых (и одноядерных) пк без накладных расходов...
а вот про асинхронность подгрузки из сети или считывания из файлов на hdd - подумаю... std::async
p.s/
но например в Python
Цитата
asyncio не поддерживает файловый ввод-вывод
Цитата
В основе асинхронной системы Python лежит цикл событий. Он запускает весь код, включая main().
- и надо (обычно) делать все функции с приставкой async, внутри реализовывать переключение контекстов... к файловой IO это не имеет никакого отношения... а асинхронное чтение даёт aio модуль
а вот aiohttp - даёт асинхронную подгрузку
Изменено: JeyCi - 12.11.2019 08:57:46
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
bedvit написал: К сожалению, в моей задаче, сам алгоритм не позволил распараллелить нормально расчёты. В вашем, возможно, это получится.
возможно...
10 лучших алгоритмов и структур данных для конкурентного программирования
Конкурентное программирование
N.B.
Data Level Parallelism (DLP)
Цитата
such instructions which is vector in nature can be allowed for DLP
p.s.
Цитата
In some cases parallelism is transparent to the programmer, such as in bit-level or instruction-level parallelism, but explicitly parallel algorithms, particularly those that use concurrency, are more difficult to write than sequential ones,[7] because concurrency introduces several new classes of potential software bugs, of which race conditions are the most common.
Цитата
In parallel computing, a computational task is typically broken down into several, often many, very similar sub-tasks that can be processed independently and whose results are combined afterwards, upon completion.
Цитата
In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution.
Цитата
Communication and synchronization between the different subtasks are typically some of the greatest obstacles to getting good parallel program performance
Изменено: JeyCi - 09.11.2019 07:48:48
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
и выскажу ещё одну мысль, которая мне кажется камнем преткновения в выборе взаимодействия с БД (возможно, по причине того, что являюсь новичком в этом деле):
насколько понимаю, в природе возможна реализация взаимодействия между различными программами разными способами: через ООП (пишем объекты и их методы), по TCP/IP (на сокетах), функциональным программированием (пишем интерфейсы)... и выбор зависит исключительно от скорости и удобства...
===
В Сервере MS SQL Express реализована TCP/IP передача данных... хотя MS SQL Local версия по принципу memory-share...
и есть разные Interprocess Communication Mechanisms, что в принципе является основой и при построении многопоточности и выстраивании взаимодействия между процессами (разница между потоком и процессом отражена здесь)...
Коммуникация в среде TCP/IP происходит по клиент-серверной модели - хоть и требуется время на подключение, но сама передача данных затем возможна быстро и даже на несколько клиентов - Python: Listen on two ports... (хоть и есть проблема в Python - глобальная блокировка интерпретатора (Global Interpreter Lock — GIL)... но не об этом речь,)
===
а о Сокетах,
и на C# в том числе,
как впрочем и на C++...
и на Python:
наброски Клиента для подключения по TCP/IP на сокетах - в Python

[если хост в сети интернет] - (чтобы взять data для загрузки в свою бд)...
:qstn:  но что-то мне не верится, что можно получить данные со стороннего сайта таким макаром - ведь чужой сервер, наверно, не знает, что при запросе с такого клиента (как под спойлером) - ему надо бы вернуть ответ -- т.к. в нём этого не закодировано, а именем хоста я могу дать только  :qstn:  Host (который вижу в заголовках Fiddler) - а не все нужные мне странички с сайта этого чужого...
наверно, поэтому вариант  доступа к чужому серверу за нужной инфо - ? только стандартно через GetHttpResponce...
p.s. просто UDP Client - каждый запуск разный)

[если хост - свой пк, aka localhost (или 127.0.0.1)] - (чтобы выгрузить потом из БД нужные select'ы)...
:excl:  НО возникает 2-ая мечта (пощупать скорость TCP/IP) - будет ли быстрее, чем через ADO??... ADO ведь, наверно, не даст организовать параллельное выполнение запросов... а вот сокеты - всё может быть??  полагаю... но есть неуверенность - :qstn: можно ли с хоста "localhost" (мой компьютер) подключиться к 1433 порту для отправки серверу запроса и получения от него ответы, если сервер - тоже на этом же пк... КАК указать в хосте Путь к Серверу ??? - или сокет сам найдёт?.. или моя проблема лишь в том, что я не настроила порт 1433 ? - хотя вроде открыла его таким способом...  но не настроила Сервер на то, чтобы давал ответ (не знаю как) - может проблема в этом??.. а может проблема всё-таки в том, что MS SQL Server Express на локал пк (по сути имя компа и есть сетевое имя) НЕ :qstn: может взаимодействовать с др. софтом этого же пк (т.е. по сути такое же сетевое имя) ???... или не получается, потому что 1433-порт - это порт для прослушивания MS SQL Server, а не MS SQL Server Express ?
p.s.
или всё-таки возможность наладить TCP/IP connect в рамках одного пк - зависит от ОС ?
поскольку в UNIX - всё есть файлы! ... а в Windows. возможно. что-то другое - может, объекты??
===
(маршруты транспорта инфо, как и асихронность,, и многопоточность, - наверно тоже заслуживают внимания)
(в придачу к латентности SSD и скорости i'net провайдера)
Изменено: JeyCi - 14.11.2019 18:01:49
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
хм, хотя есть нюанс для сервера - его bind может разрываться, когда др процесс (др клиент, например) будет пытаться подключиться к этому порту, пока наш клиент молчит... хотя в принципе для запуска наших запросов и их выгрузки - нам не нужно постоянно заполнять канал listen сервера - чтобы всё время слушал нас... получили данные и пусть слушает дальше др клиентов - не проблема...
P.S.
Цитата
TCP устанавливает соединение и ведёт "разговор" между клиентом и сервером в рамках установленного соединения, пока кому-нибудь из них не надоест.
Цитата
UDP по сути просто отправка данных на какой-то адрес. Обработали его там или не обработали - для того, чтобы вам это узнать нужна дополнительная синхронизация.
их различия здесь
Что следует иметь ввиду при разработке с TCP
p.p.s.
вопросы предыдущего поста остаются, если кто в теме...
Изменено: JeyCi - 12.11.2019 09:32:20
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
наверно, всё-таки всё банально:
SOCK_DGRAM (UDP) - может заменить обычный read/write в файл;
SOCK_STREAM (TCP) - может заменить обычный ADODBStream;
- для пользовательского ПК ...
и навороты TCP connection нужны только для обмена инфо через сеть (не только) -  делает обмен данными более безопасным, но не сделает его более быстрым в случае ошибочного адреса хоста (т.к. клиент выжидает time-out, чтобы убедиться, что подключиться невозможно)...
===
уместен в условиях реализации сетевой модели данных...
===
:) всё-таки для работы с бд "первостепенно и достаточно" иметь НОРМ. реляционную модель данных !.. а умение MS SQL Server Express работать по TCP/IP - это лишь приятный бонус для многопользовательского режима... имхо... скорость это не увеличит, подключение так же занимает время (только если запрос плохой - берёт time-out на попытку всё-таки подконнектиться), запросы также быстро исполняются + ещё время на разбивку по пакетам, и на клиенте сбор этих пакетов воедино...
вобщем всё упирается в IO (для выгрузки нужной инфо)
P.S.
а с localhost (локал пк) подключиться к localhost (сервер на этом же пк) - не возможно, подключение будет отклонено... у меня так и не получилось... значит действовать по старинке - через ADO - лишь прогонять все запросы поочерёдно, либо силами асинхронности ?... - выделив задачи непосредственно запросов и их обработки для выгрузки
Изменено: JeyCi - 14.11.2019 17:44:44
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Добрый день. Давно просматриваю данную ветку - очень знакомая боль. Хочу поделиться своим опытом.

На всех предыдущих местах работы - ритейл, банковский сектор, нефтянка - обычному пользователю и главному специалисту не дают прав локального администратора. Нет возможности зарегистрировать dll, сделать pip install, тем более поставить borland or c++.

Использую следующую экосистему:
1) Excel + R (portable version) + sqlite:
Не требует прав администратора, R легко конектится к бд, можно делать параллельные вычисления, куча пакетов для json.
Пакет Excel.link позволяет запускать R из Excel vba.
Пакет RSQLite позволяет лить все в локальную бд избегая переполнение памяти.

2) аналитическая платформа knime:
Легко работать с json, rest api, любые бд. Итоговый workflow компилируется в bat файл, в Excel макрос готовит входные данные, потом запуск bat.

3) Talend Di - любые бд, любые данные, итоговый workflow компилируется в jar архив. Из Excel запускается консольная команда.
Talend esb - можно запустить свой rest api и уже из Excel посылать post запросы.

Все опен сорс, все быстрое, доступное обычному пользователю. Access использовал только как adp к SQL серверу.  
 
egonomist, сильно.
И это все оттого, что не дают прав локального админа, но работу надо сделать. Как объясняют?
Спасибо за инфо, не специалист, не смогу прокомментировать, но написано толково.
Такие пути решения не рассматривали:
1.Заявку в IT на установку нужных инструментов
2.
Цитата
egonomist написал:
зарегистрировать dll,
можно под пользователем.
«Бритва Оккама» или «Принцип Калашникова»?
 
День добрый.
Возможно это уже оффтоп, кратко по вопросу:
Не разрешено политикой безопасности.
Аналитика - это бизнесовая часть, не входит в иерархию ИТ-трудно лоббировать свои хотелки.
До вируса Петя можно было все,после ничего.
Служебками можно выбить установку по на свой комп,
Но результат твоей работы должен быть воспроизводим на пк других пользователей.

Маленькое дополнение к предыдущему посту:
Для каких задач используется:
1) Excel + R + sqlite - любые задачи обработки, хранения, визуализации данных. Пакеты data.table, dbplyr, tidyverse для обработки, ggplot2, shiny - графики, веб отчёты. Выполняемых код, находится на листе, его можно менять формулами, результаты работы сразу в Excel.
2) knime - парсинг json от рест запросов к веб сервиса,
ETL для бд, прогнозирование нагрузки контакт центра.
3) talend - обработка больших данных (более 10 млн. Строк), качественные тесты данных, join big data, Etl.

Для прочего BI ещё есть metabase.  
Изменено: egonomist - 15.11.2019 06:08:38
 
Тоже немного офтопа, немного по теме.
Перед глазами альтернативный вариант, пишу для сравнения.
Все рабочие файлы на серваке, с правильно политикой доступа и бекапом. Рабоче ПК под админом, т.к. нет разницы под кем пользователь работает в сети (для каждого свои права). Вирус Вася максимум убъёт локальный ПК, с образа рабочее место восстанавливается за 20 мин. Базы 1C-SQL-сервера, ORACLE-сервера (+самописная СУБД на ORACLE). Для спец аналитиков открыт доступ для чтения к нужным витринам, через ETL все прекрасно ложится в Excel. В т.ч. и SQL-запросы на 1С SQL -сервак (почти ничего вручную не выгружаем), все подгружается через power pivot, с доп обработками и join-ми с таблицами в Excel + WEB-через запросы, VBA. В итоге вся аналитика фрмируется напрямую из баз, WEB - за минуты (макс часы в случае годовых данных). Никаких танцев с бубнами. Что эффективнее пусть выбирают акционеры. Без претензий на истину.
«Бритва Оккама» или «Принцип Калашникова»?
Страницы: Пред. 1 2 3 4 5 6 7 След.
Наверх