Цитата |
---|
JeyCi написал: прилагаю файл со скриптом JS - правильно ли написан?? |
Не уж то нет форумов, где обсуждается JS?
15.06.2019 19:21:02
Не уж то нет форумов, где обсуждается JS? |
|||
|
|
15.06.2019 19:35:26
да ещё и тема в курилке (как положено)... - поэтому ваш троллинг не имеет оснований... пройдите мимо - поберегите нервы... за Excel и VBA идите в Основную ветку
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
18.06.2019 12:28:25
большеват оказался VS... кстати нашла норм. альтернативу -
--- вот только вопрос по Профайлеру нарисовался - скрин прилагаю - т.е. p.s/ т.е. на скрине я пометила логически вытекающие вопросы из увиденного (правильно ли смотрела?) - повод подумать, как с увиденным бороться? [т.е. переписать-оптимизировать код]... вопрос про unsafe - смутил !unsafe... p.p.s. это, думаю последний вопрос, чтобы начать разрабатывать логично/корректно... а так - win_form уже получилась - осталось синтаксис нарабатывать опытом... thanks a lot всем... буду передавать sql-комманды в управлюющий код (благо на с-подобном уже пробовала это дело - из void в void ходить) p.p.p.s кстати поняла: Консоль тут не при чём (в кодировании на c#) -- мы ведь при создании проекта можем выбрать Консольное приложение ИЛИ Win_Form ИЛИ любое другое... а увидеть какую-либо переменную в SharpDevelop и на C# можно и в Locals и в Messagebox.Show... (и не надо тянуть в консоль )
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|
|
|
18.06.2019 17:46:00
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
22.06.2019 09:41:46
стоит отметить, что в создании корректного проекта и его сборки на C/C++ важную роль играют не только
=== а для C# стоит помнить особенности также - хотя IO потоки в принципе дело небыстрое и неблагодарное при записи файлов, что также, как и любую отрисовку форм, можно приписать к выражению "Хороший интерфейс - это невидимый интерфейс"... всегда лучше всё делать в память... насколько её хватает... но т.к. даже в .NET можно применить unsafe mode ( === p.s. и после всего написанного кода в Visual Studio подробности:
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|
|
|
22.06.2019 16:50:18
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||
|
|
22.06.2019 21:13:14
|
|
|
|
23.06.2019 12:04:26
p.s. а вообще там достаточно интересные статьи... p.p.s кстати где-то на хабре встретила статью, что у Visual Studio 2017 есть какоё-то bug, приводящий к overflow при или после компиляции C++... Вобщем 2019 будет понадёжнее для unsafe code, полагаю...
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
23.06.2019 16:35:04
Изменено:
«Бритва Оккама» или «Принцип Калашникова»?
|
|||||
|
|
24.06.2019 13:01:26
вот, возможно, по вашему линку речь об этом:
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||||
|
|
28.06.2019 11:50:48
и всё-таки век живи - век учись...
"легкость добавления потоков, не утруждая себя думами о стандартных проблемах, которые неизбежно сопровождают многопоточные приложения!"... хоть и "недостатки ленивых вычислений"... ==== "функциональное программирование vs. императивное программирование - чтобы не бегать циклами со всеми вытекающими удобствами"... и о проблемах делегатов в самом LINQ, также особенности использования списков... ==== значит ВОТ и споcоб ускорения не в ущерб читаемости: -- где надо - перейти от ООП к ФП... что и можно реализовать в C#... (хоть сам Excel и многопоточен, полагаю, поскольку в его настройках есть свойство "использовать все ядра" [наверно, знает, для чего использует]... но код написанный на vba лишь прямолинеен) p/p/s хотя LINQ можно использовать и в составе C++, и VB, и C# (вроде встречалось такое)
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|
|
|
28.06.2019 15:24:37
Попробуйте перейти. О результатах напишите.
«Бритва Оккама» или «Принцип Калашникова»?
|
|||||
|
|
29.06.2019 10:15:12
перейти-то - перешла, а о результатах ещё, наверно, рано... - надо как-то идеи пробовать вставлять в свой проект - тогда и результаты будут... а вообще - интересно (оттуда по линку) -
p.s. вообще, ну и, как всегда, ускорение загрузки и парсинга json-файлов интересует для вставки потом в бд... конечно, если будут результаты - отпишусь... (но думаю, не скоро - т.к. по сути это будут уже не переделки к имеющемуся, а совсем новая история) p.p.s спасибо за линки !!
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|
|
|
29.06.2019 19:23:06
действительно, наверно, потому что многопоточность в VBA не организовать - а то, может [на JS], и выкрутиться удалось бы... ?.. !хотя всё равно ресурсов не хватило бы... (да и писан тот код для скриптовых языков с использованием ScriptControl Ref в Tools[vbe], хоть и реализация объектной модели [?COM], насколько поняла?)
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
29.06.2019 22:46:02
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||
|
|
29.06.2019 23:44:55
? - как рациональнее распорядиться кучей и стэком в памяти (особенно стэком!) - чтобы на 2гб ram творить чудеса на С++... - чтобы суметь всё! (пусть даже за счёт мЕньшей скорости успевать всё укладывать в память, но не превышать её) - как-то порционно обрабатывать входящие данные?.. или многопоточность спасёт даже для скорости при ограниченной памяти? p.s. понятно, что нужно какие-то деструкторы писать... но как расчитать момент их включения (например при порционной обработке) ?.. или для ограниченных ресурсов есть какие-то другие более эффективные алгоритмы для С++?.. (чтобы не попасть в overflow) p.p.s хочется, конечно, также, как на сервере, - читать память, а не хранить в памяти… но, наверно, не дано... ну и например, если брать поштучно json-файлы [для цели порционно], то ведь процедурная природа С++ не даст ни цикл создать, ни модульность для передачи в функцию … а писать для каждого json свой обработчик – тоже не вариант… надо сразу брать всё… можно даже, оформив это всё в один массив json-синтаксисом… но тогда [даже если памяти на это хватит] потом разбирать строку [которая по сути в с++ есть массив символов] – есть ли лимит у длины такого массива?.. и опять же вопрос память тут и нарисуется (overflow)… если данных уж больно много… наверно, всё-таки нет более адекватного варианта – кроме как использовать CLR для зацикливания и С++ как dll … или через unsafe mode организовывать парсинг в рамках CLR цикла – наладив взаимодействие между ними… думаю, на голом С++ - не всё так радостно, как скорость может порадовать…
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
30.06.2019 07:07:35
[и не в мощи железа всё дело!]
Overflow
p.s. значит 3-й вариант - это всё-таки тоже вариант??... не понятен залог успеха этого варианта - как и за счёт чего? p.p.s вобщем, по-байтово считать память !!!..... ... полагаю, стэк всё равно ? не задать на весь ram, как хочется (почти весь за исключением уже использованного ос)
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||||||
|
|
30.06.2019 10:02:20
поэтому и приходится мониторить глубину дерева при, например, рекурсивном обходе... [как и в PQ, полагаю, когда говорят что там нет циклов, есть только рекурсия.. т.к. ФЯ] ===
хотя для web - выход избегать overflow: ===
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||
|
|
30.06.2019 10:11:09
а вообще,
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
30.06.2019 12:02:10
Вот когда вы сами познакомились с функциональным программированием, вы наверное поняли, что не везде его можно использовать и профита нет. А отказ от циклов, в пользу рекурсии (плюс отказ от динамических переменных, в силу модели вычислений без состояний) жрет стек. Итого не вижу целесообразности в использовании ФП, кроме особо специфичных задач.
По стеку - переходите на кучу. Это нормальная практика в С++ для больших структур (массивы, строки, и т.д.). Стек хоть и быстрее, он многим меньше кучи и используется под хранение параметров функции, локальные переменных и другой информации, связанная с функциями. Разделить выполнение кода в С++ потокам вообще не проблема. Только нужно понимать, что алгоритм должен поддерживать распараллеливание (не любой алгоритм можно эффективно расспаралелить) и количество потоков, обычно не должно превышать количества логических ядер на вашем ЦП. Для чего вам 2000 потоков, у вас 2000 ядерный ЦП? Ну и будут потоки стоять в очередь на логическое ядро, как в последовательном процессе, плюс затраты на выделение потока.
Изменено:
«Бритва Оккама» или «Принцип Калашникова»?
|
|
|
|
30.06.2019 13:40:44
дополню (как знаю) : главный поток - всё равно всегда один и он контролирует начала и завершения остальных потоков... и всё равно не завершится пока не завершаться все доп. потоки... спасибо, что дополнили, что они в очереди на ядро ЦП ... и что
=== теперь к слову о разрядности ОС (к чему в принципе привязан и допустимый RAM)... зачем мне больше 32x, если таких цифр у меня в принципе не будет в ценах... надо только прикинуть размер массива символов строк возможный (из всех моих json-ов, полагаю) ... чтоб не превысить 32x разрядов (насколько понимаю)... хотя на кибере хороший топик (
=== и к слову о RAM - да, наверно, до 3-х можно увеличить - если 2гб для Access (хоть и не весь он лезет в ram, а лишь его интерфейс и функционал)... а к данным драйвер просто подключение делает... а само по себе увеличение RAM ради 64x-разрядности мне по боку, полагаю ... да и быстрее 64, чем 32, - при одинаковых алгоритмах и количеству данных - не будет при более мощной ram, если её нет смысла использовать?? [мощность ЦП всё равно, наверно, поважнее будет?] ===
Обязательно приму на рассмотрение. Благодарю. p.s. вот такие промежуточные выводы пока... если в чём критически ошибаюсь - черканите please... в любом случае - спасибо за наводку резкости в моих глазах и моём зрении на 'скорости' p.p.s и самое главное при рекурсии Дерево то лучше делать квадратным, чем глубоким... но тут я пока слеповата... надо ходить в google
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||||||
|
|
30.06.2019 16:14:00
p.s. честно говоря, всегда думала, что 64x изобрели для разукраски той же windows7, и подгрузки этого добра из ram... а не для увеличения возможностей бытовых юзеров... (не имею ввиду крупные корпорации с большим потоком бизнес-инфо, прокручивающейся за день через их железо и софт)
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||
|
|
30.06.2019 17:44:23
Ух, сколько всего вы намешали в кучу.
Перешли на х64 вынуждено, т.к. х32 не поддерживает адрессацию памяти более 4 Гбайт на все процессы. Это мало в современном цифровом мире. Стек использовать надо с умом, он ограничен. Куча это общая память, ее столько, сколько у вас оперативки, даже больше с учетом файла подкачки. Пользуйтесь этим мощным ресурсом.
«Бритва Оккама» или «Принцип Калашникова»?
|
|||
|
|
30.06.2019 18:03:25
Изменено:
«Бритва Оккама» или «Принцип Калашникова»?
|
|
|
|
30.06.2019 18:39:59
p.s. честно говоря, отходила... и по дороге вспомнила, что предыдущим постом вы как раз и советовали кучу, а я всё на автомате про стек - вернулась, чтобы дописать по ветке, а вы уже и линки оставили... thanks... вобщем всю память имела ввиду - и кучу, и стэк... пошла знакомиться с вашими линками...
получу ли я очень большой выигрыш, если начну писать для 64x (и переходить на 4гб ram) ?? или такое посчитать - это, действительно, намешала я чего-то ? === (просто думала, что куча - это часть памяти, где выполняется сам написанный код) всё - вопрос снимается после вашего
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||||||
|
|
30.06.2019 19:11:42
но есть ведь и другой смысл кучи -
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|
|
|
30.06.2019 20:56:04
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|||
|
|
30.06.2019 21:13:18
Прошу прощения у модераторов за то, что тема так разрослась - с пользой для общего дела...
Предлагаю переименовать в "Возможности разработки взаимодействия с БД (выбор инструментов)"
Изменено:
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
|
|
|
14.07.2019 11:49:26
- понравился последний ответ по линку
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
|
||||
|
|
|||