Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
Страниц: 1 2 3 [4] 5 6 7 ... 10
 31 
 : 18-10-2017 20:47 
Автор oktonion - Последний ответ от oktonion
В общем получилось вот так (вдруг кому-то пригодится):
https://github.com/oktonion/PhWidgets-lib/blob/b7eaa6edb3e12c622214cec760af693591cd5b61/src/service/bitmask.hpp

Возможно что то упустил конечно, но работает так как нужно.
А если определить еще свободные операторы для enum:

Код: (C++)
cppbitmasks::bitmask<MaskT, FlagT> operator|(const FlagT &flag1, const FlagT &flag2);
cppbitmasks::bitmask<MaskT, FlagT> operator&(const FlagT &flag1, const FlagT &flag2);
cppbitmasks::bitmask<MaskT, FlagT> operator^(const FlagT &flag1, const FlagT &flag2);

то и "слевые" выражения работать будут =)

 32 
 : 18-10-2017 15:58 
Автор geser111 - Последний ответ от geser111
После небольшого тестирования понял, что Windows будет увеличивать количество кадров в зависимости от мощности компа. Так что он даже учетверит, если тормозов не будет.

У меня спрашивали - зачем ставить кодек пак. Вот теперь даю более точный ответ:
Когда я смотрю запись avi 720x400, то количество кадров не спасает. Если запустить самый быстрый и наименее качественный режим, то количество кадров будет на вид - около 200-300. Но цветов будет мало. А если взять самый медленный и качественный режим, то количество кадров будет 100, зато цвета будут зашкаливать. А значит если у Вас топовая видеокарта, то вполне вероятно что Вы почти всегда будете использовать более качественный режим, потому что кадров будет достаточно много, а предел кадров всегда будет ограничивать монитор. Так что в моей борьбе с финальным MPC-HC я занял свое почетное место: Лучшее (Geser Codec Pack 3D) - враг хорошему (MPC-HC).

 33 
 : 18-10-2017 15:52 
Автор ann_nef - Последний ответ от Джон
А можно чуть по-подробней
 - что за зверь такой DataTimePicker?
 - почему "используется многобайтовая кодировка"?
 - и, если работает с UNICODE и есть такая возможность, то почему так не оставить?

 34 
 : 18-10-2017 15:33 
Автор geser111 - Последний ответ от geser111
Хочу всех обрадовать. Windows как впрочем и телевизор увеличили через деинтерлейсинг вдвое больше кадров для любого видео, в том числе и игр. А значит мои плееры будут показывать в 4 раза больше кадров в секунду. А это 96 кадров для 24 исходных и 120 для 30. А если у Вас 60 кадров - то будет 240 кадров в секунду.

 35 
 : 18-10-2017 13:32 
Автор oktonion - Последний ответ от oktonion
Как вариант. Но хочется чтобы ругался. В итоге все же пишу свое. Для побитого или к примеру:
Код: (C++)
namespace cppbitmasks
{
        template<class MaskT, class FlagT>
        class bitmask
        {
        public:
                bitmask() :
                        _val(MaskT())
                {
                }

                bitmask(const FlagT &flag) :
                        _val(flag)
                {
                }

                bitmask(const bitmask &other) :
                        _val(other._val)
                {
                }

                inline bitmask& set(const FlagT &flag)
                {
                        _val |= flag;
                        return *this;
                }

                inline bitmask& set(const bitmask &mask)
                {
                        _val |= mask._val;
                        return *this;
                }

                inline bitmask& operator|(const bitmask<MaskT, FlagT> &flag2)
                {
                        return set(flag2);
                }

                inline bitmask& operator|(const FlagT &flag2)
                {
                        return set(flag2);
                }

                bitmask& operator=(const bitmask &other)
                {
                        _val = other._val;
                        return *this;
                }

        private:
                MaskT _val;
        };

        template<class MaskT, class FlagT>
        inline bitmask<MaskT, FlagT>  &operator|(const FlagT &flag1, bitmask<MaskT, FlagT> &flag2)
        {
                return flag2 | flag1;
        }
}

Использование:

Код: (C++)
using namespace cppbitmasks;

enum eFlags
{
        flag1 = 0x00,
        flag2 = 0x01,
        flag3 = 0x02,
};

enum eFlags2
{
        flag4 = 0x04,
        flag5 = 0x08,
};

//определяем оператор для самого enum
bitmask<int, eFlags>  operator|(const eFlags &flag1, const eFlags &flag2)
{
        bitmask<int, eFlags> bm(flag1);
        return bm | flag2;
}

int main()
{
        bitmask<int, eFlags>  bm;

        flag3 | flag3; // ok, в bitmask преобразуется
        flag3 | bm; // ok, в bitmask преобразуется
        bm = flag3 | flag3; // ok
        bm = bm | flag3 | bm | flag2; // ok
        a.set(flag3 | flag2); // ok

        bm = flag3 | flag4; // ошибка компиляции
        a = a | flag3 | a | flag4; // ошибка компиляции
        a.set(flag3 | flag4); // ошибка компиляции

        return 0;
}

