HLFX.Ru Forum - нубовопросы по c++

Страницы (3): « 1 [2] 3 »
Показать все 123 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Технические вопросы (https://hlfx.ru/forum/forumdisplay.php?forumid=20)
-- нубовопросы по c++ (https://hlfx.ru/forum/showthread.php?threadid=5083)

Отправлено thambs 06-02-2019 в 16:10:

В 17м стандарте появилась спецконструкция constexpr if, значит ли это, что в обычном случае компилятор не оптимизирует оператор if от constexpr выражений?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 06-02-2019 в 16:16:

thambs
Компилятор всё оптимизирует. constexpr if, в отличие от обычного if, может выполняться компилятором.

__________________

Отправлено thambs 06-02-2019 в 16:46:

XaeroX
Я правильно понимаю, что оптимизация if производится в случае если на входе constexpr переменная, а constexpr if может работать чистой функцией от constexpr переменных?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 06-02-2019 в 17:56:

thambs
Да, правильно. Это всё нужно по большому счёту для шаблонного программирования.

__________________

Отправлено thambs 06-02-2019 в 18:03:

XaeroX т.е. при компиляции конструкции

code:template<int a> void foo(){
	if constexpr (a>1) do_stuff();
};

code:template<int a> void bar(){
	constexpr bool tmp = a>1;
	if (tmp) do_stuff();
};

эквивалентны и условный переход исчезнет для любого инстанса?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 06-02-2019 в 18:48:

thambs
Насколько я знаю, if constexpr ведёт себя идентично if в обычных функциях.
Разница возникает в constexpr-функциях. Такие функции не скомпилируются с обычным if, потому что он гарантирует, что лишь одна из веток будет выполняться, а вот constexpr-if гарантирует, что лишь одна из веток будет компилироваться.
Ещё раз - это всё нужно в метапрограммировании, когда мы из-за отсутствия if constexpr в С++14 (интересно, многие ли уже на С++17 перешли?) городим этажерки с std::enable_if.

__________________

Отправлено Дядя Миша 06-02-2019 в 19:43:

А чо, если я в шестёрке напишу if( 1 ) она это не выкинет?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-02-2019 в 14:08:

мультидефайн в зависимости от параметра

Что-то так и не придумал как это сделать, лучше опишу что я хочу, а потом спрошу, можно-ли и как это сделать.

вообщем, хочется что-то вроде макроса, который в зависимости от параметра делает много дефайнов, и другого, который чистит за ним. Что-то вроде:

макрос def_args(n): делает

code:#define $a foo<n>
#define $b bar<n>
...

и undef_args:

code:#undef $a
#undef $b

Можно-ли, и как?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 19-02-2019 в 14:59:

Вроде бы нельзя.

__________________

Отправлено thambs 10-03-2019 в 12:48:

Снова вопрос. Есть например функция от n-аргументов, можно ли её как-то вызвать использовав массив из n-аргументов, не прописывая их вручную? Т.е. хочется что-то вроде рекурсивного шаблона, каждый из которого добавляет ещё один аргумент к частичному применению функции:

code:foo(...);
int xs[n];
apply<xs,n>(foo);

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 10-03-2019 в 13:05:

Я не знаю способа так сделать. Если узнаешь - напиши.
Но вообще говоря, если ты хочешь передавать аргументы в функцию как массив, то и надо передавать массив, можно даже compile time (std::array).
Идея вариативных шаблонов в том, чтобы поддерживать произвольное число аргументов у функции, а у тебя число аргументов фиксированное.

__________________

Отправлено ~ X ~ 11-03-2019 в 09:20:

thambs here, I googled that for you https://embeddedartistry.com/blog/2...unctions-c-vs-c
может, там найдутся варианты.

Добавлено 11-03-2019 в 12:20:

https://stackoverflow.com/questions...c-function-in-c
в ответах нашлись вроде.

__________________
Минутка полезного:
Бесплатный UT-подобный Half-Life mod.
Бесплатный редактор для 32-битных текстур. Без дотнета.
Бесплатный IDE для любых компиляторов и ЯП.
Бесплатная Windows-подобная ОС.
Проверка грамматики русского языка.
Чат по hl[fx]: [email protected]

Отправлено XaeroX 11-03-2019 в 15:35:

~ X ~ стесняюсь спросить, а по каким именно ключевым словам ты гуглил? Вроде бы это вообще не по теме.

__________________

Отправлено ~ X ~ 11-03-2019 в 18:38:

Тебе зайцев не жалко? И постыдился, и спросил
А я, похоже, не понял его вопроса.

Отправлено Дядя Миша 14-03-2019 в 21:55:

Зачем битовые сдвиги оформляют в табличку? Неужели такой подход даёт хоть какой-то выигрыш в производительности? В качестве примера вальвовский bistream buffer.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 27-03-2019 в 21:58:

А вот поясните мне, что-то я совсем запутался с тем как c++ осуществляет неявное преобразование типов.

C++ Source Code:

1	#include <complex>

2	#include <cmath>

3	typedef std::complex<float> cfloat;

4	int main(int argc, char **argv){

5	int i,n; constexpr cfloat _coeff(0, (-4)*atan2(1,1));

6	cfloat x = exp(_coeff * cfloat(i)/cfloat(n)); //fine

7	cfloat y = exp(_coeff * i/cfloat(n)); //fail

  return 0;

Собственно, почему в этом выражении не происходит неявного приведения типов, в чём дело?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 27-03-2019 в 22:29:

Ну а слеш перегружен для такой пары типов?

Отправлено nemyax 21-08-2019 в 15:44:

Не знаю даже, с чего начать свой нубский вопрос. Столкнулся с порчей памяти, которую никак не могу отдебажить. Проявляется в FLTK-поделке при повторении операций undo-redo, реализованных через перезапись структов их сохранёнными состояниями (сейчас через приведение, но через мемкпю тоже делал, разницы нету). Поправил все невысвобождения, какие смог найти, проверил аллоцируемые размеры. В результате под линуксом уже не валится, но под вендой продолжает. Самое интересное, данные в слепках структов верные, и анду-реду даёт ожидаемые результаты. Но на какой-то по счёту тудымсюдым (причём это число воспроизводимое) память оказывается перепаханной.
Когда у вас, опытные товарищи, начинается чертовщина с порчей памяти, где кроме аллокации-высвобождения вы ищете её причины?

Отправлено XaeroX 21-08-2019 в 16:51:

nemyax
У нас кастомные аллокаторы с сентинелями.
Кажется, в CRT дебажный аллокатор тоже умеет проверять на предмет порчи, но я им не пользовался.
Проверь все массивы, нет ли выхода за границу.
Если порча у класс-мембера, проверь, нет ли перезаписи за пределы другого класс-мембера.
Попробуй комментировать memcpy и смотреть, пропадает ли баг.

Цитата:

nemyax писал:
причём это число воспроизводимое

Ну это вообще самый идеальный и лёгкий для дебага вариант.

__________________

Отправлено nemyax 21-08-2019 в 17:10:

Цитата:

XaeroX писал:
Проверь все массивы, нет ли выхода за границу.

Попроверяю ещё, конечно. Но кабут всё укладывается в выделенные размеры на куче. А если выясняется, что размер данных малый, то и вовсе обхожусь массивом на стеке без кучы.

Цитата:

XaeroX писал:
У нас кастомные аллокаторы с сентинелями.

Не на асме же вы их пишете. Небось оборачиваете стандартные средства под конкретную задачу.

Насколько вообще надёжно перетирать структы, хранящие указатели?

Отправлено XaeroX 21-08-2019 в 17:53:

Цитата:

nemyax писал:
Насколько вообще надёжно перетирать структы, хранящие указатели?

Ты бы код показал, что ли, а то сеанс телепатической связи отнимает очень много энергии.

__________________

Отправлено nemyax 21-08-2019 в 18:32:

Структы такого рода:

C++ Source Code:

1	struct umark

3	const int *ptr;

};

6	struct ulink

8	uvert *vert;

9	ulink *twin;

10	ulink *wrap;

11	uedge *edge;

12	ubend *bend;

13	umark *mark;

};

16	struct uvert

18	flags options;

19	union {float xyz[3]; vec3 coords;};

20	ulink *link;

21	uties *ties;

22	extra_info *extra;

  int misc;

};

