(реализации ни в GCC ни в clang транках пока нет)

Вопрос про констукторы.

Какой смысл во всех этих конструкторах если, согласно доке, все методы являются constexpr-методами? Из этого можно сделать весьма уверенный вывод, что реализация будет примерно такой(т.е. конкретные значения будет генерить компилятор, т.е. копировать/инициализировать тут нечего):

struct source_location {
   constexpr std::uint32_t line() const { return __LINE__; }
   constexpr std::uint32_t column() const { return ТАКОЙ МАКРОС МНЕ НЕ ИЗВЕСТЕН; }
   constexpr const char* file_name() const { return __FILE__; }
   constexpr const char* function_name() const { return __PRETTY_FUNCTION__; }
};

Такой же вопрос про статический метод current().

Или же это сделано для симуляции value семантики?

Здравствуйте, Tasheehoo, Вы писали:

T>Какой смысл во всех этих конструкторах если, согласно доке, все методы являются constexpr-методами?
одно другому не противоречит. первый конструктор constexpr, там все поля класса проинициализиурются константами времени компиляции
два других конструктора сгенерятся, ибо default и скорее всего тоже должны быть constexpr (хз какие правила для "= default")


T>Из этого можно сделать весьма уверенный вывод, что реализация будет примерно такой(т.е. конкретные значения будет генерить компилятор, т.е. копировать/инициализировать тут нечего):
странный вы сделали вывод, я бы сделал другой вывод:
current() должен захватить все значения макросов типа __LINE__ и засунуть уже в класс source_location, а тот просто возвращает их
набросок

sourceLocation current()
{
  int line = __LINE__OF_THE_CALLER_SITE__ <--- magic?
  return sourceLocation(line, ....);
}

struct source_location
{
  const int m_Line;

  source_location(int line, .....)
    : m_Line(line)
  {
  }

  constexpr std::uint32_t line() const { return m_Line; }
}

Здравствуйте, uzhas, Вы писали:
U>странный вы сделали вывод, я бы сделал другой вывод:
U>current() должен захватить все значения макросов типа __LINE__ и засунуть уже в класс source_location, а тот просто возвращает их

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

Вот, доку нашел.

Здравствуйте, Tasheehoo, Вы писали:

T>В таком случае должен быть соответствующий конструктор, не? Именно из-за отсутствия этого конструктора я и сделал такой вывод...
обычно документируют публичное API, так что по факту там могут быть еще какие-то конструкторы, но стандарт (или драфты, как в данном случае) не обязывает их иметь

Здравствуйте, uzhas, Вы писали:

U>обычно документируют публичное API, так что по факту там могут быть еще какие-то конструкторы, но стандарт (или драфты, как в данном случае) не обязывает их иметь
В общем, пока не будет реализации, много не ясно.

Спасибо.
Вопрос решен.

Здравствуйте, Tasheehoo, Вы писали:

T>(реализации ни в GCC ни в clang транках пока нет)

вот меня постоянно мучает другой вопрос: зачем, ну зачем (!?) все эти библиотеки (в основном логгерские, а тут еще и std тудаже) делают line целочисленным типом???
для какой-такой арифметики оно нужено? все что с ним происходит это преобразование в строку (зачастую std::string, ага, с аллокацией(!)) и последующая печать/вывод в лог...
почему сразу не делать его constexpr char* строкой? -- можно избежать в рантайме кучу действий (при выводе это будет просто конкатенация строк)...

Здравствуйте, zaufi, Вы писали:

Z>вот меня постоянно мучает другой вопрос: зачем, ну зачем (!?) все эти библиотеки (в основном логгерские, а тут еще и std тудаже) делают line целочисленным типом???
Z>для какой-такой арифметики оно нужено? все что с ним происходит это преобразование в строку (зачастую std::string, ага, с аллокацией(!)) и последующая печать/вывод в лог...
Z>почему сразу не делать его constexpr char* строкой? -- можно избежать в рантайме кучу действий (при выводе это будет просто конкатенация строк)...

#include <iostream>

#define STR1(x) #x
#define STR2(x) STR1(x)

int main() {
    const char* str = STR2(__LINE__);
    std::cout << str << std::endl;
    return 0;
}

Здравствуйте, zaufi, Вы писали:

Z>вот меня постоянно мучает другой вопрос: зачем, ну зачем (!?) все эти библиотеки (в основном логгерские, а тут еще и std тудаже) делают line целочисленным типом???
Это же можно сконвертить в строку хоть макросом, хоть constexpr-выражениями, и никаких std::string и аллокаций.

Тут несколько примеров.
А тут в обратном направлении.

Здравствуйте, Tasheehoo, Вы писали:

T>Здравствуйте, zaufi, Вы писали:

Z>>вот меня постоянно мучает другой вопрос: зачем, ну зачем (!?) все эти библиотеки (в основном логгерские, а тут еще и std тудаже) делают line целочисленным типом???
T>Это же можно сконвертить в строку хоть макросом, хоть constexpr-выражениями, и никаких std::string и аллокаций.

T>Тут несколько примеров.
T>А тут в обратном направлении.

я знаю как это сделать! вопрос (риторический) в том, зачем во всяких log4cxx или там apache, а теперь вот и в std это делают int'ом?? -- какой глубокий смысл делать это intтом, когда все, на что способны эти библы/логгеры это тратить, почем зря, ресурсы на перевод int'a в строку, когда этого можно было не делать, а сразу иметь номер строки в виде строки...

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, zaufi, Вы писали:

Z>>вот меня постоянно мучает другой вопрос: зачем, ну зачем (!?) все эти библиотеки (в основном логгерские, а тут еще и std тудаже) делают line целочисленным типом???
Z>>для какой-такой арифметики оно нужено? все что с ним происходит это преобразование в строку (зачастую std::string, ага, с аллокацией(!)) и последующая печать/вывод в лог...
Z>>почему сразу не делать его constexpr char* строкой? -- можно избежать в рантайме кучу действий (при выводе это будет просто конкатенация строк)...

я вот о чем... давно использую такой вот класс:

template <
    typename File = const char*
  , typename Line = const char*
  , typename Function = const char*
  >
class basic_location
{
    // blah-blah-blah
};

для своих нужд у меня есть:

typedef basic_location<const char*, const char*, const char*> location;

а когда приходится интергрироваться с не к ночи упомянутыми библами в которых line у source location это целочисленный тип:

typedef basic_location<const char*, int, const char*> weird_source_code_location;

и я бы предпочел в std иметь как можно более общий вариант, а не жестко навязывать типы полян в source_location...

Здравствуйте, Tasheehoo, Вы писали:

T>Вопрос про констукторы.
T>Такой же вопрос про статический метод current().

Я так понимаю, что самое интересное в source_location — его поведение, когда он используется как default parameter. Раньше нельзя было получить подобное без макросов (наподобии костылей #define new DEBUG_NEW)

a.h

void f(source_location loc = source_location::current());

a.cpp

void f(source_location loc)
{
  std::cout << loc.file_name() << std::endl;
}

b.cpp

f(); // prints b.cpp

c.cpp

f(); // prints c.cpp