[dxp 65]

для этого надо сначала понять, какие плюсы Вы видите в его использовании?

Как обычно - облегчение как проектирования софта, так и написания кода. Активно использую все средства, кроме откровенно тяжёлых, оверхедных. А ваши рассуждения можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ. Кстати, такие холивары (асм vs C) весьма громко гремели лет 10 назад.

[Danis 0]

А ваши рассуждения можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ. Кстати, такие холивары (асм vs C) весьма громко гремели лет 10 назад.

 

Согласен. Но думаю ТС тогда не нужно было вести речь о GSM модемах, а просто задать вопрос по ООП на С++: ”Как лучше объявить в программе переменную-наследника?” Тут все таки, ИМХО для ТС интересно обучение, нежели необходимость применения.

Рекомендую почитать Шилдт Г. C++. Наследование, полиморфизм, инкапсуляция.

[kolobok0 0]

...текстового редактора...

 

мы о конечной задачи. не теряйте фокус!!!

 

(круглый)

 

 

..облегчение как проектирования софта, так и написания кода....можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ....

 

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

 

написание кода - то немного другое. облегчение можно получить при распределённой разработки но не в ущерб задачи, скорости и т.д. и т.п.. распределённой - это когда теряется мало времени на осмысление новым винтиком в команде фронта работы. Это вот единственный плюс который лично я наблюдаю. Минусов, на мой взгляд, гораздо больше. И МК (чиссо мой взгляд) силён не тем, что можно и на нём "как у больших". А немного другим.

 

холивар не бум. ну его в баню.

 

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

Что написал - сам дурак(С)

хотя знаю не только азмы, но ещё кучу других языков и ОО и не очень. И не только знаю но и активно пишу на них.

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

 

(круглый)

 

[Артём__ 0]

Но думаю ТС тогда не нужно было вести речь о GSM модемах, а просто задать вопрос по ООП на С++: ”Как лучше объявить в программе переменную-наследника?”

 

Да, можно было спросить не о модемах, а о применении наследования, полиморфизма, инкапсуляции для IAR AVR. Но говорить о реальном примере как-то проще и понятнее.

 

Тут все таки, ИМХО для ТС интересно обучение, нежели необходимость применения.

 

Есть такая необходимость применения, которая может быть реализована средствами Си++.

И да, интересно не приведёт ли применение наследования, полиморфизма, инкапсуляции к нежелательным последствиям (как то: глюки компилятора, возрастанию размера кода, падению быстродействия и тп).

 

Рекомендую почитать Шилдт Г. C++. Наследование, полиморфизм, инкапсуляция.

 

ИМХО, слишком абстрактно (даже для Windows, не говоря о МК).

 

 

проектирование - это ООА.

 

Это чё?(как расшифровываетсяв смысле?)

 

 

Минусов, на мой взгляд, гораздо больше.

 

Об чём и речь.Какие минусы?

 

И МК (чиссо мой взгляд) силён не тем, что можно и на нём "как у больших". А немного другим.

 

Чем?

 

холивар не бум. ну его в баню.

 

Это - да. Согласен. И не в баню, а ещё подальше.

 

 

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

Что написал - сам дурак(С)

Как вам удаётся на асм быстреё чем на Си?

Какие задачи?

[dxp 65]

проектирование - это ООА.

Не знаю, что это такое. Для меня проектирование - это создание "каркаса" программы, определение основных типов, их интерфейсов и взаимодействия. И тут С++ на три головы выше С и на 10 голов выше асма. Благодаря нативной поддержке объектной парадигмы.

 

Разрабатывая программу на С++ (или любом другом языке, поддерживающим объектный подход), я мыслю объектами реального мира (как рекомендуют классики), которые имеют прямые аналоги в виде типов, определяемых пользователем, (классов). Это выводит процесс разработки программы на значительно более высокий уровень и весьма поднимает достижимый потолок сложности. Даже при разработке простых программ очень удобно (когда уже есть навык) использовать этот же подход - всё получается легко и непринуждённо. Почему нужно от этого отказываться, не понимаю, тем более, что всё это сегодня доступно бесплатно (единственная и естественная плата за это - затраты на изучение языка, который относительно сложен).

 

про азм и си под МК... не знаю, что даже ответить. чисто по мне - просче и быстрее на азме(повторюсь - для МК). но тут кому как...

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

 

 

у азма всегда был и останется один большой плюс, на мой взгляд:

Что написал - сам дурак(С)

