Об светлом будущем C++

Есть ощущение, что к разработке софта (по крайней мере к серьезной)

Так софт не ограничен «серьёзной разработкой». Есть не серьёзная разработка, когда нужны какие-то костыли сейчас и просто, чтобы было удобно. Почему нет?

Есть не серьёзная разработка, когда нужны какие-то костыли сейчас и просто, чтобы было удобно. Почему нет?

Потому что в одноразовых программах затраты на «свой карманный язычок» могут не окупиться.

Какой нужен положительный опыт? Я делал макрос на си, мне понравилось. Сойдёт за положительный опыт?

Нет. Масштаб задачи слишком мал.

Прикинь: 1) расходы на реализацию 2) выигрыш по времени от реализованного

Прикинул. Получил, ~0, 150.

Ага. И так сделает каждый. И будет у вас N вариантов foreach.

Да я не против, пусть делают себе хоть по 10 пар. Кто-то заставляет писать всем вместе? А если надо писать вместе нельзя договориться или что?

Так софт не ограничен «серьёзной разработкой»

В рамках разговора про будущее C++ ограничен.

Почему нет?

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

А если речь идет не о 200 строк, а о 20K или 200K, или 2M строк, то здесь уже другой разговор. И ваши личные «закидоны» должны идти в пешее эротическое путешествие, поскольку понятность и сопровождабельность кода с ростом кодовой базы гораздо важнее вашего личного «удобства».

Нет. Масштаб задачи слишком мал.

Так мне больше и не надо.

Потому что в одноразовых программах затраты на «свой карманный язычок» могут не окупиться.

Какие затраты? Сделать replace?

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

Они пишут, что 95% их кода кроссплатформенно.

В рамках разговора про будущее C++ ограничен.

А c++ принципиально нельзя писать свои поделки, потому что eao197 так сказал?

Вы можете написать 250 строк без метапрограммирования вместо 200 и этого никто не заметит.

Я замечу.

А если речь идет не о 200 строк, а о 20K или 200K, или 2M строк

2М строк и так даром не нужны ни как каком яп, я считаю.

поскольку понятность и сопровождабельность кода с ростом кодовой базы гораздо важнее вашего личного «удобства».

Так я не против. Я же не говорю, что надо делать новый systemd-like яп. Я просто говорю, что не плохо было бы, чтобы у программиста была возможность самому себе выбирать конструкции. А там люди разберутся без сопливых как им удобнее писать код.

C?

А c++ принципиально нельзя писать свои поделки, потому что eao197 так сказал?

Так уж получилось, что в последние лет 15 (минимум) C++ не нужен в мелких программках на выброс. Т.е. ничто не запрещает их вам писать, но погоды они не делают.

C++ все еще нужен там, где затраты на его использование окупаются. А это либо огромный легаси (вроде того, что в упомянутой статье про кодовую базу 1С). Либо сложные и более-менее большие проекты с серьезными затратами на разработку.

В остальном C++ не нужен в современном мире.

2М строк и так даром не нужны ни как каком яп, я считаю.

Ой, простите, я сразу не понял, что говорю с «малолетним дебилом» (с)

Ваше мнение из палаты №6 очень ценно для нас, продолжайте держать в курсе.

Ага wchar

Нет. Масштаб задачи слишком мал.

Так мне больше и не надо.

Так и пользуйся «макросами Си».

Потому что в одноразовых программах затраты на «свой карманный язычок» могут не окупиться.

Какие затраты?

Вот такого вида:

crutch_master> всё можно оттранслировать в существующий яп.

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

Но ты это, подожди. В с++ же есть препроцессор. Да там вообще ничего не мешает приделать аж свой препроцессор.

Т.е. ничто не запрещает их вам писать, но погоды они не делают.

Так я и не собирался делать погоду в ынтерпрайзе. Чего ты с ним привязался ко мне?

В рамках разговора про будущее

Так у него нет будущего, это уже ясно и много раз обсуждалось.

«как мы с нашим ненужно сделали ненужное» (с) Напомнило как Цдиез-хипсторы устраивали спешные переписывания делегатов на лямбды... а говно типа конкатенации строк в цикле оставалось не тронутым.

А истинный™ путь развития - это метаязык, на котором можно делать свои языковые конструкции и пути исполнения кода. Такой, чтобы любой существующий язык мог быть им выражен.

И даже небо, даже Аллах.

На самом деле такие языки давно уже есть. Просто они не особо популярны, раз, например, вы о них не знаете. Не ломитесь в открытую дверь.

Так и пользуйся «макросами Си».

Так пользуюсь. Но они ограниченные очень.

Вот такого вида:

Так сделать один раз replace - это не затраты. Сделать для этого возможность на уровне яп - ну может быть, но это не то, чтобы очень. Пытался ковырять на эту тему duktape, но там чёрт ногу сломит, а это, между прочем - промышленный труЪ язык си, а не какая-то там метаподелка.

На самом деле такие языки давно уже есть.

Например?

Но ты это, подожди.

Зачем? Чем разговор с вами может быть полезен лично мне? Или кому-то из читателей этой темы вообще?

В с++ же есть препроцессор.

Видимо, вы им никогда не пользовались.

Да там вообще ничего не мешает приделать аж свой препроцессор.

Ничего, кроме порога сложности.

Чего ты с ним привязался ко мне?

Потому что ваши половые сложности с разработкой микропрограммулек не интересны. А то, как развивается C++ под требованиями от того же энтерпрайза — интересно.

Так у него нет будущего, это уже ясно и много раз обсуждалось.

«А мужики-то и не знают» (с)

Так сделать один раз replace - это не затраты

О чем ты вообще?

Пытался ковырять на эту тему duktape

Да уж, «сделать один раз replace».

Например Racket. Тут лучше послушать monk

На самом деле такие языки давно уже есть.

Например?

Ocaml + p4, бгг.

«А мужики-то и не знают» (с)

Да все всё знают. В мозилле хипсторы аж целый раст сделали. Про легаси ты сам всё сказал.

Ничего, кроме порога сложности.

Да я не спорю с этим, что тебе так не понятно?

Потому что ваши половые сложности с разработкой микропрограммулек не интересны. А то, как развивается C++ под требованиями от того же энтерпрайза — интересно.

Ну и что ты ко мне привязался со своим ынтрепрайзом, раз не интересно?

Я хочу заверить как сооснователь фонда ООО «Нинужно» что шрифты и даже в консоле не нужны и мое ноу хау представляет собой черный экран в котором при включений появляется белый цвет и им удобно пользоваться как тем же фонариком

Например Racket
(+ x y)

Понимаешь, надо человекочитаемый. А человекочитаемый - это просто x + y

p4 вроде бы задепрекейтили, я слышал звон.

p4 вроде бы задепрекейтили, я слышал звон.

Я тоже слышал. Но вместо него что-то сделали же. Вот, нашел: ppx.

не нужно. C++98 хватит всем (а кому-то и C89)

Что нужно в C++ по моему мнению:

1. Сильная типизация. То есть нужно чтобы при компиляции примера ниже выдавало ошибку о том, присвоение не может быть выполнено из-за того, что типы разные. Вообще уберите все неявные преобразования типов!

typedef int mytype;

int a;
mytype b;

int main()
{
  a = b;

  return 0;
}

void fn (int a, int b, int c)
{ ... }

int main()
{
  fn(a=3, c=5, b=4);

  return 0;
}

1. Сильная типизация.

https://github.com/foonathan/type_safe ?

2. Значения по умолчанию для аргументов функций.

А вы вообще пробовали изучить C++ прежде чем что-то от него хотеть? ;)

4. Убрать явное указание итераторов в стандартных алгоритмах. Чтобы вместо sort(v.begin(), v.end()) можно было делать sort(v). Раздражает лишняя писанина.

Ranges обещают в C++20.

5. Чтобы в объявлении функции можно было явно задавать, какие исключения она может бросать, а если она будет бросать не те исключения, то на этапе компиляции выдавалась бы ошибка.

Это вам в Java. Там хотели, но нешмогли, пришлось приделывать костыль в виде RuntimeException. А в современных языках на базе JVM от checked exceptions отказались. В том числе и потому, что это плохо дружит с обобщенным программированием.

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

1. ...

Это называется синоним типа, и сильная типизация такие допускает. Но да, я понял, ты хочешь newtype из хаскеля.

2. Значения по умолчанию для аргументов функций.

Точно есть, и давно

4. Убрать явное указание итераторов в стандартных алгоритмах. Чтобы вместо sort(v.begin(), v.end()) можно было делать sort(v)

Уже есть или скоро будет в новом стандарте

6. Полноценный язык макросов/кодогенерации. Например, чтобы, допустим, в цикле можно было бы создать N переменных a0 ... aN, притом N задается параметром.

Создай массив :)

Как минимум пункт 1 сломает совместимость. Пункт 4 можно сделать и в текущем варианте Си++.

Ну сделай себе в нём инфиксную нотацию или возьми готовую, ты ж сам за это топил.

Не обязательно эта pragma должна распространяться на все тексты.

JavaScript что ли?

Не вижу никаких прагм в приведенном примере.

Наверное речь шла о том, чтобы добавить новую прагму к https://gcc.gnu.org/onlinedocs/gcc/Pragmas.html

1. Сильная типизация.

Как минимум пункт 1 сломает совместимость.

Можно ввести «in-code параметры компилятора». Понятно, что компиляторы разные, но стандарт мог бы определить разные «режимы» для компиляторов и сделать возможность задавать это в коде.

4. Убрать явное указание итераторов в стандартных алгоритмах. Чтобы вместо sort(v.begin(), v.end()) можно было делать sort(v)

Пункт 4 можно сделать и в текущем варианте Си++.

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

1. Вообще уберите все неявные преобразования типов!

Просто иди в жопу.

2. Значения по умолчанию для аргументов функций.

Всегда были.

3. Явное задание аргументов при вызове функций.

Опиши, как это должно совмещаться с перегрузкой функций.

4.

Над этим давно работают.

5.

Даже Java-макаки признали, что Checked Exceptions (или как там) — это тупиковый путь. Но нет, необучаемые хотят притащить это в C++.

7.

Для этого не хватает только char8_t

Возможно что-то забыл.

Что тебя никто не спрашивал.

Я знаю, что такое прагма.

А прима?

2. Значения по умолчанию для аргументов функций.

Точно есть, и давно

Значит я проспал. Ура!

4. Убрать явное указание итераторов в стандартных алгоритмах. Чтобы вместо sort(v.begin(), v.end()) можно было делать sort(v)

Уже есть или скоро будет в новом стандарте

Когда писал, перепроверял на cppreference.com. Знать бы когда это появится.

6. Полноценный язык макросов/кодогенерации. Например, чтобы, допустим, в цикле можно было бы создать N переменных a0 ... aN, притом N задается параметром.

Создай массив :)

Ну ты же понимаешь о чем я.

Это вам в Java. Там хотели, но нешмогли, пришлось приделывать костыль в виде RuntimeException.

Потому что все исключения явно нужно было бы прописывать. А если бы можно было прописывать «эта функция может бросать всё то, что бросает foo и bar, и ещё вот это», глядишь, и взлетело бы. Так что это связано больше не с самой идеей, а с убогой реализацией.

~~@~~

Можно ввести «in-code параметры компилятора»

Зачем эти сложности? Аналог newtype уже можно сделать, тебе даже дали ссылку на готовую либу. Пользуйся хоть сейчас, или она тебя чем-то не устраивает?

у C есть

при чем здесь С? Ты статью читал?

Но автор, то не указал путь реализации первого пункта.
Вот и предложил.

ты говоришь это регистранту с ником «мастер костылей»

6. Полноценный язык макросов/кодогенерации. Например, чтобы, допустим, в цикле можно было бы создать N переменных a0 ... aN, притом N задается параметром.

Создай массив :)

Ну ты же понимаешь о чем я.

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

Если N известно на этапе комплиляции, то можно добиться, чтобы квази-переменные a[0] ... a[N] вели себя «настоящие» переменные a0 ... aN. То есть в машкоде не останется ни массивов, ни циклов для обхода по ним, всё будет сделано эффективно. Ты же этого хотел? Или для чего тебе такая кодогенерация?

1. Сильная типизация.

https://github.com/foonathan/type_safe ?

Просмотрел. Да, очень похоже. Может даже попробую там, где это будет нужно.
Спасибо.

2. Значения по умолчанию для аргументов функций.

А вы вообще пробовали изучить C++ прежде чем что-то от него хотеть? ;)

Мне уже указали что это есть.
И вот я не пойму, почему я это упустил....

5. Чтобы в объявлении функции можно было явно задавать, какие исключения она может бросать, а если она будет бросать не те исключения, то на этапе компиляции выдавалась бы ошибка.

В том числе и потому, что это плохо дружит с обобщенным программированием.

Можно подробней? Это просто еще одна compile-time валидация, которую можно задавать, а можно не задавать.
Use case: модифицируешь функцию, добавляешь throw с новым типом исключения, а catch забываешь для него добавить. И узнаешь об этом только когда программа вылетает. А если это еще и случается нечасто...

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

Матчасть никогда не вредно подтянуть. А такое вот общение это ускоряет.

Можно подробней?

Попробуйте написать шаблонный for_each или accumulate в присутствии спецификации исключений. Может быть сами поймете.

Когда писал, перепроверял на cppreference.com. Знать бы когда это появится.

Для нетерпеливых есть https://github.com/ericniebler/range-v3 Вроде как даже с сегодняшнего дня VC++ 15.9 будет это уметь собирать.

А так в C++20.