Пока что глупость написана в плане того что оператор изменяет значение, но направление гдето такое

 36 
 : 18-10-2017 11:19 
Автор Aether - Последний ответ от darkelf
А можно ещё поинтересоваться: стоит ли для ускорения вычислений создавать количество потоков кратное или равное количеству ядер?
Есть такой подход. В принципе надо создавать столько потоков, сколько надо. Для обеспечения максимальной производительности, например в вычислениях, хорошим вариантом может быть и число потоков равное числу ядер.

И новые потоки делят квант процесса или могут образовывать собственные, независимые от процесса, кванты? Иными словами, создавая множество потоков, можно создать ситуацию, когда они начнут "вытеснять" другие процессы, вызывая общее торможение системы, или нет?
Обычно, объектом диспетчеризации ядра ОС являются не процессы, а потоки. Точнее, когда не было многопоточных программ было соответствие поток=процесс. Сейчас это не так. Сейчас процесс - это хранилище ресурсов - распределённая память, открытые файлы и т.д - т.е. как-бы пассивная сущность. А поток (активная сущность) это контекст выполнения, у которого, собственно, кроме состояния регистров и стека ничего и нет. В соответствии с этим все потоки всех программ участвуют в диспетчеризации и программа на каком-нибудь четырёх ядерном процессоре, запустив 4 потока может забрать все ресурсы компьютера. С этим тоже есть возможность бороться - например в том-же unix-е есть setrlimit(), при помощи которого можно контролировать совсем уж слетевшие с катушек процессы. Более мягко это, имхо, разруливается на уровне назначения приоритетов потокам (см. например sched_setscheduller() и прочие функции с префиксом sched_*) - т.е. если эта работа какая-нибудь не сильно важная, но объёмная - можно запустить поток/процесс с пониженным приоритетом.  Если есть важная работа - выполняется она, если нет - ядро ОС ставит на выполнение этот процесс/поток.

 37 
 : 18-10-2017 10:57 
Автор Aether - Последний ответ от Aether
Да, согласен, резервирование впрок может помочь.

А можно ещё поинтересоваться: стоит ли для ускорения вычислений создавать количество потоков кратное или равное количеству ядер? И новые потоки делят квант процесса или могут образовывать собственные, независимые от процесса, кванты? Иными словами, создавая множество потоков, можно создать ситуацию, когда они начнут "вытеснять" другие процессы, вызывая общее торможение системы, или нет?

 38 
 : 18-10-2017 09:49 
Автор Aether - Последний ответ от darkelf
а что мешает при вызове функций менеджера памяти захватывать/освобождать мутекс? Я имею в виду не снаружи, а внутри функции malloc()/realloc()/free().
Тоже самое в итоге получится. Поток будет ждать своей очереди, но есть нюансы в плюсах и минусах.
В общем случае - да, но могут быть варианты. Например, во внутреннем менеджере памяти для каждого потока выделять определённый объём, гораздо больший, чем запрашивают на данный момент, а потом из этой области распределять под мелкие выделения. Тогда, пока есть свободное место в этой области, блокировки не потребуются, они будут необходимы, когда данный объём исчерпается, и будет необходимо выделить новую область. Т.е. получится как-бы внутренняя персональная для каждого потока "куча".

 39 
 : 18-10-2017 09:23 
Автор Aether - Последний ответ от Aether
а что мешает при вызове функций менеджера памяти захватывать/освобождать мутекс? Я имею в виду не снаружи, а внутри функции malloc()/realloc()/free().
Тоже самое в итоге получится. Поток будет ждать своей очереди, но есть нюансы в плюсах и минусах.

Сравнительно недавно, для упрощения построения многопоточных программ, придумали ещё такую вещь, как транзакционную память, которая может быть реализована как чисто программно, в компиляторе и/или библиотеке, так и с определённой аппаратной поддержкой на уровне процессора.
Это незнакомый зверь. Как понял, суть в предоставлении буфера для каждого потока, в который можно писать не ожидая разрешения на запись, а читать, стало быть, можно только оттуда, где актуально. Возможно, в каких-то отдельных задачах этот подход оправдан.

 40 
 : 18-10-2017 09:17 
Автор ann_nef - Последний ответ от darkelf
ann_nef, к сожалению не пользовался ни этим компонентом, ни  Visual Studio с++ 2010, ни даже Windows 10, но беглый просмотр документации, говорит, что там есть свойство CustomFormat, в котором можно указать необходимый формат отображения даты/времени, например, в Вашем случае, можно попробовать сказать "HH:mm:ss";

Страниц: 1 2 3 [4] 5 6 7 ... 10
Powered by SMF 1.1.21 | SMF © 2015, Simple Machines