Это субъективные страхи. Давным давно уже ситуация такова, что 99 целых и 9 в периоде процентов ошибок содержатся в пользовательском коде, я уже и забыл, когда находили более-менее серьёзный баг у компилятора. А если не доверять программным инструментам, то вообще всё надо делать без компа - ведь и САПР печатных плат тоже может в герберах накосячить.

 

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

У меня немного другой взгляд. Задач много, а времени мало, поэтому тратить его на написание низкоуровневого кода, который едва ли лучше по качеству, чем кодогенерация с ЯВУ, слишком расточительно. Ну, и оформление алгоритмических идей на основе языковых концепций, предоставляемых ЯВУ, лично мне доставляет эстетическое удовольствие. Т.е. совмещаем полезное с приятным.

[khlenar 5]

С++ я бы сказал совершенно другой, отличный от С язык. Я раза три пытался вникнуть в него, 2,3 страницы чтения и все, мозги просто отказываются понимать(честное слово). Все

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

[dxp 65]

С++ я бы сказал совершенно другой, отличный от С язык. Я раза три пытался вникнуть в него, 2,3 страницы чтения и все, мозги просто отказываются понимать(честное слово). Все

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

Тогда С - язык создания процедур. :) На самом деле вы, конечно, правы - при всём внешнем сходстве между С и С++ это весьма разные языки. Точнее, С++ может "мимикрировать" под С, но смысла в этом немного. Чтобы понять С++ надо начать немного по-другому думать. Перейти от оперирования обилием переменных и функций, работающих с ними, к оперированию законченными объектами - аналогами объектов внешнего мира. Жизнь сразу приобретёт новые краски. :) Наверное, вам имеет смысл познакомиться с фундаментальной работой тов. Г.Буча "Объектно-ориентированный анализ и проектирование", отличная книжка, хотя она, можно сказать, не столько о само ЯП С++, сколько о подходах. Имхо, маст рид. Книжка легко доступна в интернетах: например тут или тут.

[khlenar 5]

... Наверное, вам имеет смысл познакомиться с фундаментальной работой тов. Г.Буча "Объектно-ориентированный анализ и проектирование", отличная книжка, хотя она, можно сказать, не столько о само ЯП С++, сколько о подходах. Имхо, маст рид. Книжка легко доступна в интернетах: например тут или тут.

Спасибо, буду читать.

[kolobok0 0]

...Это чё?(как расшифровываетсяв смысле?).....

 

я лучше дальше помолчу господа :)))

 

 

Не знаю, что это такое. Для меня проектирование - это создание "каркаса" программы, определение основных типов, их интерфейсов и взаимодействия....

 

весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.

 

рекомендую альма матер учения по ОО:

 

Гради Буч

Объектно-Ориентированный Анализ и Проектирование

 

объясняю.

термины

ООА = Объектно Ориентированный Анализ

ООП = Объектно Ориентированное Проектирование

 

(круглый)

ЗЫ

а то как то расуждать-рассуждаете, а элементарных вещей не знаете.

ЗЫ ЗЫ

плюсы данного подхода апсолютно не в типизации и иже. И (о ужас!!!) даже не в си плас плас :))) Точнее скажем так - язык записи логики работы - вторичен.

[haker_fox 61]

весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.

 

ООА = Объектно Ориентированный Анализ

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

Никто не может знать все: все основы, все серединки и все верха.

 

 

 

 

Себе купил недавно эту книгу. Хотелось именно автора Си++ почитать. Пока только положительные эмоции)))

 

[dxp 65]

я лучше дальше помолчу господа :)))

 

весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.

 

рекомендую альма матер учения по ОО:

 

Гради Буч

Объектно-Ориентированный Анализ и Проектирование

Правда? Ой, спасибо большое, практически спасли дураков от невежества. Правда, чукча, видимо, не читатель, по крайней мере, не читатель поста №22 (особенно, последних двух предложений) этой темы.

 

объясняю.

термины

ООА = Объектно Ориентированный Анализ

ООП = Объектно Ориентированное Проектирование

ООА - очень неупотребительная аббревиатура. Я её не встречал со времён, когда ознакомился с трудом Г.Буча, это было порядка 10 лет назад. Поэтому ни разу не странно, что люди не догадались, что там некий автор имел в виду (а телепаты, как всегда, в отпуске). Гораздо более употребительная аббревиатура - ООП, тем более, что и речь шла о проектировании. Кстати, не об ОО проектировании, а вообще. Или для вас С++ == ООП?

 

ЗЫ

а то как то расуждать-рассуждаете, а элементарных вещей не знаете.

ЗЫ ЗЫ

