@ProCxx

Страница 1761 из 2477

Ilia

16.02.2018
07:41:52

Учил года 2-3 назад html и css , c++ на уровне создания программ для решения квадратных уравнений , полтора года назад ходил на базовые курсы по java

Ну тогда уже с++ будет не первым, после Java.

Dmitry

16.02.2018
07:42:17

Ну тогда уже с++ будет не первым, после Java.

Жизнь не удалась

Ilia

16.02.2018
07:42:58

Да нет, Java как первый язык вполне ничего, главное, чтобы не последний...

Mark

16.02.2018
07:44:43

Спасибо за советы) начну с чистого Си тогда

Google

Berkus

16.02.2018
07:46:03

я так научилась кушать готовить?

я так научился кушать - без книг

@antoshkka Антон, не знаешь, почему char_traits<T>::length (а также некоторые друзья) не noexcept? также эти функции не noexcept во всех специализациях char_traits для стандартных char'ов. В libcxx, кстати, это не так. Тогда можно было бы пометить конструктор string_view как noexcept: basic_string_view(const _CharT* str) noexcept(noexcept(_Traits::length(str))) : ... conditional noexcept для того если вдруг пользователь решил написать свою специализацию char_traits с не-noexcept length функцией ?

они еще и не constexpr в чуть более старых реализациях libc++ (которые как раз и использует ЭПОЛ бле)

Для программирования микроэлектроники какой язык лучше изучать?

раст, да, читаешь жапарика и вперёд

Antony

16.02.2018
08:15:07

@antoshkka Антон, не знаешь, почему char_traits<T>::length (а также некоторые друзья) не noexcept? также эти функции не noexcept во всех специализациях char_traits для стандартных char'ов. В libcxx, кстати, это не так. Тогда можно было бы пометить конструктор string_view как noexcept: basic_string_view(const _CharT* str) noexcept(noexcept(_Traits::length(str))) : ... conditional noexcept для того если вдруг пользователь решил написать свою специализацию char_traits с не-noexcept length функцией ?

Скорее всего из-за того, что если строка не нуль терминированная то там UB. А функции с UB в стандарте не помечаются как noexcept

Anatoly

16.02.2018
08:20:27

Скорее всего из-за того, что если строка не нуль терминированная то там UB. А функции с UB в стандарте не помечаются как noexcept

а по какой причине конструкторы std::basic_string_view не помечены noexcept, принимающие const CharT*: constexpr basic_string_view() noexcept; (1) (since C++17) constexpr basic_string_view(const basic_string_view& other) noexcept = default; (2) (since C++17) constexpr basic_string_view(const CharT* s, size_type count); (3) (since C++17) constexpr basic_string_view(const CharT* s); (4) (since C++17) ?

видимо, по той же причине

Antony

16.02.2018
08:26:22

Забыли :) Кажется что стоит добавить через issue. Есть похожий issue http://cplusplus.github.io/LWG/lwg-active.html#2836 но там про конструкторы ни слова

Anatoly

16.02.2018
08:28:19

Забыли :) Кажется что стоит добавить через issue. Есть похожий issue http://cplusplus.github.io/LWG/lwg-active.html#2836 но там про конструкторы ни слова

видимо по причине того, что в случае (3) [s, s + count) может быть не valid range, а в (4) это может быть не null-terminated. в одном случае UD, в другом UB

Antony

16.02.2018
08:32:26

+1

Свеженькие предложения подоспели: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/

Сравнение контейнеров без учёта аллокаторов просили в чатике. Теперь есть на него бумага: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0805r1.html

О! Спинлоки предлагают http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0514r3.pdf

Крутые последствия одной из бумаг от РГ21 и @zamazan4ik http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0784r1.html

Google

Egor

16.02.2018
09:59:51

спинлоки - atomic_wait?

Raman

16.02.2018
10:02:29

С++ we worth

Александр

16.02.2018
10:03:59

@antoshkka Антон, не знаешь, почему char_traits<T>::length (а также некоторые друзья) не noexcept? также эти функции не noexcept во всех специализациях char_traits для стандартных char'ов. В libcxx, кстати, это не так. Тогда можно было бы пометить конструктор string_view как noexcept: basic_string_view(const _CharT* str) noexcept(noexcept(_Traits::length(str))) : ... conditional noexcept для того если вдруг пользователь решил написать свою специализацию char_traits с не-noexcept length функцией ?

