LINUX.ORG.RU
ФорумTalks

C++ - некошерно, C - кошерно. Почему?


0

0

Решил тут поднять свой левел знания С/С++ дальше понимания синтаксиса и пр., т.к. с Pascal'ем в моем городе дальше хобби не "уехать" по всей видимости :) Ну и собственно начал практиковаться, переводя один свой проЭкт на С. Почему-то расстроило отсутствие аргументов по умолчанию, с трудом привык к работе со строками и пляскам вокруг ручного контролирования выделения под них памяти и т.д. Свыкся с разбивкой модулей на *.c/*.h(даже проникся)... в общем ладно, отошел от темы немного ) Хотел поинтересоваться, какие реальные аргументы на тему "С++ - УГ" можно привести? :) И будет ли извратом/некошерно использовать C++ не прибегая к использованию классов/STL/etc.?

ЗЫ: давно подобных тредов не было, лень искать старые.

★★★★

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

> посмотрите как нибудь на MS Visual C++ и Visual Assist и после этого вам станет стыдно, что вы подняли тему IDE, особенно что касается скорости работы

Смотрел. Ужос десятилетней давности.

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

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

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

>Зато не жрут полгига оперативы и не тормозят при просмотре менюшек.

Угу - это самые полезные фишки для приложений класса Computer Aided Engineering. Главное чтобы памяти поменьше занимали.

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

>посмотрите как нибудь на MS Visual C++ и Visual Assist и после этого вам станет стыдно, что вы подняли тему IDE, особенно что касается скорости работы

Всегда когда имел дело с MSVC++ по мере того как разные тестовые кусочки начинали склеиваться в нечто более серьезное MSVC++ постепенно деградировал до нотепада с деревом файлов и подсветкой синтаксиса. Рантаймово анализировать код на С++ невозможно и пытаться делать для этого тулчайн даже обладая ресурсами MS это пустая трата времени и денег.

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

> Ну речь AFAIU шла о том что рефакторить код с динамической типизацией ужасно тяжело.

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

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

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

По моему так наоборот разобраться в коде deluge раз в пять проще чем в коде linuxdcpp.

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

> вы Visual 2008/2010 посмотрите ;)

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

Да конечно как стали плуги писать на .NET так сразу функционал появляться стал.

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

Кстати, раз уж тут все равно о пистоне говорят.. Опять его начал ковырять. А как подобные вещи отлавливать?

class Test1:
    def __init__(self, s):
        self.str1 = s
        
    def f1(self):
        print self.str1
                
if __name__ == "__main__":
    test = Test1("Hello")
    print("without par.")
    test.f1
    print("with par.")
    test.f1()

% ./test.py
without par.
with par.
Hello

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

> Угу. .NET в полный рост
> ReSharper


LOL, с чего вы вдруг на ReSharper и другое начали кивать? в Visual кроме С++ много чего поддерживается, но опять же причем тут это?

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

> По моему так наоборот разобраться в коде deluge раз в пять проще чем в коде linuxdcpp.

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

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

> А как подобные вещи отлавливать?

ну это скорей всего тот самый костыль pylint и подобные отловят

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

> А как подобные вещи отлавливать?

Ты что сказать-то хотел? Что забываешь при вызове скобки ставить? Такое никак не отлавливается.

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

> Такое никак не отлавливается

тоесть все эти костыли они вообще даже как-то слабо подпирают ... тогда вообще жопа в пистоне ...

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

>А как подобные вещи отлавливать?

А тут ошибок нет - он сделал именно то, что ты попросил:

>>> def f(x):
...     print x

>>> f(1)
1
>>> x = f
>>> x(1)
1


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

>в Visual кроме С++ много чего поддерживается, но опять же причем тут это?

Ты наверное не смотрел сколько оно жрет и на чем плугины написаны - да? Или решил доказать крутость C++ плугинами на С#?

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

> Что забываешь при вызове скобки ставить?

Я на днях забыл поставить скобки при ковырянии PyGTK и некоторое время недоумевал :)

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

