- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
function make_json($array){
$json = '{';
$pairs = array();
foreach($array as $key=>$val){
if (!is_numeric($val)) { $val = "'{$val}'"; }
$pairs[] = "{$key}: $val";
}
$json .= implode(', ', $pairs);
$json .= '}';
return $json;
}
(c) json_encode()
- "Кодировка, в старых версиях" - ответ бывалого)))
Удобные библиотеки завезли, не завезли удобного способа их подключать.
Жопа начинается, когда системы сборки либы и твоего проекта не совпадают... Вроде и либа есть, а поюзать - хуй.
Их нынче только для hello world юзают, не переживай...
> инклудгарды
А в чём там магия? После первого втыкания куска текста тупо взводится переменная и второй раз этот кусок уже не втыкается. Если имена этих переменных не повторяются - никаких проблем с гардами нету.
Да ну ладно) Их много где юзают. Просто вместе с autoconf всякими.
Короче в сишечке реализовать модульность можно, но вручную, с бубном, но можно же.
>>А в чём там магия?
Да я не в том смысле что это магия, а в том что это бесконечно прекрасно.
Потому что у пыховцев до сих пор нет красивого способа переиспользования кода за пределами фреймворка
Это называется "используют autoconf", и не вместе, а вместо. То что система сборки генерирует мейкфайлы - это детали реализации.
важно что ./configure && make работает
и пофиг кто писал мейк файл -- программист или скрипт
Тебе ниже уже объяснили что проблема не решаема нигде.
Что значит не решаема нигде? В любом пистоне/раби/жабе можно в setup/гемфайле/pom.xml написать, какие библиотеки каких версий тебе нужны, и всё будет автоматом загружаться и устанавливаться. Написал пару строк в конфиге — можешь юзать либу. В go вообще можно тупо импорт написать, сборщик последнюю версию скачает из интернета.
С сишкой в 99.9% случаев нужно будет вендорить и писать собственный билд под каждую зависимость.
А теперь прокрути на три сообщения ниже и почитай про psycopg в питоне и про jar hell в джаве с кучей разных juit в classpath.
То, что софт становится трудно переносить, если вдруг приходиться вляпаться в сишку, не означает, что 99% остальных либ не работает как надо.
Но не нужно. Сначала все сорцы конпелируют, а потом скопом линкуют - зависимостей нет.
phar, composer?
Потом сделать #include<libудобнаябиблиотека.h>
и потом передать сборщинку -lудобнаябиблиотека
?
В винде.
Ну и мейнтейнеры дистриба не всегда положат тебе нужную версию удобной библиотеки.
В таком случае никакой ЯП не решает приведенных тобою проблем.
А потом расскажи как он "поставит в независимо от дистрибутива".
Мавен, градл, зависимости, никакого нативного кода.
А знаешь что бывает когда у тебя три либы зависят от трех разных junit?
У тебя в класс пасе оказывает три разных junit. Догадываешься что потом бывает?
Класс пас - говно. Как и любая другая идея о path (path, library path, inclede path и т.п.).
Не оказывается. maven/gradle и прочие смотрят весь граф зависимостей и выбирают одну версию каждой либы. Если у тебя в classpath оказалось три разных версии — ССЗБ.
У проблем с установкой на венду postgres-клиента питона и какого-нибудь lxml одинаковый источник — отсутсвие возможности нормально переиспользовать сишные библиотеки, на которых основаны змеиные реализации.
Скорее всего не сильно.
Переписали уже и не раз:
http://python.projects.pgfoundry.org/
https://pypi.python.org/pypi/pg8000
Никаких системных либ не надо. Замеры производительности искать лень, но на исходя из здравого смысла должно быть пофигу, ибо сеть.
Зато в теории в пистоне можно более удобную асинхронную версию драйвера написать.
Ну психопг2 вроде как умеет несколько параллельных запросов по одному сокету (что подразумевает неблокирующие запросы). Так что на нём тоже можно асинхронную версию слепить.
Это конечно не проблема, потому что есть системы сборки, которые сами все найдут и в опции компилятора добавят, но ты об этом не сказал. Мне почему-то кажется, что ты на практике не делал сборку для чего-то крупнее хеловорлда.
Мне почему-то кажется что ты на ЛОРе начитался что "сишечка говно" и повторяешь эту чушь как попугай
Не просто говно, а говно, которое генерит говно на основе говна сгенерённого говном, генерящее говно на основе говна...
З.Ы. Но более переносимого говна, чем автоконф, походу, не существует.
После чего make install все сама делает: и компилит с правильным include и линкует и маны инсталлирует.
Такая же есть для портов.
Разумеется, работает только на той ОС, для коей сделано: не переносимо даже между openbsd и freebsd
Причём редкостное.
> убунточке
А в штабильном дебьяне вообще какое-нибудь говно 5 летней давности будет лежать вместо ожидаемой версии...
Более того, в разных релизах бубунточки пакеты могут называться по-разному или иметь разную структуру. Например, в новом релизе кто-нибудь может решить разбить один пакет на 2 или 3. Мы писали софт под определённый дистрибутив и платформу, и всё равно огребали кучу работы каждый раз при миграции на новый LTS.
autoconf/cmake может помочь найти хедеры и собранные либы, но до этого их надо, очевидно, собрать и установить. Если пишешь какой-нибудь опенсорс, это норм, пакетные менеджеры разрулят.
А если хочется герметичных и воспроизводимых сборок — только вендоринг и написание собственных билд-скриптов для каждой зависимости.
Расскажи поподробнее.
Меня удивляет как в 201х можно написать софт непортируемый между убунтами.
Всё-таки интересно услышать реальные примеры.
За примерами к Роману
Ну слушай, между LTSами вполне может случиться чото: например могут openssl заменить на libressl или хедеровые файлы могут переехать
sudo apt install openssl
Или какой толк от этой убунты? Проще тогда на слаке сидеть и в билд-скрипте херачить для каждой нужной либы
>хедеровые файлы могут переехать
Тут да.
Скачивают порты у BSD и всякие арчи/генты
Вишь, отдельно сырцы
https://slackbuilds.org/repository/14.2/desktop/mcwm/
Даже тут написано
https://slackbuilds.org/howto/
Next, download the source of the application
Как ты думаешь -- почему?
Если sha другое значит там что-то испортили.
А если там наживую меняют код в этом таге -- тогда как-то не очень стабильно
Или мимо пробежит телеграм.