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

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

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

Racket - это язык программирования общего назначения, а также первая в мире экосистема для языко-ориентированного программирования.

Racket версии 7.0 включает существенные изменения в рамках долгосрочных целей замены текущей системы времени выполнения и поддержки множества систем времени выполнения. Предполагается, что пользователи Racket не почувствуют большой разницы между Racket 6.12 и Racket 7.0, но в связи с тем, что реализация претерпела серьёзные изменения, увеличен именно старший номер версии.

Ядро версии 7.0 является результатом переработки ядра версии 6.12 более чем на 1/8, и включает новый механизм раскрытия макросов, который осуществляет бутстрэппинг самого себя. Данный механизм покрывает более 40% кода, необходимого для замены ядра Racket на Chez Scheme. Остальные 60% кода, по бОльшей части, также реализованы, но не включены в этот выпуск; мы надеемся и предполагаем, что Racket-на-Chez будет готов для промышленного использования в следующих выпусках ветки 7.x

• Синтаксис формы (`#'`) поддерживает новые шаблоны подформ: ~@ - для сплайсинга, и ~? - для выбора между подшаблонами, основанного на возможном «отсутствии» значения у переменных образца (например, у образца ~optional в syntax-parse). Библиотека syntax/parse/experimental/template, откуда происходят эти возможности, экспортирует новые формы под старыми именами для совместимости.
• На Windows флаг --embed-dlls команды raco exe создаёт по-настоящему автономный исполняемый файл ".exe", который содержит в себе разделяемые библиотеки Racket.
• Опция «Create Executable» интегрированной среды разработки DrRacket для учебных языков (Beginner Student, и т.п.) использует флаг --embed-dlls на Windows.
• Поддержка prefab («previously fabricated») структур в Typed Racket существенно улучшена, что делает их более полиморфными, исправляя, вместе с тем, существенные ошибки текущей реализации. Программы, которые сейчас используют предикаты для prefab-структур неизвестных данных, могут нуждаться в ревизии, т.к. предыдущие версии Typed Racket позволяли программам с потенциальными ошибками осуществлять проверку типов. Смотрите Typed Racket RFC 1 и prefab-changes для более подробной информации об этом изменении, и о том, как исправить программы, которые подверглись влиянию в связи с этим изменением.
• Typed Racket поддерживает #:rest-star в конструкторе типов ->*, что позволяет функциональным типам указывать в хвостовом списке аргументов (rest arguments) более сложные образцы типов, такие как функция hash.
• Интерактивные оверлеи могут быть наложены на графики, созданные с помощью plot-snip. Это позволяет создавать интерактивные графики или отображать дополнительную информацию, когда указатель мыши находится над областью графика. Примеры использования данной возможности можно посмотреть тут.
• racket/plot предоставляет процедуры для отображения графиков японских свечей (candlestick charts), которые могут быть использованы в финансовом анализе временных рядов.
• Добавлен contract-equivalent?, который проверяет, что два контракта являются взаимосильными, без экспоненциального замедления, которое имеет место в случае двух вызовов contract-stronger?.
• Lazy Racket поддерживает функции с именованными аргументами.

>>> Оригинал

Всем привет!

Сегодня в мире т.н. «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++?

Пусть есть класс 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. Какие будут соображения на этот счёт?

Добрый день.

Рассмотрим пример из 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?

Спасибо.

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

Есть такой замечательный язык 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

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

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

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

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