>> По моему так наоборот разобраться в коде deluge раз в пять проще чем в коде linuxdcpp.

>а по-моему в deluge используют пистон абсолютно не по назначению ... не предназначен пистон для написания таких программ и изначально не разрабатывался ...

А это тут причем? Давай сравним код linuxdcpp (C++, write-only) и deluge (Python, отлично структурировнно и читаемо) и придем к верному выводу что ты лжешь. Такие дела.

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

> Ты наверное не смотрел сколько оно жрет и на чем плугины написаны - да?

открыты 20 больших проектов - "жрет" 61Мб памяти, удивлены?

> Или решил доказать крутость C++ плугинами на С#?


ну LOL же, VisualAssist написан на С++, другими не пользуюсь

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

> Я на днях забыл поставить скобки при ковырянии PyGTK

Ну конструкция f; вместо f(); допустима и в Си. Правда, в Си наверняка есть какой-нибудь варнинг, но включен ли он по умолчанию...

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

> А это тут причем? Давай сравним код linuxdcpp (C++, write-only) и deluge (Python, отлично структурировнно и читаемо) и придем к верному выводу что ты лжешь. Такие дела.

дык пистон это по-определению write-only, ну на С++ тоже можно так написать программу, да ... но можно и по-пнормальному ...

ЗЫ: код ни того ни другого не видел

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

> открыты 20 больших проектов - "жрет" 61Мб памяти, удивлены?

открыт один большой проект, жрет 173 Мб, без всяких Visual Assist-ов

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

а не - гоню ... это солюшн один, а проектов 34 в нем

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

> тоесть все эти костыли они вообще даже как-то слабо подпирают ... тогда вообще жопа в пистоне ...

А в С празник каждый день:

#include <stdio.h>
int main(int argc, char ** argv) {
        int a = 2;
        int * x = &a;
        (*x)++;
        printf("%d\n", a);
        x++;
        printf("%d\n", a);
        return 0;
}

я правильно понимаю?

Или в С++:

#include <iostream>

using namespace std;

class E
{
};

void m() {
     throw new E();
}


int main(void) {
   try {
           m();
   } catch (E e) {
         cout << "aga!!" << endl;
   } catch(...) {
         cout << "oheret' mlia" << endl;

   }
  return 0;
}

праздник каждый день! Охрененный язык!

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

>видимо имел в виду нечно другое все-таки

Ты когдла на сях вызываешь функцию с результатом, но ни к чему не присваиваешь - ты что имеешь ввиду?

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

только запущенный без проектов - 20Мб
с одним открытым проектом - 26Мб
// голый VS2008 С++ без установленной поддержки C# и прочего

предыдущая цифра( 61Мб ) была для 2005 + VA

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

> открыты 20 больших проектов - "жрет" 61Мб памяти, удивлены?

Вранье. Не знаю что ты называешь большими проектами - но у меня проекты на диске больше занимают. А у тебя большой проект это 61 / 20 =~3 мб?



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

>праздник каждый день! Охрененный язык!

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

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

> Вранье. Не знаю что ты называешь большими проектами - но у меня проекты на диске больше занимают. А у тебя большой проект это 61 / 20 =~3 мб?

дурачек, ты искренне считаешь, что все файлы проекта постоянно находятся в памяти?

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

>> Вранье. Не знаю что ты называешь большими проектами - но у меня проекты на диске больше занимают. А у тебя большой проект это 61 / 20 =~3 мб?

>дурачек, ты искренне считаешь, что все файлы проекта постоянно находятся в памяти?

Для комплишенов надо ast-дерево в том или ином виде в памяти держать.

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

ну а в пистоне надо постоянно catch TypeError- ы расставлять, тоже весело, да ...

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

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

> Ты когдла на сях вызываешь функцию с результатом, но ни к чему не присваиваешь - ты что имеешь ввиду?

имею в виду что результат мне не нужен

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

