Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 42

Велосипедисты, Сталин дал приказ!

Велосипедисты, зовёт Отчизна нас!

Всего голосов 6: ↑4 и ↓2+2

Обажаю подобные штуки для С++, спасибо.

Всего голосов 2: ↑1 и ↓10

Boost multi_index на порядок функциональнее и позволяет создавать множество индексов на данные не двигая в памяти сами данные. И главное - читый C++, никаких макросов.

Всего голосов 7: ↑7 и ↓0+7
Где вы видите двиганье данных? Индекс, это вектора указателей, разложенные по мапам или просто упорядоченные. Т.е. когда я пишу что можно работать с std::vector<Row*>, не меняя синтаксиса, то это это самое и будет.

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

А на счет multi_index, спасибо, позже посмотрю, что можно от-туда взять себе в пользование.

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

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

Что-нибудь типа такого? (навскидку):

#include <iostream>

struct Row
{
  int id;
  double value;
};

template<typename R, typename T>
auto &getMemberRef(const R &row, T member)
{
  return row.*member;
}

int main()
{
  Row item = {1, 2.2};

  std::cout << getMemberRef(item, &Row::id)
    << " " << getMemberRef(item, &Row::value) << std::endl;
}
Всего голосов 1: ↑1 и ↓0+1
Не, это не реализует ничего, кроме:
#include <iostream>

struct Row
{
  int id;
  double value;
};

int main()
{
  Row item = {1, 2.2};
  std::cout << item.id << " " << item.value << std::endl;
}

Зачем здесь прилепили getMemberRef это не понятно.

А вот если бы показали, как суммировать, сортировать, поиск значения. Как это все раздувается и обвешивается дополнительными конструкциями, и код становится ради кода, а не ради результата.
Всего голосов 1: ↑1 и ↓0+1

getMemberRef - это как пример того, что можно сделать вместо вашего генератора лямбд на макросах (то что у вас называется COLUMNS) чисто средствами языка. А в плане остального вам уже предлагали посмотреть на Boost Multi-index.

Всего голосов 1: ↑1 и ↓0+1
Так я и говорю, покажите как именно этот вариант примените хотя бы к std::sort, сколько это дополнительных строк возьмет. Ну или может на бустовских каких-нибудь функциях. Как вы будете суммировать такую колонку, и т.д. У меня же то же, не запрещается использовать свои лямбды без макросов, о чем я и писал.

Будет интересно посмотреть на обвес, когда вы попробуете написать поиск по двум колонкам.

UseCols::findFirst(table,
 [](auto& item) { return std::tuple(item.f1, item.f2); },
 2, 3);

Вот мой вариант, без макросов. А у вас как будет? Весь код не обязательно, только сам поиск, и объявления дополнительных функций, если таковые нужны. Но если доп.функции отсылаются к типу Row, то это прицеп раздувающий код, а не либу.
Комментарий пока не оценивали0

Например так:

template<typename... Ts>
auto createMemberRefAccessor(Ts... members)
{
  return [members...](auto &row) {
    return std::forward_as_tuple(row.*members...);
  };
}

UseCols::findFirst(table,
                   createMemberRefAccessor(&Row::id, &Row::value),
                   2, 3);

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

Всего голосов 3: ↑3 и ↓0+3
Очень спасибо. Добавлю такой вариант в копилку к этой либе. Будет альтернатива макросу. Чуть позже оформлю и добавлю.
Всего голосов 2: ↑1 и ↓10

А зачем вообще макросы?

Всего голосов 2: ↑2 и ↓0+2
Проблема не в макросах, проблема в головах. Одни любят придумать шаткие и сложнопонимаемые макросы — болезнь унаследованная от С. Другие видят эту болезнь в каждом макросе, и даже типовые #ifndef в хеадерах заменяют на #pragma once.

Одни могут и перочинным ножичком себя покалечить. Другие могут ходить с ружьем десятки лет, и не отстреливать себе ногу, но получая прибыль от этого большую, чем если бы ходили с перочинным ножиком.
Всего голосов 5: ↑2 и ↓3-1

Плохой пример. #pragma once же лучше в любом случае. А если можно без макроса, то вообще хорошо.

Добавлю. Ваш макрос выглядит как раз сложным. Я понимаю простой макрос как азерт или тест, когда надо только прилепить номер строчки.

Всего голосов 3: ↑3 и ↓0+3

У #pragma once свои проблемы. Во-первых, она не везде есть. Во-вторых, она не работает правильным образом, если включаемый файл имеет несколько имён (скажем через симлинки) и одна часть кода включает его под одним именем, а другая - под другим.

Комментарий пока не оценивали0

Мне кажется что если в компиляторе нету pragma once то он не из тройки и модерн С++ там тоже нету.

Комментарий пока не оценивали0
template<typename R, typename F1, typename F2, typename V1, typename V2>
auto& findFirst(const std::vector<R>& table, F1 f1, F2 f2, V1 v1, V2 v2)
{
    for (auto& i : table)
        if (i.*f1 == v1 && i.*f2 == v2) return i;
    return R{};
}

auto found = findFirst(table, &Row::id, &Row::value, 1, 7.0f);
Комментарий пока не оценивали0

Я так понял нужно предоставить генератор функций/лямбд которые принимали бы row и выдавали бы tuple со ссылками на перечисленные элементы этого row, вот выше пример как это сделать без макросов.

