Здравствуйте, PlusMyTwitterFace, Вы писали:
К>>Если функция принимает указатель, то она, вроде бы, обязана проверять на ноль
PMT>Не хотелось бы на это просто рассчитывать.
А что про передачу NULL в качестве параметра этой функции говорит документация по библиотеке?
PARAM param = PARAM();
// установи нужные поля. Остальные будут NULL.
foo(¶m);
верно компилируется сильно не всеми компиляторами, так что, формально, прав, конечно же ты, а вот на практике, код Дворкина возможно таки и попереносимее может оказаться...
Хотя бываеют, конечно, контроллеры, в которых нулевой бинароно указатель вполне валиден
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PlusMyTwitterFace, Вы писали:
PMT>В C99 и C11 эту проблему можно решить при помощи compound literals:
PMT>В C++ на ум приходит лишь два решения:
А что за С++? 03 или можно 11?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
> Можно ли каким-то образом "избавиться" от "лишних" аргументов функции?
В бусте кстати есть библиотека поддержки именованных параметров.
Используется в boost::graph. Но саму библиотеку я забыл.
Можеш либо использовать, либо стянуть идею.
Здравствуйте, Erop, Вы писали:
F>>NULL не всегда равен 0! Ваш код не переносим.
E>К сожалниею, переносимый код
E>PARAM param = PARAM();
E>// установи нужные поля. Остальные будут NULL.
E>foo(¶m);
верно компилируется сильно не всеми компиляторами, так что, формально, прав, конечно же ты, а вот на практике, код Дворкина возможно таки и попереносимее может оказаться... E>Хотя бываеют, конечно, контроллеры, в которых нулевой бинароно указатель вполне валиден
Ваш вариант тоже не переносим (что бы стал переносим нужно написать свой конструктор "по умолчанию", но это уже другой разговор). Более того, он не корректен для С.
Здравствуйте, freestyle, Вы писали:
F>Ваш вариант тоже не переносим (что бы стал переносим нужно написать свой конструктор "по умолчанию", но это уже другой разговор).
Чушь, ботай value initialization.
F>Более того, он не корректен для С.
И что с того?
Да, вариант с агрегатом сбивает оптимизаторы. Например, оптимизатор MSVC...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PlusMyTwitterFace, Вы писали:
M>>Ну сделай несколько врапперов. Делов-то.
PMT>Как я уже сказал выше, данные функции принадлежат библиотеке.
Ну и? Пускай принадлежат.
M>>и?
PMT>А ничего, что таких врапперов мне придётся тогда написать, скажем, 200?
Ты намерен использовать все 200 врапперов? Если нет(а я уверен, что нет), то не пиши 200. Делов-то
Здравствуйте, Erop, Вы писали:
F>>Ваш вариант тоже не переносим (что бы стал переносим нужно написать свой конструктор "по умолчанию", но это уже другой разговор).
E>Чушь, ботай value initialization.
Сами сначала изучите "value initialization".
F>>Более того, он не корректен для С. E>И что с того?
Ничего, все
E>Да, вариант с агрегатом сбивает оптимизаторы. Например, оптимизатор MSVC...
Спасибо за совет, ознакомлюсь с Вашей реализацией.
Есть, правда, пара моментов:
— Здесь присутствует ошибка с порядком инициализации полей — deleter объявлен в классе раньше data, хотя инициализируется в списке инициализации конструктора позже.
— gcc 4.7.1 не компилирует assert'ы в данном коде. Пока не вникал в суть ошибок.
Здравствуйте, PlusMyTwitterFace, Вы писали:
PMT>- Здесь присутствует ошибка с порядком инициализации полей — deleter объявлен в классе раньше data, хотя инициализируется в списке инициализации конструктора позже.
А кто тебе сказал что это ошибка? (порядок вызова от этого не меняется)
Здравствуйте, PlusMyTwitterFace, Вы писали:
PMT>- Здесь присутствует ошибка с порядком инициализации полей — deleter объявлен в классе раньше data, хотя инициализируется в списке инициализации конструктора позже.
не пофиг ли?
PMT>- gcc 4.7.1 не компилирует assert'ы в данном коде. Пока не вникал в суть ошибок.
#include <assert.h> типа...
Но уровень дискуссии доставляет. Ты правда не знаешь, что такое assert?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
В данном случае всё равно.
E>Но уровень дискуссии доставляет. Ты правда не знаешь, что такое assert?..
Не понял. К чему этот вопрос и с чего он возник? Вы думаете, что я не в состоянии включить cassert / assert.h?
Ошибки, на самом деле, возникали в связи с -Wall -Werror, с которыми я запускал gcc, из-за всё того же порядка инициализации. Про assert показалось, просто рядом было.
Здравствуйте, PlusMyTwitterFace, Вы писали:
PMT>В данном случае всё равно. PMT>Не понял. К чему этот вопрос и с чего он возник? Вы думаете, что я не в состоянии включить cassert / assert.h?
Ну раньше думал, что в состоянии, но теперь не уверен...
PMT>Ошибки, на самом деле, возникали в связи с -Wall -Werror, с которыми я запускал gcc, из-за всё того же порядка инициализации. Про assert показалось, просто рядом было.
На самом деле это был код, написанный для демонстрации концепции, он вообще не обязан компилироваться...
Но уровень дискуссии всё равно доставляет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Прада, если делать это всё законченным решением, то нехило бы поддержать ещё и буфера.
Например, можно приписать operator[], которому в аргумент передаёют размер буфера, а он возвращает аналог или наследник CFakeArgument, который по operator T*() аллокирует буфер нужного размера. Правда всё раво не ясно, что делать с T**, которые обычно используются для того, что бы передать указатель на буфер, который будет аллокирован внутри функции и возвращён наружу, так как есть, как минимум два популярных способа его разрушения. Через free и через delete[]...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sni4ok, Вы писали:
S>чё за бред, по вашему и strlen на 0 проверяет?
Я думаю, что имелись в виду факультативные параметры...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
ндя.... прочитал все и так понял, что не удивительно, что у нас год от года все больше гигарец и гигабайт доступно, но проги все больше и больше тупят и тормозят...
уважаемый PlusMyTwitterFace: писать самое главное надо просто — и если вам что-то не нравиться в чем-то — это не повод изобретать велики и носки-самокаты с нуля. И все уважаемые советчики — нахрена в данной ситуации вы даже просто позволили себе подумать — А КАК эту задачу можно решать по другому? Нахрена городить уйму строк с шаблонами и черт-еще-знает-чем? Просто потому что С++ это позволяет — а вы решили что так можно написать?
Простейшая ситуация, когда надо задать только последний параметр в функции превратилась просто в монстра по решениям. Вам не страшно потом этот ужас поддерживать? Исправлять? Передавать, так сказать, по наследству кому-то?
Вот ответьте сперва на главнейший вопрос — нафига в вопросе, заданном PlusMyTwitterFace вообще искать какое-то новое решение?
Кто и главное КАК выиграет от нового решения? и в чем?