- codesnip
- Постоялец
codesnip
> Об этом пишут во всех книгах по плюсам в первой главе.
не все книги одинаково полезны :)))
>улучшенная версия языка С, в которой добавлены объектно-ориентированные расширения
ню ню, а потом эти люди начинают писать на с++ как на с
fsmoke,
>>не все книги одинаково полезны :)))
О том что си++ это улучшенный си написано в том числе и в книге Страуструппа если чё.
>ню ню, а потом эти люди начинают писать на с++ как на с
Ну и пусть пишут. Чистый си например в 100 раз легче дебажить и просматривать выполнение программы построчно чем на си++. На си++ это делать очень проблематично. Дебаг ведь очень важен. Потом на плюсах бывает очень сложно понять почему программа не компилится. В си всегда можно понять чё не так.
codesnip
> на плюсах бывает очень сложно понять почему программа не компилится
Тут, я думаю, вполне подходит пословица про плохого танцора и то, что ему всегда мешает
codesnip
> и в книге Страуструппа если чё.
Это он писал чтобы не пугать сишников :))) - основной его задачей было приучить людей пишущих на чистом с к объектноориентированности(как он сам говорил об этом) - на деле же это совершенно другая философия(и шаблоны её неотъемлемая часть) - на с++ вы скорее проектируете нежели программируете. Так-что Бьерн был хитрый троль :))) и вначале не открывал все карты.
А остальные начали это бездумно копипастить - хотя это уже фактически не требовалось.
codesnip
> Потом на плюсах бывает очень сложно понять почему программа не компилится
бгг - вообще то в плюсах гораздо более развитый контроль ошибок - вернее всего сам синтаксис языка с был изменен Страуструпом чтобы избежать ошибочных мест в коде. Хотя я согласен, что неоднозначностей в языке полным-полно - но таких глупых ошибок которые можно сделать в с - с++ уже нельзя.
codesnip
> 100 раз легче дебажить
мне проще с++ - например си код я воспринимаю иногда как абракадабру - из-за того что в приложении сотни и тысячи мелкий фций(штук 50 переходов в дебаге - и мысль уже теряется - просто уже в голове трудно держать всю цепочку) - и понять, что хотел автор просто невозможно - а с++ хотябы классами это более менее структурировано - ну какбе это я про себя говорю :))
Си не знаю - начал с С++. Когда стал изучать множественное наследование, схемы ромба и прочие хитрости, то жестко сел. То, что методы не являются частью объекта, а отдельным блоком функций, у каждой из которых есть скрытый указатель на сам объект (который, как я понял, на самом деле реализуется как struct), было для меня откровением. И, видимо, поэтому хитрости со множественным наследованием до меня так и не дошли. Такой вопрос: понять множественное наследование стало проблемой потому, что я начал не с си?
loonypy
> у каждой из которых есть скрытый указатель на сам объект
это везде так (ну почти везде я думаю)
а вообще все это зависит от реализации компилятора - с чего ты взя что
>методы не являются частью объекта, а отдельным блоком функций
что такое вообще объект на низком уровне - это просто блок данных(+ виртуальная карта фций). Так как же, по твоему, методы должны являтся частью объекта :))))
в стандарте насколько мне извесно не определено как на низком уровне мне реализовать методы класса - я могу спокойно плюнуть на все реализации современных компиляторов с++ - и сделать свой компиль - где методы будут находится вообще в другом месте - а данные объекта размазать по всей памяти приложения - да как угодно - и это НЕ будет противоречить стандарту.
loonypy
> стало проблемой потому, что я начал не с си?
почему o_O????? - язык это все лишь лингвистические и логические парадигмы - которые позволяют писать код. Вы путаете понятия ЯЗЫК и КОМПИЛЯТОР.
реализация под другой процессор того же с++ может быть координально другой - есть процессоры например где биты внутри байтов имеют другую последовательность - системы, в которых организация памяти абсолютно отлична от x86 - и там возможно методы класса не будут ввиде
> а отдельным блоком функций
НО это не говорит что с++ перестанет быть с++ом - Язык это всего лишь набор правил - ты программировать можешь не на компе а на бумажке :))) - и никто не посмеет сказать что ты не с++ программист
loonypy
> было для меня откровением
видимо не последним
Barabus
> Выложить на торренты :)
много уже сделал? )
Xunter
> много уже сделал?
Не считал, думаю, что несколько десятков наберется, но все мои программы специфичны и мало кому нужны. А игры я делать не умею :(
fsmoke
> язык это все лишь лингвистические и логические парадигмы
То есть правила множественного наследования - это решение Страуструпа, "логический уровень" и причина не на более низких уровнях?
fsmoke
> объект на низком уровне - это просто блок данных(+ виртуальная карта фций
Вот такого низкоуровневого понимания мне не хватает. Студенческое обучение паскаль-делфи-билдер\с++ студия6 этого не дало. До этого думал, что причина в том, что не учил си.
fsmoke
> видимо не последним
ага:)
Всё нормальные мужики уже давно перешли на брайн фак, не тупите!
Igor'
> брайн фак
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++
.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.
------.--------.>+.>.
loonypy
> То есть правила множественного наследования - это решение Страуструпа
ага
ЗЫ
Т.е. все это множественное наследование и виртуальное инстанцирование экземпляров предков при этом наследовании - это выдумки Страуструпа. Так что на компилятор нечего гнать особо - разработчикам компилятора наоборот надо памятник ставить, что всю вот эту логику он смогли реализовать хоть как то.
ЗЫ
Первый компьль кстати сам Б.Страуструп написал - причем он не был вообщем-то компилем - это был интерпретатор из с++ синтаксиса в си - а си уже компилился имеющимся в то время компилером :))))
fsmoke
Ясно. Не хочу быть навязчивым, но еще два вопроса. Когда-то у Мейера читал, что в с++ есть 2 варианта написания конструкторов, скорость выполнения у каждого разная. Причина связана с уровнем не логики, а ассемблера. Это имеет смысл для всех платформ, даже для приставок? И много подобных нюансов, связанных с аппаратной реализацией кода, нужно учитывать, чтобы разбираться в том, что (скорость выполнения, нагрузка) стоит за тем или иным средством с++?
loonypy
> 2 варианта написания конструкторов
что ты имеешь ввиду - Мейерс много чего писал :)))
loonypy
> Это имеет смысл для всех платформ, даже для приставок? И много подобных
> нюансов, связанных с аппаратной реализацией кода, нужно учитывать, чтобы
> разбираться в том, что (скорость выполнения, нагрузка) стоит за тем или иным
> средством с++?
слушай платформы разные, компилеры разные, естественно есть общие принципы оптимизации - но они алгоритмические а не низкоуровневые. И ты никогда не будешь уверен что компилер правильно понял что ты от него хочешь - соответственно ты не можешь быть уверенным, что он сгенерит оптимальный код - если ты хочешь быть уверен - используй асм - там ты вообще всем будешь управлять.
Языки высокого уровня были придуманы, чтобы облегчить написание программ, а не для того чтобы создавать максимально быстрый код.
А при кроссплатформенной разработке вообще лучше не выходить за рамки стандарта - здесь производительность как правило дело 10е - главное чтоб везде собиралось.
Запомни простое правило(почти всегда работает): Универсальное решение - медленное. Частное решение - быстрое.
Каждое решение выбирается от задачи.
Так что я тебе рекомендую оптимизировать алгоритмы - благодаря им ты можешь получить прирост в разы, 10ки а может и 100ни раз - чем переписывать их на асме и получить прирост в 1%
fsmoke
> что ты имеешь ввиду
Откопал его книгу про 55 советов - не нашел. Похоже спутал с каким-то другим источником.
//1, работает быстрее
class A
{
public:
A() : n(1)
{ }
private:
int n;
};
//чем
class A
{
public:
A()
{
n=1;
}
private:
int n;
};Это тоже выдумка Страуструпа?
fsmoke
> есть общие принципы оптимизации - но они алгоритмические а не низкоуровневые
fsmoke
> Так что я тебе рекомендую оптимизировать алгоритмы - благодаря им ты можешь
> получить прирост в разы, 10ки а может и 100ни раз - чем переписывать их на асме
> и получить прирост в 1%
Понял.
Тема в архиве.