>> попробуйте сделать и использовать шареную библиотеку на C и на C++ и ответите для себя на один из важных вопросов.

> писали, пользовали - может объясните? а то не очень понятно, что у вас за трудности были

Да, а кстати как вызываете методы классов - напрямую или заворачиваете методы в extern C?

У меня трудностей не было, потому что я не использую C++ ;-)

Мое знание о проблемах основывает на сообщениях о проблемах других людей.

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

google:Binary Compatibility of C++ shared libraries on GNU/Linux

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

>дурачек, ты искренне считаешь, что все файлы проекта постоянно находятся в памяти?

Я искренне считаю, что любой ассист должен делать индекс символов, и этот индекс - немаленький.

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

> Это еще не все - вот когда определенная комбинация символов была прочитана как триграф и в результате поменялась семантика - это уже интереснее

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

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

>за адресную арифметику и возможность взять адрес С++ и любят, потому что он достаточно низкоуровневый ...

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

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

>имею в виду что результат мне не нужен

вот f - возвращает ссылку на функцию. Хто ж виноват, что результат по коду тебе не нужен.

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

> В далеких 8х может и нуждно было - а сейчас большинство этих вещей нафиг не нужны

согласен ... сейчас есть куча библиотек ...

> А указатели на интежеры с адресной арифметикой и отсутствие нормальных строк - это бредятина

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

> Потмоу все с ней и воюют разными обрерточными либами типа Qt.

оберточные либы и у каждого свой класс строк - это костыли, да

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

>> Это еще не все - вот когда определенная комбинация символов была прочитана как триграф и в результате поменялась семантика - это уже интереснее

>ой - не надо передергивать ... ну пережиток прошлого, да ... пистон столько не проживет сколько С, ему такое не грозит ...

Ты не путай хороший, годный кроссплатформенный ассемблер Си и плохой, негодный высокоуровневый язык выехавший на совместимости с Си (С++)

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

>> имею в виду что результат мне не нужен

> вот f - возвращает ссылку на функцию.

Ну так-то не передергивай. Функция вызывается ради побочных эффектов, а выражение "func" как оператор не имеет смысла ни в Питоне, ни в Си.

Хотя то, что в Питоне на это не выдается варнинг - это недостаток компилятора, а не языка.

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

>про нормальные строки Джоел хорошо писал, что нормальные строки они нормальные до какого-то предела, потом приходится спускаться на уровень ниже,

Вранье. Весь профит потеряется на перефасовке специализированных строк в обычные.

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

> вот f - возвращает ссылку на функцию. Хто ж виноват, что результат по коду тебе не нужен.

просто в С/С++ больше стараются сделать чтобы реально применимо было, кмк. там тоже можно написать

f;

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

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

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

> Ты не путай хороший, годный кроссплатформенный ассемблер Си и плохой, негодный высокоуровневый язык выехавший на совместимости с Си (С++)

ну дык в негодном С++ просто остались эти пережитки прошлого, и все ... тоже не один год существует ведь язык

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

> Хотя то, что в Питоне на это не выдается варнинг - это недостаток компилятора, а не языка.

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

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

> Весь профит потеряется на перефасовке специализированных строк в обычные.

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

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

>Хотя то, что в Питоне на это не выдается варнинг - это недостаток компилятора, а не языка.

Угу. Я имел ввиду что конструкция - корректа. Другое дело, что бессмысленна, как вычисление значения, которое никуда не возвращается.

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

>> Ты не путай хороший, годный кроссплатформенный ассемблер Си и плохой, негодный высокоуровневый язык выехавший на совместимости с Си (С++)

>ну дык в негодном С++ просто остались эти пережитки прошлого, и все ... тоже не один год существует ведь язык

Да скорее наоборот есть вопрос для выбора проектных решений на С++: "надежно ли это будет работать и будут ли неожиданные жопы?". Ответ на этот вопрос примерно такой: "Чем дальше ты отошел от Си-подмножества тем менее это надежно и тем больше подводных камней ты встретишь"

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