Комментарий пока не оценивали0
Именно. И тогда после того как сформирован tuple, отпадает необходимость отсылаться к частному типу из vector. И тогда возможность построения универсальных алгоритмов на этом существенно возрастает.
Комментарий пока не оценивали0
Этот вариант не совсем подходит под универсальные, он под фиксированное количество полей. Но его можно поменять на вариадичный, нужно будет сделать функцию сравнения вариадичной, и вызывать ее из такой findFirst. Непосредственно здесь ошибочка, возврат ссылки на локальное значение в случае не найденности.
Комментарий пока не оценивали0
возврат ссылки на локальное значение в случае не найденности
Да, проблемка. А как надо?
    static R value;
    return value;
}
Комментарий пока не оценивали0
Нужно возвращать итератор, т.е. тип decltype(list.begin()), и в случае не найденности list.end(). Если конечно не хотим копировать всю структуру строки в результат.

Или указатель на элемент списка, т.е. тип decltype(&*list.begin()), и в случае не найденности nullptr.
Всего голосов 1: ↑1 и ↓0+1

Ещё один вариант — вернуть std::optional<R&>

Всего голосов 1: ↑1 и ↓0+1
И на что будет ссылаться R& в случае не найденности? А если пользователь метода хочет использовать копирование для результата? Ссылки не переопределяются, и следовательно операторы копирования или перемещения работать не будут.

В любом случае, возврат ссылки будет не стабильным и не красивым для этого случая. Общеприменимая практика это возврат итератора.
Комментарий пока не оценивали0

А почему оно куда-то должно ссылаться, если в случае "ненайденности" возвращаться будет пустой optional?


Для копирования же — да, нужен std::reference_wrapper.

Комментарий пока не оценивали0
Потому что пустой ссылка быть не может, такое не компилируется. Чуть ниже qw1 написал про это.
Комментарий пока не оценивали0
Может, вернёмся к старым добрым указателям? R* отличный тип для возврата )) Почему они сейчас не в моде…
Комментарий пока не оценивали0
вариант — вернуть std::optional<R&>
А можно пример?
std::optional<R&> op;
Не компилируется.
Комментарий пока не оценивали0

Верно, в стандарт не приняли такое. Есть boost::optional с поддержкой ссылок.

Комментарий пока не оценивали0

Вы слышали про std::sort который принимает любой компаратор? Про то что можно создавать ссылки на поля, типа
template<typename C, typename T>
auto Foo(T C::* value) {
return 10;
}

Зачем всё сделано на макросах?

Комментарий пока не оценивали0
Если Вы про макросы, то значит Вы не то увидели, что я хотел показать. Классический std::sort не принимает никаких указателей на поля. Я показал, какой должна быть функция сортировки, что бы туда можно было перечислить поля, без описания всего компаратора. В больших количествах сортировок по множеству полей, это очень утомительно прописывать, легко запутаться, что является источником ошибок.

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

Если Вы про что-то другое, то напишите полный пример. Незабудьте его проверить на компилируемость, а то, то что выше, не похоже на компилируемое.
Комментарий пока не оценивали0

Может вы хотя бы годболтом научитесь пользоваться? Или вы на глаз компилируете?

легко запутаться, что является источником ошибок

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

Заглянул в реализацию - шаблоны разеделены на хедеры и cpp, всё, это уже автоматически ifndr, не используются универсальные ссылки вообще

Комментарий пока не оценивали0
Ну да, компилится. Не приходилось использовать такой синтаксис. Тут чуть выше более простой вариант чем Ваш указывался.

Это не отменяет того, что я до этого написал.
Комментарий пока не оценивали0
Макросы с короткими именами, типа CAT или FIELD — может в любой момент вылезти боком.

Я например несколько недоумевал, почему не компилируется такой код
enum class ITERATOR_RESULT { SUCESS, ERROR, EOF };
Оказалось, что ERROR и EOF опрелены макросами в windows.h
Всего голосов 2: ↑2 и ↓0+2
Да, такое бывает. Чуть позже позаменяю все короткие названия на гитхабе.
Комментарий пока не оценивали0

У меня бы члены подобного энума имели бы префикс «IR_». И от таких эксцессов защищает, и немного повышает читаемость и самодокументируемость кода.

Комментарий пока не оценивали0
В итоге так и сделал. Но это enum class, а не enum, поэтому префикс приходится дважды указывать.
Комментарий пока не оценивали0

Я бы скорее посоветовал ничего, кроме макросов не называть в ALL_CAPS. А уже макросам обязательно давать префиксы и вообще минимизировать их количество.


Как уже правильно заметил qw1, тут префикс будет просто повторяться дважды, соответственно читаемость и самодокументируемость никак не улучшит.

Всего голосов 3: ↑3 и ↓0+3
Да много где такой code-style, что enum members — all caps.
Всего голосов 1: ↑0 и ↓1-1

Знаю, что практика распространённая, но считаю её вредной — мало того, что вот таким неприятным конфликтам имён способствует, так ещё и привлекает излишнее внимание к совершенно безобидному использованию enum'ов.

Всего голосов 4: ↑4 и ↓0+4
много где такой code-style, что enum members — all caps

Любителей такого стиля можно посылать сюда, с аргументом «it's in the book»:
ES.9: Avoid ALL_CAPS names
Reason Such names are commonly used for macros. Thus, ALL_CAPS name are vulnerable to unintended macro substitution.
Всего голосов 1: ↑1 и ↓0+1
10 лет прошло. Оперативненько.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr