Ычан: [d | au / b / bro / hr / l / m / mi / mu / o / r / s / sci / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 25965)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5000 кБ.
  • Ныне 3748 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
junior_developer_nene.png - (648.30KB, 720×720)
25965
No. 25965  
Здесь можно получить помощь и консультацию по любому языку программирования, в любой сфере разработки. Не важно, программируете ли вы собственного робота, пишете серверную приблуду, интегрируете чужие API, ковыряете игру, или пытаетесь сделать сайт на Wordpress - если аноним что-то об этом знает, он обязательно поможет.

Пополняемая база знаний: http://pastebin.com/AGhLZppH

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

Другие тематические нити (иногда обновляется): https://pastebin.com/psy43ibG

Примеры кода лучше выкладывать в виде ссылок на http://pastebin.com или http://ideone.com
Фронтендные вещи лучше выкладывать на http://jsfiddle.net

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

Чтобы не сбивать новичков с толку, а также не разбавлять полезную информацию мусором, беспредметные споры типа "какой язык / парадигма / библиотека / етц лучше" здесь запрещены. Для подобных вещей теперь есть отдельная диспутов нить >>/dev/21353

Если здесь поселится достаточное количество программистов на одном языке / одной сферы, можно будет их выделить в отдельную нить, а в этой оставить на неё ссылку.
По мере поступления вопросов можно составлять FAQ и базу знаний.

Архив нитей:
http://410chan.org/dev/arch/res/14160.html
http://410chan.org/dev/arch/res/15681.html
http://410chan.org/dev/arch/res/17424.html
http://410chan.org/dev/arch/res/19666.html
http://410chan.org/dev/arch/res/21641.html
http://410chan.org/dev/arch/res/23830.html

