LINUX.ORG.RU

Баш, питон... А исполняемые C++ сорцы с шебангом видали? :)

 ,


2

8
$ cat ~/bin/hello.cpp 
#!/usr/local/bin/build-n-run
#include <stdio.h>
int main() {
    puts("Hello world!");
}

$ hello.cpp 
Recompiling...
Hello world!

$ hello.cpp 
Hello world!

Этот самый /usr/local/bin/build-n-run тоже написан на C++ с использованием std::experimental::filesystem, и он не сильно длиннее эквивалентного баш-скрипта. Собственно работа с путями даже короче. Кому сорц? :)

Отныне в гробу я видал этот ваш баш.

UPD: Сорцы: https://github.com/dimgel/cpp-linux-scripts

★★★★★

Последнее исправление: dimgel (всего исправлений: 1)

Ответ на: комментарий от Virtuos86

что я хочу добавить, так это не-шаблоны. обычные С++ шаблоны есть зло, провоцирующее людей писать говнокод.

по моему мнению, от шаблона требуется лишь подставить тип вместо его обозначения и всё.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

Первое - ты разумно критикуешь убожество шаблонов, которое работает через генерацию функции, хотя подобное уже давно протухло. На это всё.

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

Неверно. Начали писать нормальные интерфейсы, а т.к. ничего другого нет - используется то, что есть. У тебя выбор - жрать дерьмо, либо пытаться. Ты выбираешь первое?

Как в кресты завезут нормальные средства, то все выкинут эти убогие недошаблоны. Да и уже давно выкидывают где могут. Но проблема остаётся - ничего другого нет.

anonymous
()
Ответ на: комментарий от no-such-file

Тот же самый make,

Ничего подобного: make тяжёлая универсальная вещь, а у меня крошечная утилита под конкретную задачу. JFYI: прикручивание комбайна на каждый чих вместо написания 20-ти строк называется «паттерн фрейморкинг».

только кривой и неудобный.

В чём кривость и неудобство?

dimgel ★★★★★
() автор топика
Ответ на: комментарий от ckotinko

по моему мнению, от шаблона требуется лишь подставить тип вместо его обозначения и всё.

Странные у тебя представления, слабые. Как я уже писал выше - проблема шаблонов не в том, что они шаблоны, а в том, что им нету альтернативы. Если её дашь, то это одно, а если нет - ты просто неосилил.

anonymous
()
Ответ на: комментарий от ckotinko

обычные С++ шаблоны есть зло, провоцирующее людей писать говнокод.

Если погромистам дать что-то функциональнее каменного топора и мотыги, они тут же начнуть писать говнокод на нем, потому что это их обычное времяпровождения. Некоторые особо охочие и с помощью мотыги говнокодят (сишные макросы).

по моему мнению, от шаблона требуется лишь подставить тип вместо его обозначения и всё.

Это ты про генерики, что ли?

Virtuos86 ★★★★★
()
Ответ на: комментарий от anonymous

Как в кресты завезут нормальные средства, то все выкинут эти убогие недошаблоны.

Что понимается под нормальными средствами? Мне приходит в голову ближайшая альтернатива из managed-мира - generics. Но если их прикрутят к плюсам, то они будут работать только для динамических объектов (т.к. у автоматических размер произвольный), и возможно ещё и общий базовый класс для них для всех потребуется. Очевидно, что шаблоны это не заменит, они останутся для своих юз-кейсов.

В общем, зря вы на шаблоны бочку катите. Всего-то надо помнить, что они генерируют дубликат функций на каждый тип. Далеко не самое сложное для запоминания. А говнокод можно написать на чём угодно; в тех же плюсах дофига гораздо более заумных ловушек.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от Virtuos86

кывт = rsdn в русской раскладке

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

Что понимается под нормальными средствами?

Ты там на С++03 пишешь?

Шаблоны используются для написания логики в овер 80%, а «подставить тип» - это колхоз. Для написания логики существует нормальный язык, а не это убожество.

Для работы со значениями шаблоные уже давно нахрен не упали - есть constexpr. Это то ещё убожество, но всё же.

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

Добавляют те же концепты, которые и будут являться логикой на безе типов. В будущем будет рефлексия, где типы будут некими компилтайм-объектами, что даст возможность в нормальном виде получать их свойства и строить логику на базе этого.

Мне лениво всё это описывать. Это очевидные для любого вещи, естественно, если он использует С++ в нормальном виде, а не в виде С/С++.

Всего-то надо помнить, что они генерируют дубликат функций на каждый тип.