Да, тут есть у нас участники, которые любят порассуждать абстрактно, сыпать малоупотребительными терминами, но не приводят ни одного конкретного примера, хотя дискуссия с ними и началась именно с просьбы показать эти гадкие, негодные средства С++, которые делают жизнь на МК невыносимой. Это вызывает подозрения, что оные аффтары ничем, кроме устаревших лет 10 назад стереотипов, не обладают (наверное, это очень помогает писать ООА/ООП программы на ассемблере).

 

плюсы данного подхода апсолютно не в типизации и иже. И (о ужас!!!) даже не в си плас плас :))) Точнее скажем так - язык записи логики работы - вторичен.

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

[kolobok0 0]

..спасибо большое..

 

пожалуйста!!! Вы спрашивали :))) а посты ваши были потом...

 

 

ООА - очень неупотребительная аббревиатура...Гораздо более употребительная аббревиатура - ООП, тем более, что и речь шла о проектировании...

 

вообщето перед тем как что то Проектировать надо Анализировать. Опять открыл(наверное) для вас америку? :))) не верю. наверное просто забыли... ну или опять лукавите :))) ну да лано. оставим на вашей совести...

 

 

...негодные средства С++, которые делают жизнь на МК невыносимой....

простите вы сейчас о чём? где вы нателепортировали такую мысль то? что невыносимая жизня от негодных средств? Наверное опять забыли о чём речь? :)))) бывает... Речь шла о том, что не стоит тащить гаубицу в окоп для стрельбы по тараканам.

надеюсь моя мысль не глубокая, понятна? (Раневская)

 

...О конкретике уже и речи нет.

Что конкретного Вы хотите видеть? конкретика - то уже по задаче. Вы хотите меряться пиписьками или задачами? Вы случаем не дохтуртумас или как там?

 

с уважением

(круглый)

ЗЫ

Прям как дети - ей богу...

 

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

 

Простите, не хотел никого обижать.

Если посмотреть выше, то попытки развода на холивар - не от меня исходит. При этом, мягко говоря, люди находятся не в теме.

 

если говорить про книги, то в данном направлении есть ещё замечательная парта от Кнута (после Страуструпа рекомендую).

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

 

удачи вам

(круглый)

 

PS

Если речь уже перешла в слив не о чём - то считайте меня эээээээ плохим человеком.

Я заткнулся... Ведь от этого мои знания не уменьшатся :)))) (С)

Изменено 19 декабря, 2011 пользователем kolobok0

[sonycman 1]

Если речь уже перешла в слив не о чём - то считайте меня эээээээ плохим человеком.

Я заткнулся... Ведь от этого мои знания не уменьшатся :)))) (С)

Да всё уже ясно с Вами. Пришли, ляпнули ни о чём, не приведя ни одного конкретного примера, нахамили уважаемым людям и свалили :01:

[sasamy 0]

Поясните, пожалуйста, какие именно аспекты С++ делают его нерекомендуемым для использования с МК?

 

Самый главный аспект - на порядки более сложный язык по сравнению с С и в то же время не дающий абсолютно никаких реальных "++" по сравнению с С, хотя "рекомендовать" тут нет смысла - каждый использует то что ему ближе, с++ на МК - это наглядный пример "ООП ради самой ООП".

[dxp 65]

Самый главный аспект - на порядки более сложный язык по сравнению с С

Сложный - да, но как бы эти порядки определить? И кто заставляет сразу метапрограммированием на шаблонах заниматься? Сложность растёт постепенно по мере набора опыта и сложности задач. С++ не заставляет его сразу весь знать. Это целый мир, и каждый в нём находит свою нишу. Кому-то достаточно простых объектов, а кто-то не мыслит жизни без параметризованных типов. С++ позволяет всё то же, что и С, но желающим даёт возможность использовать и более продвинутые средства языка, быстрее, лаконичнее и выразительнее писать более сложные программы.

 

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

Голословное заявление. Кому не даёт реальных ++? Мне даёт. И знаю немало людей, кому тоже даёт.

 

с++ на МК - это наглядный пример "ООП ради самой ООП".

И опять вопрос (его почему-то приходится всегда задавать оппонентам): а причём тут ООП? Я знаю массу программ на С++, где ООП и не пахнет. А где ООП катит, так оно отлично ложится и даже на самые мелкие МК.

 

В общем, такая дискуссия пуста, т.к. безпредметна. Надо конкретные аргументы приводить. А в таком ключи можно и на С наехать, дескать, нафиг не нужен, асм форева (проходили 10 лет назад).