26	struct uedge

28	flags options;

29	ulink *link;

30	uties *ties;

31	extra_info *extra;

  int misc;

};

35	struct uface

37	flags options;

38	usurf *material;

39	ubend *bend;

40	uties *ties;

41	extra_info *extra;

  int misc;

};

45	struct undo_chunk

  int type;

48	void *addr;

49	char state1[Undo_slot_size];

50	char state2[Undo_slot_size];

51	undo_chunk *smaller; // in terms of memory address

52	undo_chunk *greater; // in terms of memory address

};

55	struct backup

57	int count;

58	undo_chunk *root;

};

Перезапись состояний в таком духе:

C++ Source Code:

1	void history::change_state(undo_buffer b, void (fun)(undo_chunk*))

3	backup *bak = b->bak;

4	int count = bak->count;

5	if (bak->root == NULL) {return;}

6	undo_chunk **stack = NULL;

7	if (Is_small(count))

9	undo_chunk *s[Small_tree];

10	stack = (undo_chunk**)s;

12	else {stack = (undo_chunk*)malloc(sizeof(undo_chunk) * count);}

13	int pos = 0;

14	undo_chunk *ch = bak->root;

15	undo_chunk gr, sm;

16	stack[pos] = ch;

17	while (pos >= 0)

19	ch = stack[pos];