код выделять лучше с помощью одинарного или тройного `

Antony

16.02.2018
10:08:22

Вот это крутая штука: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0934r0.pdf Должна убрать пару невменяемых мест в компиляторе и ускорить компиляцию

Александр

16.02.2018
11:30:26

Сравнение контейнеров без учёта аллокаторов просили в чатике. Теперь есть на него бумага: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0805r1.html

офигеть, а ведь это было моё предложение на stdcpp, какое счастье

Alexander

16.02.2018
11:32:21

офигеть, а ведь это было моё предложение на stdcpp, какое счастье

Об этом давно говорят

На cppnow был доклад Алистера по этому вопросу

Но твой голос тоже учли :)

Александр

16.02.2018
11:33:37

??

Alexander

16.02.2018
11:36:29

А тем временем чуваки пытаются расширить набор special math functions

Полиномы Чебышева, БПФ и так далее ))

Александр

16.02.2018
11:38:37

ну БПФ не так редко используется, а вот остальное - сомнительно

Alexander

16.02.2018
12:10:40

лол, это ещё пилят: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0267r7.pdf

Antony

16.02.2018
12:12:08

Оно в топ-10 на включение в C++20

Vsevolod

16.02.2018
12:15:01

жопа какая. а зачем?

Ostap

16.02.2018
12:15:35

Аналогично. Нахрена это?

Alexander

16.02.2018
12:16:21

Оно в топ-10 на включение в C++20

лол

а я думал, что на него забили

жопа какая. а зачем?

ну мне бы лично хотелось иметь всякие стандартные классы для точек

Vsevolod

16.02.2018
12:16:49

и так тут есть мнение, что c++ стремительно движется в сторону перла

Google

Vsevolod

16.02.2018
12:17:03

а мне лично не хотелось бы иметь лишний шлак в стандартной библиотеке

Alexander

16.02.2018
12:17:05

это не усложняет язык, лол. это расширение либы

а мне лично не хотелось бы иметь лишний шлак в стандартной библиотеке

можешь им не пользоваться просто?

Vsevolod

16.02.2018
12:17:15

которая и так излишне жирная

Alexander

16.02.2018
12:17:26

тебе как-то это мешает?

Antony

16.02.2018
12:17:56

которая и так излишне жирная

Лично мне кажется, что стандартная библиотека невероятно бедная

Vsevolod

16.02.2018
12:18:28

ну, это вопрос к модульности

мне подход модулей нравится больше, чем монстр в std::

Constantine

16.02.2018
12:20:41

Хм... а компилятор понимает, что unique_ptr или, скажем, указатель внутри вектора по сути __restrict?

Antony

16.02.2018
12:20:55

которая и так излишне жирная

Не хватает кучи всего для работы с числами, нет кучи контейнеров, нет взаимодействия с базми данных, нет http, нет криптографии, нет обёрток над системными вещами, нет гетерогенных вычислений, нет машинного обучения, нет поддержки популярных форматов, нет 3д, нет архиваторов, нет шейдеров, нет вещей для офиса и проч

Хм... а компилятор понимает, что unique_ptr или, скажем, указатель внутри вектора по сути __restrict?

отчасти

Igor

16.02.2018
12:21:54

Не хватает кучи всего для работы с числами, нет кучи контейнеров, нет взаимодействия с базми данных, нет http, нет криптографии, нет обёрток над системными вещами, нет гетерогенных вычислений, нет машинного обучения, нет поддержки популярных форматов, нет 3д, нет архиваторов, нет шейдеров, нет вещей для офиса и проч

и поди пойми, что из этого списка - сарказм, и есть ли он там вообще

Дед Пегас

16.02.2018
12:22:28

/me больше нравится подход как в Haskell: есть малюсенькая Prelude и куча пакетов и модулей для всего.

Но у них уже давно есть cabal и stack а у нас только щас болие-лимение начали распространяться божественный vcpkg и conan.

Constantine

16.02.2018
12:23:06

Не хватает кучи всего для работы с числами, нет кучи контейнеров, нет взаимодействия с базми данных, нет http, нет криптографии, нет обёрток над системными вещами, нет гетерогенных вычислений, нет машинного обучения, нет поддержки популярных форматов, нет 3д, нет архиваторов, нет шейдеров, нет вещей для офиса и проч

Да, как там успехи по длинной арфиметике?

Alexander

16.02.2018
12:24:21

Да, как там успехи по длинной арфиметике?

wide_int вроде нормально идут, safe_integer пока что девелопятся, undounded_integers - я работаю над этим

тут вот Ranges хотят вливаться уже: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0896r0.pdf

Да, как там успехи по длинной арфиметике?

ещё такое нашёл только что: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0828r0.md

Constantine

16.02.2018
12:25:32

ну я больше модулей компиляции жду, с тех пор как понял, что нельзя релизные сборки обмазывать extern template, потому что оптимизатор ломается

wide_int вроде нормально идут, safe_integer пока что девелопятся, undounded_integers - я работаю над этим

речь про wide_int именно, на олимпиадки очень нужны, С++ чуть ли не единственный язык, в котором нет из коробки

Google

Alexander

16.02.2018
12:27:14

ну тогда wide_integer должно хватать (да, они уже wide_integer называются)

длинная арифметика с динамическими аллокациями - это немного другое

Constantine

16.02.2018
12:27:51

длинная арифметика с динамическими аллокациями - это немного другое

это не нужно для олимпиадок :)

Vsevolod

16.02.2018
12:27:57

да, prelude у хаскеля очень хороша

Alexander

16.02.2018
12:28:04

это не нужно для олимпиадок :)

согласен

Vsevolod

16.02.2018
12:28:18

у окамля, вот, та же проблема - куча стандартных библиотек, и хрен поймешь, чем пользоваться

Alexander

16.02.2018
12:28:50

у окамля, вот, та же проблема - куча стандартных библиотек, и хрен поймешь, чем пользоваться

а у окамля стандарт есть, которому должны соотв. либы стандартные?

Vsevolod

16.02.2018
12:29:25

нет, конечно

Дед Пегас

16.02.2018
12:29:31

То ли дело в D было!)

Admin

ERROR: S client not available

Vsevolod

16.02.2018
12:29:34

его пилят три с половиной учоных и хедж фонд

https://ocaml.janestreet.com/ocaml-core/latest/doc/core/index.html

Alexander

16.02.2018
12:30:11

нет, конечно

ну тогда неудивительно, что разброд и шатания ?

Vsevolod

16.02.2018
12:30:59

а жаль, язык весьма красивый

и стремится в ту же нишу, что и c++

Antony

16.02.2018
12:33:55

и поди пойми, что из этого списка - сарказм, и есть ли он там вообще

Сарказма там нет

Alexander

16.02.2018
12:38:22

Не хватает кучи всего для работы с числами, нет кучи контейнеров, нет взаимодействия с базми данных, нет http, нет криптографии, нет обёрток над системными вещами, нет гетерогенных вычислений, нет машинного обучения, нет поддержки популярных форматов, нет 3д, нет архиваторов, нет шейдеров, нет вещей для офиса и проч

из этого списка пожалуй согласен про работу с числами, контейнеры, http, крипту и системные вещи

Igor

16.02.2018
12:41:41

Сарказма там нет

тогда я не понял, а где "нет кучи алгоритмов для работы со строками"?)

Berkus

16.02.2018
12:41:57

которая и так излишне жирная

скорее, наоборот

Matwey

16.02.2018
12:44:20

которая и так излишне жирная

Точно, это всё заговор! Напихать в стандартную библиотеку столько функций, чтобы реализовать её смогли только вполне определенные известные существующие команды

Google

Alexander

16.02.2018
12:46:41

тогда я не понял, а где "нет кучи алгоритмов для работы со строками"?)

а какая куча? trim, split, what else?))

или кто-то ICU хочет в либе? ?

Matwey

16.02.2018
12:47:37

или кто-то ICU хочет в либе? ?

Я хочу!

Alexander

16.02.2018
12:48:00