LINUX.ORG.RU

Сообщения azelipupenko

 

Разработка Web-интерфейса с пользователем.

Уважаемые коллеги!

Сегодня существует великое множество различных т.н. «веб-фреймворков» для создания различных интерактивных сайтов. (Кстати, почему и зачем так много, что любой обыватель может легко потеряться в таком изобилии, лол?) Однако, практика показывает, что многие из этих модных-модных достижений силы современной программистской мысли преподносят не самые приятные сюрпризы уже после того, как разработчик их использующий, окунётся с головой в разработку своего очередного творения мирового масштаба, рассчитанного на сверхнагрузки (aka HighLoad в мечтах и фантазиях).

Поэтому резонно возникает вопрос: какой технологией для создания качественных (простых и надёжных) web-интерфейсов, которая вас не подводила, пользуетесь вы, уважаемые коллеги, профессиональные web-разработчики? :-)

 ,

azelipupenko ()

Хвалёные смарт-поинтеры.

Всем привет!

Сегодня в мире т.н. «modern C++» принято нахваливать смарт-поинтеры. Дескать, это такая крутая технология, которая решает множество проблем. Как это всегда получалось, решение одних проблем порождало решение других проблем. Какие проблемы порождают смарт-поинтеры? Рассмотрим код, который валиден и прекрасно собирается:

struct B {
  virtual B* clone() = 0;
};

struct D : B {
  virtual D* clone() = 0;
};

struct impl : D {
  D* clone() override
  {
    return new impl;
  }
};

int main()
{
  auto b = new impl;
  b->clone();
}

Но стоит только превратить указатели в std::unique_ptr, как всё перестаёт собираться. И вот это уже вызывает смех. Ведь если ув. эксперты, уполномоченные принимать решения в части изменения стандарта, ввели смарт-поинтеры в язык, громогласно заявив при этом, что хватит писать на «голых» указателях, т.к. в современном C++ уже всё на смарт-поинтерах, то почему же тогда с этими хвалёными стандартными смарт-поинтерами ломается ковариантность? :-) C++ как он есть.

А какие вы знаете проблемы со смарт-поинтерами в современном C++?

 , , ,

azelipupenko ()

Цепочки методов в C++ (return void vs return this)

Пусть есть класс Foo:

class Foo
{
public:
  void setBar(Bar bar);
  Bar bar() const;

  void someAction();

  void anotherAction();
};

Модифицируем его API следующим образом:

class Foo
{
public:
  Foo& setBar(Bar bar);
  Bar bar() const;

  Foo& someAction();

  Foo& anotherAction();
};

Теперь вопрос к уважаемой публике. Какой API вам нравится больше? Другой вопрос: почему бы всегда вместо void возвращать *this/this? Вот в стандартной библиотеке есть цепочки методов, в том же std::string, но не все его методы возвращают *this. Какие будут соображения на этот счёт?

 

azelipupenko ()

std::optional<T> vs специальные значения.

Добрый день.

Рассмотрим пример из Boost:

// Here, having received an empty vec and having no size_t to return is not a failure but a normal, albeit irregular, situation.
template <typename T>
optional<size_t> find_smallest_elem(const std::vector<T>& vec);

Теперь посмотрим на std::string:

// Returns: xpos if the function can determine such a value for xpos. Otherwise, returns npos.
size_type find(const basic_string& str, size_type pos = 0) const noexcept;

Внимание, вопросы:

  1. Какой API вам кажется приятнее?
  2. Если да, то чем это лучше подхода std::string::npos?
  3. Если это лучше подхода std::string::npos, то чем думали члены комитета при выпуске C++17, где же этот их самый optional в API того же std::string?

Спасибо.

 ,

azelipupenko ()

Продолжаю удивляться C++.

Добрый день, уважаемые разработчики!

Есть такой замечательный язык C++ со своими правилами, парадигмами, хорошими и плохими практиками, а также с хорошими и плохими библиотеками. И вот есть такое правило, что константные объекты менять нельзя. Казалось бы, правило логичное, и хорошие мальчики и девочки должны ему прилежно следовать.

Однако существует ещё такая библиотека, как Boost.Exception. В ней есть такая возможность, как дополнять объекты исключения произвольной информацией с помощью оператора <<. Причём, дополнять можно не просто объекты, а объекты константные. Давайте посмотрим API:

template <class E, class Tag, class T>
    E const & operator<<( E const & x, error_info<Tag,T> const & v );

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

const там только потому, что в противном случае, в функцию можно было бы передать только lvalue, что не очень подходит для исключений, где объекты как правило создаются и используются без каких-либо промежуточных переменных. (C) anonymous

 

azelipupenko ()

Продуктивность разработки на C++.

Уважаемые программисты!

Предлагаю порассуждать о продуктивности разработки на C++ по сравнению с так называемыми скриптовыми языками. Вот, принято считать, что языки на вроде Python позволяют работать программисту более продуктивно по сравнению с C++. И что, дескать, на C++ надо писать только узкие места и всё такое.

Мне же хочется четкого понимания. Может быть это миф? А может быть это просто инерция, потому что так вот принято считать и все тут. Вот сегодня в C++ уже не надо думать об освобождении памяти, так как есть умные указатели. Сегодня есть уже более-менее нормальные IDE для C++. Так? Так.

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python? Какие будут рассуждения? Может быть есть какие-то реальные обоснования на этот счёт, кроме как «в конторе Y так делают, значит смысл есть, они умные, им виднее». А может быть есть какие-то рецепты по продуктивности работы на C++?

 , ,

azelipupenko ()

RSS подписка на новые темы