LINUX.ORG.RU

Программирование Linux С и С++

 , ,


0

2

Здравствуйте. Можно ли использовать С++ при программировании Linux? Поясню вопрос: в книгах по программированию под Linux примеры на С, я пробовал писать в С++ и вроде работает, но все ли так однозначно? На С++ просто удобнее, имхо, строки, например, обрабатывать и еще ряд «плюшек». Но может есть некие тонкости, о которых я, в силу не опытности не подозреваю? А можно ли часть программы писать на С(file1.c), а часть на С++(file2.cpp) - будет ли такое компоноваться потом?


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

пиши на sh

имеете в виду структурировать программу(преодолевать «недостатки» процедурного программирования) через командный интерпретатор?

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

Если бы Чарльз Дарвин был глубоко верующим человеком, как бы это повлияло на биологию? Примерно так же как мнение Линуса Торвальдса относительно того или иного языка программирования ;)

Всё что я считал нужным посоветовать - я сделал. Удачи!

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

нет.

используй sh|bash|rc - как средство первого выбора

зы. python за его из коробки структуры данных.

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

Может все эти fork() и в С++ есть и не надо замудряться

1. Если ты передал ссылку на функцию-обработчик (куда-то-там) — то просмотри документацию — вдруг внутри обработчика тебе разрешено использовать лишь только async-safe-функции (в этом случае C++ будет для тебя слишком грубым)

2. Обрати внимание на функциональность setjmp/longjmp — если ты пишешь код который участвует в этом — то C++ тебе только ноги простреливает

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

Освежите свои знания. Qt бесплатен(ака lgpl) для комерции.

https://www.qt.io/faq/

Which parts of Qt are licensed under LGPLv2.1? Most of the libraries in the Community version (Qt Free Edition) are available under LGPLv2.1 and LGPLv3. Some of the libraries are only available under LGPLv3, these currently are Qt Location, Qt 3D, Qt Canvas 3D, Qt WebView, Qt Quick Controls and parts of Qt WebEngine.

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

но чего-то мне кажется в ООП сие поудобнее, чем в процедурном стиле

Процедурный стиль давно уже устарел — пиши в функциональном :-)

А ООП такое же хорошее, как и нассать себе холодную зимой в штаны — сначало хорошо и тепло, а потом ноги замерзают :-) ..

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от eao197

Я не программист по профессии, и зарабатывать «на софте» мне не уперлось. Но ничто не мешает никому это делать, какие проблемы? Linux Foundation уже обеднела?

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

И что? Linux Foundation спонсирует разработку ядра, оно под GPL. Какая разница, кто входит? Разработчики ядра зарабатывают на GPL софте, по миру пока не пошли. Что не так?

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

LGPL таки налагает некоторые ограничения, но да не суть. Раз вы уж сослались на FAQ, то почему бы не взглянуть вот на это:

The license agreement with KDE Free Qt Foundation has been rewritten. With the new agreement, Qt will be licensed under a commercial license, GPLv2, GPLv3 and LGPLv3, but no longer under LGPLv2.1. This affects all Qt development work, starting from now with Qt 5.7 development.

With the new agreement, The Qt Company will open source all the desktop and mobile relevant APIs and tools that were formerly available only under commercial license unifying these two versions of the Qt offering. The existing Qt Essential and Add-on modules will be licensed under commercial, GPLv2, GPLv3 and LGPLv3 licenses. The newly open sourced modules and Qt tooling will be available under commercial and GPLv3 licenses.

Qt for Application Development, our product for desktop and mobile platforms, will be available with identical content under both open source and commercial licenses, i.e. the open source users receive a lot of new functionality.

Qt for Device Creation, our product for embedded platforms continues to be available only under commercial terms. As the licensing of Qt is changing, those using open source Qt for embedded platforms need to check compatibility before migrating to Qt 5.7 or later version.

Я уже слишком старый и помню времена, когда Qt была всего под двумя лицензиями. А дополнительные плюшки (уж не помню, как они назывались) шли только под коммерческой лицензией. Затем, после покупки Nokia, появилась еще и LGPL, т.к. Nokia не стремилась зарабатывать именно на Qt. Но после передачи Qt компании Digia, ситуация вновь поменялась, т.к. Digia жила именно с Qt. И версия под LGPL им несколько мешает. Отсюда и стремление потихонечку возвращаться к всего двум типам лицензий. Понятно, что уже опубликованное под LGPL компоненты уже никуда не денутся. Но вот направление дальнейшего движения уже обозначены.

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

Я не программист по профессии, и зарабатывать «на софте» мне не уперлось.

А вот мне уперлось.

Но ничто не мешает никому это делать, какие проблемы?

«ничто не мешает» чему? Зарабатывать с помощью GPL-софта?

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

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

писать софт не под GPL

Не надо так делать.

Ну, напиши библиотеку под GPL и посмотри будут ли ее использовать.

Кстати, приложения по GPL тоже зло, из них код копипастить нельзя, если твое приложение под LGPL. Так что LGPL рулит даже для конечных пложений (не библиотек).

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

Вы сами за нее платите или ваш работодатель это делает?

В конце концов платит потребитель.

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

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

Это проблемы человеческих пороков и жадности. От поставки другим клиентам под GPL заказчик ничего не потеряет, тем более речь о софте под заказ, для конкретных задач конкретного заказчика. Заказчик веб-сайта почему-то не плачет, что LAMP свободный.

При этом за тот же Qt в разрабатываемом за их деньги продукте они тоже платить не горят желанием? Или Qt не люди пишут, и им зарабатывать не надо? Любишь кататься, люби и саночки возить. Нет, я понимаю, что тот, кто оплачивает разработку, хочет оплатить как можно меньше, а получить как можно больше, но Qt чем тут виноват, и люди, которые его советуют?

curufinwe ★★★★★
()
Последнее исправление: curufinwe (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

вдруг внутри обработчика тебе разрешено использовать лишь только async-safe-функции (в этом случае C++ будет для тебя слишком грубым)

В основе C++ лежит принцип «не платишь за то, чем не пользуешься», поэтому, если тебе нужна на C++ функция, которая работает как сишная, то так и будет (язык сам по себе ничего не добавит). Нужно просто знать, как в C++ реализуется тот или иной функционал.

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

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

В конце концов платит потребитель.

Да это понятно. Qt из GUI фреймворков, по-моему, наиболее удобный. Но у Qt есть две серьезных особенности, которые следует держать в уме как возможные риски:

- во-первых, Qt — это свой обособленный мирок, который базируется на своей библиотеке. Т.е. взять кусок кода, написанного для Qt-шного проекта и вставить в проект, где Qt нет в помине, может быть непросто из-за использования QVector вместо std::vector, QString вместо std::string и т.д. Обратное тоже имеет место быть, хотя там количество геморроя, вроде как постоянно снижается.

- во-вторых, лицензии Qt. Если вас устраивает LGPL или GPL, то все нормально. Если не устраивает, то нужно платить.

Так что совет использовать Qt вполне годен, но при условии понимания этих рисков.

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

Всё что я считал нужным посоветовать - я сделал. Удачи!

спасибо.

надо тему закрывать.

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

Или Qt не люди пишут, и им зарабатывать не надо?

У вас шизофрения? Вы же сами сказали, что разрабатывать не-GPL-ный софт — это плохо. Для разработки GPL-ного софта Qt бесплатен. Соотвественно, на GPL-ном софте разработчики Qt не зарабатывают.

А живут они с того, что кто-то разрабатывает не-GPL-ный софт и платит за коммерческие лицензии. Но ведь это же плохо, писать не-GPL-ный софт. Вы ведь на этом настаиваете?

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