Это так же одна из проблем. В рамках базовой логики у тебя класс существует всегда, а в рамках этого убожество - класса не существует до его явного инстанцирования и это никак нельзя изменить.

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

Но почему не инстанцируются шаблоны, для которые определены все типы - вот это загадка и это полная невменяемость.

anonymous
()
Ответ на: комментарий от anonymous

Добавляют те же концепты, которые и будут являться логикой на безе типов.

Я в концепты не вникал, но насколько помню, там суть в том, что используются некие общие свойства группы типов, или вводится некое ограничение на группу типов. Т.е. в отличие от тех же жава-генериков, которым в общем случае вообще любой тип можно подсунуть, здесь множество хаваемых типов будет жёстко ограничено. А если объекты будут передаваться/храниться по значению, то ограничение будет касаться и размера объекта, т.е. фреймворку не подсунешь юзерский подкласс фреймворкового класса, если подкласс объявляет дополнительные поля. Так, не так?

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

Фундаментальное неверно. Я не знаю как там в колхозе, но для меня не существует тех определений, которые я слышу из колхоза.

У любого компилируемого(да и не только) языка есть две фазы - компилтайм и рантайм. Дак вот, нет смысла смешивать их вместе, делать статический компилтайм/рантайм и выдавать это за статический язык.

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

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

Т.е. ты можешь написать obj.a = 123, хотя до этого - поля a не было. Оно добавится и изменит тип obj.

Ты это не можешь сделать в рамках статического компилтайма, в тех же крестах, которые со своим odr просто мусор мусорный. Хотя - этому ничего не мешает.

Ты можешь написать struct obj_t{}; obj_t::a = 123 и это точно так же будет работать в компилтайм контексте.

На фазе компиляции этот obj_t соберётся в конечный тип, и он будет статическим. Именно в этом случае ты можешь побороться с динамическим языком.

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

anonymous
()
Ответ на: комментарий от dimgel

https://github.com/dimgel/cpp-linux-scripts

на C++ с использованием std::experimental::filesystem, и он не сильно длиннее эквивалентного баш-скрипта. Собственно работа с путями даже короче.

В четыре раза длинее как минимум

[d_a@work tmp]$ cat CxxRun 
#!/bin/bash -e