Прошлая нить пока тонет тут: >>/dev/23830
235 сообщений пропущено. Показаны 50 последних сообщений
No. 26807  
>>26791
Семафоры могут меж абсолютно левыми процессами работать, их ещё в System V придумали.
No. 26808  
2012-04-20-linus-torvalds.webp - (28.64KB, 984×997)
26808
>>26789
https://yarchive.net/comp/linux/semaphores.html
キタ━━━(゚∀゚)━━━!!
No. 26811  
1515915234434.jpg - (53.55KB, 508×494)
26811
Sup, /dev/. Пишу на Ruby с использованием библиотеки RMAgick (https://rmagick.github.io/) небольшой скриптик для обработки изображений. Собственно, весь скрипт представляет собой загрузку изображения из файла, его обработку через последовательный вызов методов RMAgick и сохранение полученного результата в новый файл.

Проблема в том, что почти все методы в RMagick возвращают не self, а новый объект. Лично для меня это жутко неудобно, т.к. я хочу писать так:

#
# тут читаем изображение из файла в объект img
# обрабатываем изображение:
img.
   method_1!
   method_2!
   #…
   method_n!
   write('result.png')


Но вместо этого приходится делать так:
img = img.method_1

img = img.method_2
#…
img = img.method_n
img.write('result.png')


Т.е. постоянно переопределять объект img. Что некрасиво (бесит). Хуже того, что некоторые методы таки имеют аналоги, возвращающие self, но в итоге код вообще выглядит жутко некрасиво, потому что часть методов с восклицательными знаками, часть без:

img = img.method_1

img.method_2!
img.method_3!
img = img.method_4
#…
img = img.method_n
img.write('result.png')


Я примерно могу понять, зачем это сделано, но у меня нет необходимости хранить где-либо промежуточные этапы конвертации.

Собственно, вопрос: возможно ли как-то заставить методы RMagick возвращать мне всегда self, а не новый объект? Как-то переопределить их и т.п.?
No. 26812  
>>26811
>Собственно, вопрос: возможно ли как-то заставить методы RMagick возвращать мне всегда self, а не новый объект? Как-то переопределить их и т.п.?
С точки зрения ООП - возможно, и ничего не мешает.
Самый простой способ - сделать класс-обертку над RMagick, он же "декоратор", который обернет тебе нужные методы RMagick так, чтобы возвращать всегда оригинальный объект (в твоем случае img)

Пример как это делается: https://www.rubyguides.com/2018/04/decorator-pattern-in-ruby/
No. 26813  
Си
Почему вот такая конструкция при вводе некорректного аргумента в scanf, например буквы, уходит в бесконечный цикл?

while(scanf("%d", &str_len) == 0)
{
puts("Некорректный ввод. Введите длину еще раз");
}
No. 26814  
>>26813
https://en.cppreference.com/w/c/io/scanf
>Return value
>Number of receiving arguments successfully assigned
>(which may be zero in case a matching failure occurred before the first receiving argument was assigned)
У тебя не заассайнился единственный аргумент, поэтому оно возвращает 0, поэтому уходит в цикл.
No. 26816  
1523019999300.png - (125.53KB, 880×960)
26816
>>26812
Спасибо за ответ! Мне товарищ тоже рассказывал про делигаторы полтора месяца назад, я тогда попробовал через СимплДимпл SimpleDelegator сделать, но у меня ничего не получилось.

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

В любом случае, спасибо за совет!
No. 26817  
>>26816
Надеюсь решение подойдет и все получится, заходи если что.
No. 26823  
16428684542002.jpg - (669.37KB, 1300×1600)
26823
Кто-нибудь хочет вместе вкатыватсья в программирование? Сам хорошо знаю Python, сейчас учу C# и C++, так же немного ковыряюсь в линуксе. В принципе ваш стек не так важен, главное чтобы была взаимная мотивация для вката. Ну или просто общение на около айтишные темы, очень не хватает общения с людьми из этой сферы...

Пишите в дс, потом в телегу если что можно: wh1te#6615

Всем добра
No. 26824  
>>26817
Спасибо за напутствие! Пока, как обычно это бывает в процессе работы, придумались новые фичи и выявились более приоритетные задачи. Операции над картинкой пока оставил с костылями, это low-priority task на текущий момент. Но позже к нему вернусь.
No. 26825  
good-menhera.gif - (147.77KB, 278×283)
26825
>>26824
No. 26833  
>>26823
Это что за айди такое?
No. 26845  
163490563547.jpg - (245.09KB, 1440×810)
26845
>>26823
> Сам хорошо знаю Python
Так ты уже вкатился, если ХОРОШО знаешь Python.
No. 26846  
Он ответил мне. Мы съехались и собираемся уехать в казахстан, открыть там студию по производству порноквестов про свиноорков и эльфов.
No. 26847  
captcha.png - (9.71KB, 90×50)
26847
>>26846
Ну и вкусы у вас.
No. 26851  
>>26833
Дискордовское
No. 26852  
>>26851
У меняего нет. Слишком молодежный. В нем Белуга чатится.
No. 26853  
>>26852
Это кто?
No. 26855  
>>26853
https://www.youtube.com/channel/UCmSp4bDxS9R0jpeZEvkut2g
No. 26859  
Так написал кто-нибудь?
No. 26864  
nene.png - (945.51KB, 3444×3444)
26864
>>26862
>>26863
Не смотря на низкую активность нити, не нужно устраивать здесь личный чат.
No. 26877  
>>26864
100 сообщений и переносить уже!
No. 26892  
164170946852.jpg - (968.52KB, 2000×1432)
26892
С новым годом в этом году никто не поздравлял... Перечитал все нити, очень классно и весело, спасибо всем тем кто поддерживал это, особенно Куратору и Джависту Фосфилит, очень увлекательно было с ним DOM деревья обходить! Надеюсь это всё не умрет совсем.
No. 26893  
nene.png - (790.99KB, 720×720)
26893
>>26892
Будем надеяться. Спасибо на добром слове.
В этом году настроения поздравлять не было от слова совсем.
No. 26897  
Чиочан, расскажи про исключения в конструкторе и деструкторе в плюсах. Чем чревато, стоит ли использовать?
No. 26898  
>>26897
Не спец по плюсам, но думаю, если ты кидаешь исключение в деструкторе до того, как освобождаешь все ресурсы, возможны утечки памяти.
No. 26903  
>>26897
Хорошее ЧаВО по теме исключений в плюсах:
https://isocpp.org/wiki/faq/exceptions

>Исключения в конструкторе
>стоит ли использовать?
Официально рекомендуют использовать для зафейлившихся конструкторов:
https://isocpp.org/wiki/faq/exceptions#ctors-can-throw
>Constructors don’t have a return type, so it’s not possible to use return codes. The best way to signal constructor failure is therefore to throw an exception.
>чем чревато?
Не вызовется деструктор, т.к. он не вызывается для объектов которые нормально не инициализировались, а это потенциально ведет к утечке памяти. Нужно не забыть все сделать правильно, и заранее почистить самому что там нужно почистить. Альтернатива - иметь легкий конструктор, а все тяжелое размещать в init-методе, откуда и кидаться исключениями. Формально объект будет инициализован и деструктор вызовется. Также нужно не забыть организовать все так, чтобы твое исключение поймал и обработал хотя бы main().

>Исключения в деструкторе
>стоит ли использовать?
Официально просят никогда так не делать:
https://isocpp.org/wiki/faq/exceptions#dtors-shouldnt-throw
>Write a message to a log-file. Terminate the process. Or call Aunt Tilda. But do not throw an exception!
>чем чревато?
Прибитием твоего процесса сразу:
>since C++11 destructors are implicitly noexcept
Или, если ты указал noexcept(false) - прибитием твоего процесса в случае, когда исключение не обрабатывается тут же, в самом деструкторе, и вылетает в неудачный для процесса момент, например во время размотки стека при обработке другого исключения. Также >>26898 верно указывает, что преждевременная эвакуация из деструктора у мужчин потенциально ведет к утечке памяти.

Дополнительно, для приложений реального времени с жесткими гарантиями отклика, пользоваться исключениями не рекомендуется в принципе.
No. 26904  
>>26903
> т.к. он не вызывается для объектов которые нормально не инициализировались
А кто за этим следит? Компилятор добавляет в класс пометку, что он не инициализирован, которая проверяется по выходу и скоупа?
No. 26905  
>>26904
На концептуальном уровне - если конструктор не завершился, то объект не создался, а если объект не создался, то и деструктора у него нет - вызывать не у кого и нечего.

Вот небольшая статья по этому поводу:
http://www.gotw.ca/publications/mill13.htm
>(a) The constructor returns normally by reaching its end or a return statement, and the object exists.
>(b) The constructor exits by emitting an exception, and the object not only does not now exist, but never existed as an object.

>А кто за этим следит?
За этим следит среда исполнения (рантайм).

>Компилятор добавляет в класс пометку?
Чтобы ответить на вопрос как это устроено технически, нужно нырнуть в код компилятора и код среды исполнения, а я к своему стыду не нырял. Не хочу спекулировать. Может тут кто-то нырял и знает?
No. 26906  
Понятно, спасибо.
No. 26909  
>>26906
Заходи если что, и рассказывай если выяснишь подробности.
No. 26912  
Чиочан, встретил в продуктовом коде вот такую штуку

#define X( a, b ) b,
static const char* mas_name[] = { "some_string" };
#undef X
Никто не помнит, что это, откуда взялось и что делает.
Есть идеи, что это за пляски с дефайнами?
No. 26916  
>>26912
>что это за пляски с дефайнами
Это препроцессорный макрос:
https://cplusplus.com/doc/tutorial/preprocessor/
>When the preprocessor encounters this directive, it replaces any occurrence of identifier in the rest of the code by replacement. This replacement can be an expression, a statement, a block or simply anything.
>The preprocessor does not understand C++ proper, it simply replaces any occurrence of identifier by replacement.
>The preprocessor examines the code before actual compilation of code begins and resolves all these directives before any code is actually generated by regular statements.

В твоем случае объявлен макрос, который будет менять в строчке с объявлением массива mas_name все пары аргументов заключенные в X со скобками, типа
>X(arg1, arg2)
на второй аргумент из пары, причем вот прямо с запятой в конце:
>arg2,

Например
#define X( a, b ) b,

static const char* mas_name[] = { X("Rei", "Hino") X("Rei", "Ayanami") };
#undef X

Превратится в
static const char* mas_name[] = { "Hino", "Ayanami", };

Скорее всего в каких-то таких целях макрос и использовался.
Просто предварительная обработка данных, которую проще было сделать еще до компиляции, и не тратить на нее время при исполнении.
No. 26919  
>>26916
Понятно, спасибо.

Такой еще вопрос. Зачем вкладывать анонимный неймспейс в не анонимный?

namespace name1 {
namespace {

// something something

}
}
No. 26920  
>>26919
Для того чтобы дополнительно ограничить видимость содержимого анонимного неймспейса тем файлом, в котором он объявлен:
https://www.learncpp.com/cpp-tutorial/unnamed-and-inline-namespaces/
>The content of an unnamed namespace can’t be seen outside of the file in which the unnamed namespace is defined.
Т.е. мало того что ты скрываешь что-то в именном неймспейсе, ты еще дополнительно скрываешь вещи от других файлов в этом же именном неймспейсе.
No. 26921  
>>26919
Чаще всего это встречается у имплементаций абстрактных классов. В хедере ты объявляешь порождающий метод/функцию, возвращающий указатель на интерфейс, а конкретную реализацию интерфейса скрываешь от пользователя.
No. 26923  
>>26920
А разве анонимный неймспейс и так не ограничен своим файлом?
No. 26924  
>>26923
Да, все верно, я просто плохо выразился. Речь про то что заключением в анонимный неймспейс дополнительно ограничивают видимость текущим файлом для куска содержимого именного неймспейса, например так как иллюстрирует >>26921
No. 26926  
super_hash.png - (304.56KB, 500×282)
26926
Решил написать многопоточный парсер на питоне воспользовавшись модулем threading но столкнулся с довольно очевидной проблемой. Разные потоки очевидно выполняют ту же самую работу, последовательно проходя по ссылкам в моем случае, и в частности пишут в бд одно и то же, создавая одинаковые записи. Конечно это можно некоторым образом обойти сделав лишний запрос к бд и проверив содержимое поля но мне кажется что алгоритмически это как-то не сильно хорошо. К тому же совершается лишний http запрос. Можно ли теоретически как-то это обойти? Заранее спасибо.
No. 26927  
>>26926
Складывать ссылки в одну общую очередь, а уже затем разбирать их через несколько потоков?

Кстати, threading - это не настоящая многопоточность а херня, потому что питоновский GIL все равно выполняет все потоки по очереди в одном процессе.

> If you want your application to make better use of the computational resources of multi-core machines, you are advised to use multiprocessing or concurrent.futures.ProcessPoolExecutor. However, threading is still an appropriate model if you want to run multiple I/O-bound tasks simultaneously.

Используй multiprocessing, и лучше с пулом - не уверен, сильно ли это заметно в питоне, но переиспользование процессов в общем случае уменьшает число системных вызовов и нагрузку.
No. 26928  
>>26927
Еще один вариант - выбирать поток для обработки ссылки в зависимости от ее хеша, например четные хеши отправлять в один поток пула, нечетные в другой. Это не застрахует от повторной обработки ссылки одним и тем же потоком (если они у тебя повторяются), но гарантирует, что разные потоки всегда работают с разными ссылками.
No. 26929  
>>26927
Спасибо, я разобрался что у меня неверно в принципе была реализована многопоточность. Без предварительного помещения ссылок в некую структуру и их последующего разбора разными тредами/процессами в принципе никак не обойтись. Но у меня проблема была даже не в этом. Я попытался сделать некий кэш который хранил бы уже посещенные страницы с целью быстрого рестарта парсера в случае обрыва или другого некорректного завершения работы. И этот кэш хранился в таблице SQLite. Меня крайне удивил тот факт что каждый отдельный тред видит только то что он записал в эту таблицу сам, что естественно и привело к многократному повторению записи кэшируемых страниц. Оказалось что это вполне штатное поведение этой БД, не поддерживающей одновременный доступ разных потоков в принципе(можно костыльно как-то это решить, но лучше не стоит как я понял).

>Кстати, threading - это не настоящая многопоточность

Уже уперся в это. Все это замышлялось в основном для распараллеливания затратной работы с изображениями и естественно GIL намертво блокировал треды и ставил в очередь видимо.

>Еще один вариант - выбирать поток для обработки ссылки в зависимости от ее хеша

В два потока т.е. разбирать?
No. 26931  
>>26929
> В два потока т.е. разбирать?
Ну или находить остаток от деления хеша на какое-то большее число и распеределять на это же число потоков. Не уверен будет ли подобное достаточно эффективно на практике, но сама по себе идея очень нравится

Да, если хочешь быстродействия, то по возможности старайся использовать нативные библиотеки - к примеру numpy вместо ручной итерации по массивам. Для питона это основной способ оптимизации.
No. 26932  
>>26931
> к примеру numpy вместо ручной итерации по массивам

А разве "ручная итерация по массивам" не супероптимизирована в питоне? У NumPy есть какой-то выигрыш?
No. 26934  
>>26932
Нет, с оптимизизацией там грустно, циклы for-in всегда медленные, поэтому по возможности рекомендуется использовать встроенные функции навроде map или же генераторы списков (хотя они тоже так себе). NumPy предназначен специально для массивов со статической типизацией, и по ощущениям быстрее в разы, если не десятки раз.
No. 26935  
А что за тип такой - const char const ?
No. 26938  
>>26935
Вероятно, у вас звездочки потерялись в разметке, и на самом деле это const char ★ const ★?

Если const идет после звездочки (char ★ const), значит const относится к звездочке, и это константный указатель на неконстантный тип - мы можем изменить символ по адресу, на который он указывает, но не сможем изменить само значение указателя.
char * const p = ...;

*p = 'a'; // сработает
p += 1; // ошибка компиляции


Если const идет до зездочки (char const ★ или же const char ★, они эквиваленты, и хотя первая запись выглядит логичнее, вторая почему-то чаще используется), значит const - это про char, и мы имеем изменяемый указатель на неизменяемый символ - мы сможем присвоить указателю другое значение, но не сможем поменять символ на который он указывает.
char const * p = ...; // равносильно const char * p = ...;

*p = 'a'; // ошибка компиляции
p += 1; // сработает


Здесь у тебя мы видим неконстантный указатель на константный указатель на константный символ. Я практически уверен, что твои указатели обозначают начало массива, и здесь мы видим указатель на массив константных указателей на строку.
No. 26940  
>>26938
Вообще, существует даже переводчик с сишных типов на человеческий: https://cdecl.org/
No. 26941  
>>26938
>>26940
Понятно, спасибо.
No. 26947  
>>26941
Заходи, если что
Удалить сообщение []
Пароль  
[Mod]