за что не любят сишников?

Ощущение костыля остается из-за того что ты можешь отгрести проблем из-за того что есть доступ к тому как это устроено. В Java/C# ты просто этим пользуешься, выстрела в ногу не происходит и прикладной софт пишется на ура. Это специализированный бизнес софт, ну а всякие обычные десктопные приложения аля плееры и т.д, проще вообще на Python написать чтобы экономить памяти. А системный на С, ну и если без фанатизма, то на С++. Но прикладной софт, состоящий на 95% из бизнес логики иногда пишут на С++, потому страшно жить.

Ну предложи торвальдсу перейти на С++ в ядре, а то си же такой плохой язык, вай вай...

Дык, правильные строки же. Которые «не тормозят!!!111» (с) А самое главное - не текут и... 100500*100500 хватит всем.

В Java/C# ты просто этим пользуешься, выстрела в ногу не происходит

LOL, это ты про Java с ее дженериками? шаблоны в С++ по сравнению с ней - образец прямоты

А что не так? Ну естественно кроме боксинга примитивных типов, это известная вещь каждому джуниору.

проще вообще на Python написать чтобы экономить памяти.

Только выглядят эти приложения как говно, и работают как говно, как правило.

Только выглядят эти приложения как говно

Вы определяете ЯП по внешнему виду? Ощущать Python сквозь Qt/Gtk - Ванга отдыхает

ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Float> lf = new ArrayList<Float>();
if (li.getClass() == lf.getClass()) // evaluates to true
  System.out.println("Equal");

fail

public class Example {
    public void print(Set<String> strSet) { }
    public void print(Set<Integer> intSet) { }
}

fail

List<Integer>[] arrayOfLists = new List<Integer>[2]; 

fail

if (list instanceof ArrayList<Integer>)

fail

и пр. и пр.

Ну правильно, все это знают, erasure. Проблем не вызывает, хотя решение не идеально и является trade off по совместимости. Особенно те кто применяют reflection должны понимать эти подробности. То что может случиться с памятью в С++ просто даже сравнивать с этим нельзя

Ощущение костыля остается из-за того что ты можешь отгрести проблем из-за того что есть доступ к тому как это устроено.

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

В Java/C# ты просто этим пользуешься, выстрела в ногу не происходит и прикладной софт пишется на ура.

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

Это специализированный бизнес софт, ну а всякие обычные десктопные приложения аля плееры и т.д, проще вообще на Python написать чтобы экономить памяти. А системный на С

а на чём ты будешь писать сам пайтон? а сами окошечки для пайтона? (на чём написана Qt? то-то же)

Ну предложи торвальдсу перейти на С++ в ядре, а то си же такой плохой язык, вай вай...

кто сказал, что сишечка - плохой ЯП? уж никак не я.

Ну правильно, все это знают, erasure.

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

То что может случиться с памятью в С++ просто даже сравнивать с этим нельзя

все это знают (с), ручная работа с памятью

за что

За скобки { }, от которых ломаются пикселы в глазах :)

а вот на жабе получается такой кривой былософт

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

А системный на С

а на чём ты будешь писать сам пайтон? а сами окошечки для пайтона?

На С, как я и сказал

все это знают (с), ручная работа с памятью

Ну-ну, не смешиваем, размеры проблемы имеют разные масштабы и стреляют с разной частотой

Умные они, вот и не любят.

нибудь std::vector, или std::string, что ведёт к лишним аллокациям,

Так что там насчёт утечек памяти в С?

За скобки { }, от которых ломаются пикселы в глазах :)

#define begin {
#define end }

не благодари

размеры проблемы имеют разные масштабы и стреляют с разной частотой

ручная работа с памятью - не проблема, это особенность ЯП, вот ООП в С++ примитивнейшее и костыльное - да, хотя правда местами оно и лучше чем в Java

#define begin {
#define end }

За это онафеме предают.

Нет, я не про внешний вид, а про исходный код. Сейчас мне частенько приходится сталкиваться с питонософтом, от простых скриптов до гуйни, частенько даже дорабатывать. В основном это софт для 3д принтера. Так вот.
Там где на С это делается в 200 строк и 1 тред с epoll, на питоне это 3 треда и овер 600 строк (не считая библиотеки), см. эпичный пример miniterm.py из примеров в pyserial.
Быстродействие тут тоже крайне сомнительно. slic3r написанный емнип на плюсах одну и туже тестовую STLку мне слайсит меньше 15 секунд, в то время как питоновый skeinforge более пяти минут. Алгоритмы примерно одни и те же.
А то, что в С можно выстрелить в ногу... как сказать, можно ведь и не стрелять. Пару раз девелопер себе ноги отстрелит - в третий раз поумнеет и стрелять не будет.
Мне еще не довелось встретить хотя бы одно приложение на питоне, которое нормально написано. Как страшненький язык для прототипирования чего-то по-быстрому он катит, но опять таки сомнительно. (java приятнее выглядит в плане кода в разы, логичнее, в библиотеках порядок. Да и сам язык более зрелый, на нем не так часто встречаешь откровенную содомию)
А С, как по мне - как раз и хорошь своим порогом вхождения, потому как не даст над проектом работать совсем уж контуженным идиотам, которые все угробят, хотя их везде хватает.

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