if [[ $# -lt 2 ]]; then
    echo "Usage: $0 <Cxx> [CxxArgs] <SourceFile.cxx>" >&2; exit 1
fi

sourceFile=$(readlink -e "${@: -1}")
cxxCommandLine=${@:1:$#-1}
targetFile=~/.cache/CxxRun${sourceFile%.*}

if [[ ! -x $targetFile ]] || [[ $targetFile -ot $sourceFile ]]; then
    mkdir -p "$(dirname "$targetFile")"
    sed -e '1s|^\(#!.*\)$|// \1|' "$sourceFile" |\
        $cxxCommandLine -o "$targetFile" -xc++ -
fi
exec "$targetFile"

[d_a@work tmp]$ cat X.cpp 
#!/usr/local/bin/CxxRun g++ -std=c++11 -Wall -Wextra
#include <iostream>

int
main(int argc, char *argv[])
{
    std::cout << "Hello world\n";
    return 0;
}

[d_a@work tmp]$ ./X.cpp 
<stdin>:5:1: warning: unused parameter ‘argc’ [-Wunused-parameter]
<stdin>:5:1: warning: unused parameter ‘argv’ [-Wunused-parameter]
Hello world

PS. man ccache, man make, весь твой проэкт скручивается до make X && ./$_ (ибо implicit rules).

d_a ★★★★★
()
Ответ на: комментарий от d_a

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

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

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

Нет, не так. Концепт это такой же шаблонный тип, только с ограничениями. Если у тебя нет ограничений на размер - у тебя нет проблем.

Поставишь ограничения на интерфейс - примет любой тип с нужным интерфейсом. Поставишь ограничение на baseof - примет любой тип с нужной базой.

anonymous
()
Ответ на: комментарий от anonymous

Нет, не так. Концепт это такой же шаблонный тип, только с ограничениями. Если у тебя нет ограничений на размер - у тебя нет проблем.

Но тогда для типов с разным размером опять-таки будут инстанциироваться дубликаты функций. Где профит?

dimgel ★★★★★
() автор топика
Ответ на: комментарий от m0rph

Да даже (прости господи) для PHP. :) Хотя встроенная фича для компилируемого низкоуровневого - это прикольно.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

Во-первых, bash -e, а во вторых не забудь реализовать пайп в gcc и удаление шебанга тоже на крестах.

d_a ★★★★★
()
Ответ на: комментарий от d_a

не забудь реализовать пайп в gcc и удаление шебанга тоже на крестах.

Маньяк и демагог детектед: ты сам-то всегда свои программы только на одном языке и с одним инструментом пишешь? Чего б тебе тогда из своего скрипта realpath и sed не убрать, они к башу отношения не имеет.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от d_a

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

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

А кто тебе сказал, что профит в этом?

Штука в том, что у нас типизированный язык, но. Что такое шаблоны? Это не типизированная пасте препроцессора. Я думаю, что плюсы типизации тебе разъяснять не нужно?

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

Профиты - перегрузки, нормальные ограничения на типы, нормальное обобщение типов.

Попробуй без тыщи кастылей забабахть sort(vector) и поймёшь проблемы.

Профит идёт и на уровень удобства разработки. Когда у тебя есть некий интерфейс для типа, то ты можешь статически для него получить информацию. Это позволяет и реализовать нормальный комплишн, проверки статический, ошибки. И прочее и прочее.

anonymous
()
Ответ на: комментарий от anonymous

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

dimgel ★★★★★
() автор топика

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

ugoday ★★★★★
()
Ответ на: комментарий от dimgel

Демагогией занимаешься ты, пытаясь притянуть за уши свой неудачный выбор инструмента (C++ для управления внешними процессами).

d_a ★★★★★
()
Ответ на: комментарий от d_a

Балабол. coreutils, как и любой другой бинарник - не имеет никакого отношения к башу, как и аргументы. Он мог с тем же успехом дёрнуть exec, либо сискол.

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

То же самое с ccache. Ты сел в лужу с перекомпиляцией и решил его закидать базвордами, одновременно с оправданием своей несостоятельности.

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

anonymous
()
Ответ на: комментарий от d_a

Неверно. Хотя я уже об этом писал - напишу ещё раз. Ты пытаешься подменять понятия, а именно - у тебя не получилось зайти с баша, ты съехал на make, но make - это такой же С++, а вернее си. Если си не подходит - ты помножил себя на ноль.

В конечном итоге - ты пытаешься сравнивать готовое дерьмо, которое имеет реализацию на си, с его реализацией на С/С++. Если ты сравниваешь реализацию - сравнивай реализацию.

Да и чего вообще ты в контексте баша запел про make, ccache? Какое они имеют отношения к башу?

anonymous
()
Ответ на: комментарий от anonymous

То же самое с ccache. Ты сел в лужу с перекомпиляцией и решил его закидать базвордами,

ccache у меня на генте стоит. А на базворды мне плевать. :)

одновременно с оправданием своей несостоятельности.

Да ну, нормальный скрипт он нарисовал. С кучей непонятных закорючек (я только sed осилил), из-за которых баш и ругают, но ежели он в нём сечёт, то и флаг в руки.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от t184256

Я его пытаюсь заэмбединдить в свою многопоточную graph-based систему задач, как один из скриптовых языков помимо python (будет собирать библиотеки из плюсовых нод, исходя из статистики среднего времени выполнения и количество срабатываний). Для прототипирования, дебага участка кода, JIT вещей. Если хорошо знаешь метапрограммирование, то можно, в теории, любой compile-time(ct) код, которым нужны ct параметры запустить в рантайме (тут короче должен быть написан мелким шрифтом дисклеймер по поводу скорости компиляции шаблонной лапшы).

maxis11
()
Ответ на: комментарий от Pinkbyte

Не, на самом деле я просто хотел в порядке отдыха пощупать std::filesystem. :)

dimgel ★★★★★
() автор топика
Ответ на: комментарий от maxis11

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

t184256 ★★★★★
()

конечно видели..

откройте для себя мир - C/C++ может сосуществовать даже во многих языках, прямо в виде сорца, который откомпилиться, закешиться и будет исполнен при небходимости. То есть «прощай bash» можно (но ненужно) сказать и про lisp и про tcl и про всё что угодно..

просто bash в своей области в сотни раз эффективнее про компактность, распространённость и понятность

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

откройте для себя мир

Когда? :( Работать надо. :)

dimgel ★★★★★
() автор топика
Ответ на: комментарий от Virtuos86

генерики это такое же зло, только вид сзади.

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

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

генерики это наоборот попытка все считать в рантайме

У тебя довольно странное понимание генериков. Кроме Java/C#, есть и другие языки.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Баш не нужен. И тем более сишка. Скрипты нужно на питоне писать

Мнение умного человека. Ну а я просто скромно присоединюсь к нему :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Мнение умного человека. Ну а я просто скромно присоединюсь к нему :)

Тонко. :) И ник хороший. :)

dimgel ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.