Где на ваш взгляд лучше помещать документирующие код программы блоки комментариев doxygen, в коде реализации или в заголовочном файле в объявлении?
man mblen:
If s is not a NULL pointer, the mblen() function inspects at most n bytes of the multibyte string starting at s and extracts the next complete multibyte character. It uses a static anonymous shift state known only to the mblen() function. If the multibyte character is not the null wide character, it returns the number of bytes that were consumed from s. If the multibyte character is the null wide character, it returns 0.
И т.д.
Не пойму никак, что такое null wide character?
man strtol:
#include <stdlib.h>
If an underflow occurs, strtol() returns LONG_MIN
#include <stdlib.h>
wprintf(L"LONG_MIN: %u\n", LONG_MIN);
Результат:
error: 'LONG_MIN' undeclared (first use in this function)
wtf?
В общем и весь вопрос.
Во время запуска приложения codeblocks каждый раз перед отображением главного окна вылазит диалог Compilers auto-detection. Компилятор по умолчанию уже давным давно выбран, но программе упорно не имется. Что не так, что сделать что бы программа запускалась без поиска?
#RTU.
Я ничего не понял.
Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно.
Мне то что с этим делать? Я могу только байты в порт отправлять.
Как в макросах переносимо определить порядок байт в слове на машине?
Поставил в kde темную цветовую схему, в итоге в ассистанте на темном фоне черный текст. Это можно как нибудь поменять для ассистанта?
Хочу открыть псевдотерминал и сконфигурировать его как последовательный порт (termios.h) что бы ПО написанное для работы с обыкновенным com-портом могло сработать через него. Например если хочу написать эмулятор удаленного устройства для этого ПО. Все что я сделал проверял через minocom, безуспешно. Вот вкратце что я делал:
fdm = posix_openpt(O_RDWR | O_NOCTTY);
configTerm(fdm);
grantpt(fdm);
unlockpt(fdm);
int configTerm(int fd)
{
struct termios attrs;
tcgetattr(fd, &attrs);
cfsetospeed(&attrs, B115200);
cfsetispeed(&attrs, B0);
attrs.c_cflag |= (CLOCAL | CREAD);
attrs.c_cflag &= ~( CSIZE | PARENB | CSTOPB );
attrs.c_cflag |= CS8;
attrs.c_lflag &= ~( ICANON | ISIG | ECHO | ECHOE );
attrs.c_iflag &= ~( INPCK | IGNPAR | PARMRK | ISTRIP );
attrs.c_oflag &= ~OPOST;
tcsetattr(fd, TCSANOW, &attrs) ) {
return 0;
}
man select(2):
int pselect(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, const struct timespec *timeout, const sigset_t *sigmask);
Никак не могу понять параметр nfds. Подскажите пожалуйста:
1. Чем заполняется.
2. Зачем это нужно.
Судя по имени предположил что это число дескрипторов (nfds - Number of File DescriptorS), но в руководстве вообще что-то странное написано...
Подсоветуйте домашний маршрутизатор чтоб без перебоев работал с вафлей не меньше 300МБит и более одного порта rj45. В пределах 3000р. Если знаете где в москве можно сразу купить то такая информация приветствуется. Спасибо.
В таблице есть синтетический ключ уникальный для каждой строки, еще в таблице есть три поля которые составляют уникальную комбинацию - натуральный ключ. Два из трех полей натурального ключа это год и месяц и взаимодействие в 99.9999% происходит со строками за текущий месяц, а предыдущие уходят в прошлое, но остаются в этой таблице для «истории». Мне кажется что для целей быстродействия было бы целесообразным сделать первичным ключом натуральный ключ (три поля) что бы кластерное расположение строк нейтрализовало расходы на поиск строк за текущий месяц среди гигантского множества всех строк включая старые за прошедшие месяцы (так ли?). Но. В свою очередь тройной ключ накладывает свои расходы на быстродействие т.к. 1) увеличивается трафик и 2) клиентское ПО должно хранить весь тройной ключ в памяти и каждая GUI таблица должна содержать невидимые колонки с этим большим ключом, это не удобно программировать, но именно первичный ключ необходим для возможности позиционированного обновления (positioned update) т.е. обновления через рекордсет. Господа опытные администраторы БД, взываю к вашему опыту и прошу подсказать какой из этих ключей больше подойдет под первичный, синтетический в одно поле, или составной в три поля. И еще, действительно ли кластеризация по месяцам ускорит поиск по сравнению с кластеризацией по синтетическому AUTO_INCREMENT ключу?
Есть у меня таблица (MySQL) в которой помимо прочего есть поле уникально идентифицирующее запись, назовем его rowID, и есть три поля индексированные составным индексом - год, месяц и внешний ключ. Можно ли сделать так что-бы rowID был первичным ключом таблицы, но кластеризованным был составной индекс тех трех полей, и если да то как?
В таблице есть два поля. Первое содержит группу второго, второе содержит группу всех остальных полей. Например:
SELECT ... ORDER BY А, Б;
______________
| А | Б | Остальные
_____________
| 1 | 1 | ...
| 1 | 1 | ...
| 1 | 2 | ...
| 1 | 2 | ...
| 1 | 3 | ...
| 1 | 3 | ...
| 2 | 1 | ...
| 2 | 1 | ...
| 2 | 2 | ...
| 2 | 3 | ...
| 3 | 1 | ...
| 3 | 1 | ...
Вопрос, какой индекс лучше выбрать, составной по (А,Б) или отдельный для каждого поля?
ПС. если имеет значение, бд mysql.
Что за NATIONAL CHARACTER, на кой оно сдалось в СУБД с настраиваемыми кодировками более чем везде?
Изучаю MySQL, так что в нем я нуб.
В документации к MySQL 5.7 (5.7.12) написано следующее:
14.2.2.7 Locks Set by Different SQL Statements in InnoDB
...
LOCK TABLES sets table locks, but it is the higher MySQL layer above the InnoDB layer that sets these locks. InnoDB is aware of table locks if innodb_table_locks = 1 (the default) and autocommit = 0, and the MySQL layer above InnoDB knows about row-level locks.
Otherwise, InnoDB's automatic deadlock detection cannot detect deadlocks where such table locks are involved. Also, because in this case the higher MySQL layer does not know about row-level locks, it is possible to get a table lock on a table where another session currently has row-level locks.
Из выше сказанного, как я понял, следует что если innodb_table_locks = 1 и autocommit = 0 то только тогда блокировки InnoDB уровня строки и блокировки установленные оператором LOCK TABLES видят друг друга, и иначе не видят и лезут друг на друга.
Но в действительности у меня в (MySQL 5.7.10) выходит не так, все способы блокировки «учитывают» друг друга. Так при autocommit=1 с таблицей блокированно оператором LOCK TABLES сессия все равно замирает при попытке SELECT ... FOR UPDATE, и на оборот. Кроме того такое же точно поведение наблюдается даже при innodb_table_locks = 0.
Например:
Сессия1:
> LOCK TABLES tabtest READ;
Сессия2:
> START TRANSACTION;
> SELECT * FROM tabtest FOR UPDATE;
ждет...
Сессия1:
> LOCK TABLES tabtest WRITE;
Сессия2:
> START TRANSACTION;
> SELECT * FROM tabtest LOCK IN SHARE MODE;
ждет...
Сессия1:
> START TRANSACTION;
> SELECT * FROM tabtest LOCK IN SHARE MODE;
Сессия2:
> LOCK TABLES tabtest WRITE;
ждет...
Почему такое несоответствие написанному в доках, или я чего-то неправильно понял?
От чего score в учетке на лоре может снизиться? Вчера/позавчера был на единицу больше, а в уведомлениях никаких ни минусов ни удалений за это время.
Объяснрте, почему компилятор ругается на
Cls1 obj1;
set( obj1.get() ) ;QString tmp = obj1.get();
set(tmp);QString Cls1::get() const;
bool Cls2::set(QString& str);А?
Так то.
П.С. Android Opera Mini.
| ← назад | следующие → |