Тут есть уязвимый момент - колеса у коляски сравнительно легко заменить :)

#define begin {

ты совсем не знаешь C:

main() <%%>

так что вон из топика ;)

Там где на С это делается в 200 строк и 1 тред с epoll

epoll

Кулхацкер детектед.

У него ща кое-что разорвёт от таких слов :)

Ты просто не видел обьемы логики которая там есть. Постоянны поток из миллионов транзакций с совершенно мозговыворачивающей логикой должны работать годами.

ага. Теперь расскажи мне про объёмы клиента wuala или азарус(vuze)? для них тоже нужен свой сервер?

На С, как я и сказал

ну да, пайтон на Си, но вот скажем Qt таки на плюсах.

Да ладно тебе... Ну любит человек «все Ъ-асинхронное», что ж теперь.

Он не просто любит Ъ-асинхронное, он еще и любит делать это на специфичном для Linux вызове. Кулхацкер, что с него взять.

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

Не ну серьезно, код на С падает постоянно, тому лучший пример - Линукс десктоп. Постоянно новые версии привносят новые глюки, и все приняли это как данное. Мол новое - unstable. Причем в нормальных ЯП код через время просто становится stable и так уже навсегда, редко что-то ломается. Причем если ломается то не сегфолтом, а какой-то внятной ошибкой

asio, NIH... Ну ты понел

asio

На Си?

Не ну серьезно, код на С падает постоянно, тому лучший пример - Линукс десктоп

А говорили, что Гном стабилен, лол.

А С, как по мне - как раз и хорошь своим порогом вхождения, потому как не даст над проектом работать совсем уж контуженным идиотам, которые все угробят, хотя их везде хватает.

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

А на си еще проще :) Велосипед сам не изобретется... libevent? no way!

Что-то глючит и крешится в любом DE, исключений нет

Ты сам сказал: «код на С падает постоянно».

код на С падает постоянно, тому лучший пример - Линукс десктоп

Даже не знаю, тут бы я грешил на рожу т.е. унылых обезьян девелоперов Гнома.

Что-то глючит и крешится в любом DE, исключений нет

это особенность LInux, к сожалению, сравни с OS X, например

КДЕ, Xfce, MATE, Cinnamon, Unity - все глючат так что не балуйся

KDE ж на Це++. Плюс, хоть прогресс заметен.

Унылое 4.2

Да, на специфичном, потому как он быстрее и проще, а софтина для которой я это сделал будет пахать только на линуксовом эмбеддеде. Это называется «обоснованный выбор». Если бы стояла задача сделать кроссплатформенно - сделал бы другим, и это кстати не слишком было бы больше по коду.

Не ну серьезно, код на С падает постоянно, тому лучший пример - Линукс десктоп. Постоянно новые версии привносят новые глюки, и все приняли это как данное. Мол новое - unstable. Причем в нормальных ЯП код через время просто становится stable и так уже навсегда, редко что-то ломается. Причем если ломается то не сегфолтом, а какой-то внятной ошибкой

Это говорит о качестве софта и выбранном подходе. У тебя часто сегфолтится код в ядре, который проходит нормальный контроль качества?

нормальный контроль качества

Это как?

Не ну серьезно, код на С падает постоянно, тому лучший пример - Линукс десктоп.

у меня не падает. Почему так? может дело совсем не в C?

Причем если ломается то не сегфолтом, а какой-то внятной ошибкой

«внятную ошибку» ты можешь получить и на сишечке. Вот так например:

int array[10];
for(i = 0; i < 10; i++)
{
    if(i < 0 || i >= 10)
       exit(66);
    // тут юзаем array[i]
}

exit(66);

http://en.wikipedia.org/wiki/Magic_number_(programming)

ну и vertexua очевидно имел ввиду, что в его «нормальных ЯП» не надо писать руками такие проверки, более того - он получит полный стек вызовов, т.е. больше информации, backtrace, к сожалению, не часть C и не везде есть

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

http://en.wikipedia.org/wiki/Magic_number_(programming)

к чему это? коды ошибки 1..63 вообще-то за системой зарезервированы. Как и коды 128..255. Вот и остаются 64..127.

ну и vertexua очевидно имел ввиду, что в его «нормальных ЯП» не надо писать руками такие проверки

оберни в макрос, если не хочешь писать.

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

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

Можно сказать «Я упала из-за выхода за пределы массива в строчке mysegfault.c:23, потому что индекс 23, а размер массива 17». И сделать это в любом месте, а не где воткнули макрос. Это не подходит для системного софта, избыточные проверки, потому и едим кактус. А для прикладного так и надо, потому что он пишется согласно быстрых изменений рынка и требований пользователей, нет времени сегфолты исследовать