20	gr = ch->greater;

21	sm = ch->smaller;

22	if (gr != NULL) {stack[pos++] = gr;}

23	if (sm != NULL) {stack[pos++] = sm;}

        fun(ch);

      --pos;

27	if (!Is_small(count)) {free(stack);}

Отправлено XaeroX 21-08-2019 в 18:36:

Ух... кондовый такой си.
Ты указатели чтоли сохраняешь, а не сами данные? Оно так разве будет работать?

__________________

Отправлено nemyax 21-08-2019 в 18:42:

Вот я и говорю, под линуксом просто работает. Под вендой (компилятор vc9) тоже работает, но начинается наркомания после энного повторения.

Отправлено Дядя Миша 21-08-2019 в 18:58:

Цитата:

nemyax писал:
Когда у вас, опытные товарищи, начинается чертовщина с порчей памяти, где кроме аллокации-высвобождения вы ищете её причины?

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

Добавлено 21-08-2019 в 21:58:

Поглядел код. Если уж сохранять что-то с указателями, то логично кусок памяти выделять так чтобы в него попала структура + то что мы хотели сохранить. И тада уже можно с этим иметь дело. И не использовать явные указатели, а что-то типа (struct + 1). Ну это так, к слову.
Тут помойму проблема в самой задумке. Это вообще не будет нормально работать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-08-2019 в 19:07:

Хорошо, скажем иначе: где кроме ошибочных аллокации-освобождения?

Добавлено 21-08-2019 в 22:07:

Цитата:

Дядя Миша писал:
Это вообще не будет нормально работать

Почему? Что может заставить систему похерить выделенные данные с того места, где она их выделила?

Отправлено Дядя Миша 21-08-2019 в 19:42:

Систему - ничего. Ты сам там что-то херишь, но скорее всего просто не понимаешь этого. Это самый частый сценарий. Ты думаешь что всё в порядке, а сам что-то портишь. Я за все годы программирования один единственный раз столкнулся, когда мне система в штаны насрала - тот известный случай, когда в libc и msvcrt разная реализация atof. А всё остальное - это уже сам себе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-08-2019 в 19:48:

Цитата:

Дядя Миша писал:
Ты сам там что-то херишь, но скорее всего просто не понимаешь этого. Это самый частый сценарий.

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

Отправлено Дядя Миша 21-08-2019 в 19:58:

Во-во, я ж и говорю что ты не о том думаешь. У тебя там что-то с указателями, скорее всего. Память-то на старом месте, а вот на что указатели указывают, это другое дело.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-08-2019 в 20:18:

То, что я где-то написал фигню, не означает, что общая задумка работать не будет в принципе.
Меня плющит, что коллапс созревает постепенно к четвёртому-пятому анду-реду и только при использовании компилятора микрософта.

Отправлено Дядя Миша 21-08-2019 в 21:39:

Компилятор тут точно непричём. Значит где-то посадил UB. Накопительный баг. Надо там хотя бы алертов понтаыкать и посмотреть чо происходит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 26-08-2019 в 18:23:

Всё-таки нашёл одну течку. Заткнул, и порча снята.

Отправлено nemyax 23-09-2019 в 22:32:

Микрософт опубликовал свой STL под лицензией Apache: https://devblogs.microsoft.com/cppb...cing-msvcs-stl/

Добавлено 24-09-2019 в 01:32:

На ЛОРе профессионалы наорудовали, что там не только STL, но и либстдц++ как таковой. Не знаю, правда ли.

Отправлено Дядя Миша 24-09-2019 в 06:08:

STL это вообще удивительная вещь. Её сделал наш, а гордость почему-то никто не испытывает. Подозрительно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-09-2019 в 07:07:

Дядя Миша
Ну потому что он не совсем наш. Вернее, совсем не наш. Наш - это сам знаешь что, на букву К.

__________________

Отправлено thambs 15-10-2019 в 14:06:

Вот ещё вопрос возник про vardic templates.
Например, если мне нужна функция переменной арности от однотипных аргументов, то я могу записать

C++ Source Code:

1	template<typename ...ids>

2	void foo (const ids&... args){

3	for(auto& arg: {args...}){

4	/* do stuff with arg*/

А можно ли эту конструкцию как-то специализировать для конкретного нетривиального типа под многоточием? Например, я хочу передавать в функцию, пускай, tuple<int,char*,float> — можно-ли написать это в единой конструкции, без привлечения прокси-шаблонов?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-10-2019 в 14:17:

О! Шаблоны позволяют var args? Хотя в шестёрке небось не сработает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 30-11-2019 в 01:44:

А может кто ни будь пояснить, почему ptr не изменяется в результате?

C++ Source Code:

1	/* relink data <- ptr */

2	inline void relink

3	(void* ptr){

4	self.data = (t*)ptr;

5	ptr = self.data + self.offset[0];

6	printf("relink %p -> %p\n", self.data, ptr);

Вызывается, например:

C++ Source Code:

void* ptr = nullptr;

cmp.pparts.relink(ptr);

cmp.pindex.relink(ptr);

А в результате:

C++ Source Code:

relink (nil) -> 0x445c0000

relink (nil) -> 0x2d00

При этом, если возвращать изменённый указатель из функции, то он снаружи нормально присваивается безо всяких проблем. В чём тут дело?

Добавлено 30-11-2019 в 04:44:

ps: или я идиот, или одно из двух...

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 30-11-2019 в 01:51:

thambs
Потому что ты передаёшь указатель по значению, а не по указателю.
Функция должна иметь сигнатуру

C++ Source Code:

void relink(void **ptr)

со всеми вытекающими модификациями.

__________________

Отправлено thambs 30-11-2019 в 02:01:

XaeroX
Посыпаю голову пеплом, я точно идиот — слона не углядел.
Вот так, можно

C++ Source Code:

void*& ptr

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 30-11-2019 в 02:44:

Цитата:

thambs писал:
Вот так, можно

Так, безусловно, тоже можно, но выглядит менее красиво, и сложнее для пони-мания.

__________________

Отправлено thambs 30-11-2019 в 03:00:

XaeroX
По-моему лучше, так rvalue туда не пропихнёшь.

__________________
http://www.moddb.com/mods/monorail-quest

Временная зона GMT. Текущее время 00:02.

Страницы (3): « 1 [2] 3 »
Показать все 123 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024