Как бы правильно отработать такую ситуацию на С++:
Есть плата, на которую может устанавливаться два-три близких по системе команд GSM-модема (большинство нужных команд полностью идентичны).
Думаю делать так:
Создать класс содержащий все нужные функции (различающиеся команды объявить как виртуальные), от него создать нужное количество наследников с переопределёнными функциями и .
Тип модема может задаваьтся конфигурацией (байт в еепром) или определятся запросом версии AT-командой (предпочтительней).
А вот как дальше делать?
Как лучше объявить в программе переменную-наследника?
Компилятор IAR AVR.
Полная версия этой страницы: Вопрос по С++
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Направление мысли правильное. Фабрика вам в помощь. Если есть возможность использовать динамическую память , то вообще без проблем. Если нет - статический буфер достаточного размера, чтоб вместить самого большого наследника и placement new.
Цитата(neiver @ Dec 13 2011, 20:38) 
Если есть возможность использовать динамическую память , то вообще без проблем.
Не использовал пока динамическую память, нода смотреть как с этим в IAR AVR.
Цитата(neiver @ Dec 13 2011, 20:38)
статический буфер достаточного размера, чтоб вместить самого большого наследника и placement new
Получается по смыслу что-то аналогичное Сишному union-у?
Цитата(_Артём_ @ Dec 13 2011, 22:49)
Получается по смыслу что-то аналогичное Сишному union-у?
Нет. Просто статически выделяется буфер в памяти и в нем конструируется (с помощью конструктора) объект нужного типа.
Код
char buffer[MAX_BUFFER_SIZE]; // static array
...
class Base{...};
class D1 :public Base {...};
class D2 :public Base {...};
class D3 :public Base {...};
...
Base *ProduceObject(ObjectType type)
{
switch(type)
{
case Type1: return new (buffer) D1(); // creating an object using palcement new
case Type2: return new (buffer) D2();
case Type3: return new (buffer) D3();
}
}
...
class Base{...};
class D1 :public Base {...};
class D2 :public Base {...};
class D3 :public Base {...};
...
Base *ProduceObject(ObjectType type)
{
switch(type)
{
case Type1: return new (buffer) D1(); // creating an object using palcement new
case Type2: return new (buffer) D2();
case Type3: return new (buffer) D3();
}
}
Да, еще возможно придётся определить оператор new если он еще не определен:
Код
void *operator new(unsigned int size, void* ptr)
{
return ptr;
}
{
return ptr;
}
В этом операторе можно что-то сделать с буфером памяти, обнулить его, например, а можно ничего не делать.
Цитата(neiver @ Dec 13 2011, 21:12)
Нет. Просто статически выделяется буфер в памяти и в нем конструируется (с помощью конструктора) объект нужного типа.
Да, еще возможно придётся определить оператор new если он еще не определен:
В этом операторе можно что-то сделать с буфером памяти, обнулить его, например, а можно ничего не делать.
Код
char buffer[MAX_BUFFER_SIZE]; // static array
...
class Base{...};
class D1 :public Base {...};
class D2 :public Base {...};
class D3 :public Base {...};
...
Base *ProduceObject(ObjectType type)
{
switch(type)
{
case Type1: return new (buffer) D1(); // creating an object using palcement new
case Type2: return new (buffer) D2();
case Type3: return new (buffer) D3();
}
}
...
class Base{...};
class D1 :public Base {...};
class D2 :public Base {...};
class D3 :public Base {...};
...
Base *ProduceObject(ObjectType type)
{
switch(type)
{
case Type1: return new (buffer) D1(); // creating an object using palcement new
case Type2: return new (buffer) D2();
case Type3: return new (buffer) D3();
}
}
Да, еще возможно придётся определить оператор new если он еще не определен:
Код
void *operator new(unsigned int size, void* ptr)
{
return ptr;
}
{
return ptr;
}
В этом операторе можно что-то сделать с буфером памяти, обнулить его, например, а можно ничего не делать.
Что-то всё равно не так.
Ввёл:
Код
char buffer[1000]; // static array
class Base {
public:
unsigned int A;
unsigned int N;
void SetA(unsigned int a)
{
A=a;
}
};
class D1 :public Base {
public:
void *operator new(unsigned int size, void* ptr)
{
}
void SetN()
{
N=0;
}
};
class D2 :public Base {
public:
void SetN()
{
N=1;
}
};
class D3 :public Base {
public:
void SetN()
{
N=2;
}
};
Base *ProduceObject(unsigned char type)
{
switch(type)
{
case 0: return new (buffer) D1(); // creating an object using palcement new
case 1: return new (buffer) D2();
case 2: return new (buffer) D3();
}
}
int _tmain(int argc, _TCHAR* argv[])
{
Base *p;
p=ProduceObject(0);
p->SetA(10);
}
class Base {
public:
unsigned int A;
unsigned int N;
void SetA(unsigned int a)
{
A=a;
}
};
class D1 :public Base {
public:
void *operator new(unsigned int size, void* ptr)
{
}
void SetN()
{
N=0;
}
};
class D2 :public Base {
public:
void SetN()
{
N=1;
}
};
class D3 :public Base {
public:
void SetN()
{
N=2;
}
};
Base *ProduceObject(unsigned char type)
{
switch(type)
{
case 0: return new (buffer) D1(); // creating an object using palcement new
case 1: return new (buffer) D2();
case 2: return new (buffer) D3();
}
}
int _tmain(int argc, _TCHAR* argv[])
{
Base *p;
p=ProduceObject(0);
p->SetA(10);
}
Компилятор говорит:
Цитата
error C2660: 'operator new' : function does not take 2 arguments
QUOTE (_Артём_ @ Dec 13 2011, 22:07)
Что-то всё равно не так.
Так вы operator new объявили членом D2, а надо его сделать членом Base. А еще можно buffer и фабрику также спрятать внутрь base, сделав статическим членом и статической функцией соответственно.
Цитата(Сергей Борщ @ Dec 13 2011, 23:06)
Так вы operator new объявили членом D2, а надо его сделать членом Base.
Да, не заметил. Спасибо.
Цитата(Сергей Борщ @ Dec 13 2011, 23:06)
А еще можно buffer и фабрику также спрятать внутрь base, сделав статическим членом и статической функцией соответственно.
Попробую.
Проверял в Visual Studio (ничего другого под рукой нет).
Как считаете в IAR AVR так же всё будет работать?
Цитата(_Артём_ @ Dec 13 2011, 20:38)
Создать класс содержащий все нужные функции (различающиеся команды объявить как виртуальные), от него создать нужное количество наследников с переопределёнными функциями и .
......
......
ИМХО, тут можно конечно сделать, но из за 2-x, 3-x подобных устройств использовать С++ со своими возможностями ООП (виртуальные функции и полиморфизм) Вам больше навредит, чем поможет. Сильно не рационально. С++ надо использовать только там, где это действительно необходимо и приемлемо, а не просто ради того чтоб использовать. Вот если бы подобных устройств было десятки, еще можно говорить….
Цитата(Danis @ Dec 14 2011, 12:33)
ИМХО, тут можно конечно сделать, но из за 2-x, 3-x подобных устройств использовать С++ со своими возможностями ООП (вирртуальные функции и полиморфизм) вам больше навредит, чем поможет. Сильно не рационально. С++ надо использовать только там, где это действительно необходимо и рационально, а не просто ради того чтоб использовать. Вот если бы подобных устройств было десятки, еще можно говорить….
Поставленную задачу и проще и эффективнее решать именно с помощью виртуальных функций и полиморфизма и не важно сколько конкретно устройств имеется, их может быть более одного - этого уже достаточно.
К тому-же как это можно реализовать без полиморфизма?
С помощью таблиц функций? Вручную их заполнять нужными значениями и т.д. Получаются те-же виртуальные функции, только самописные и кривые - восход солнца вручную.
Вставлять в местах где поведение устройств ветвления по типу устройства? Еще более неудобно и черевато дополнительными ошибками.
Так, что выбранный путь очень даже рационален. Виртуальные функции дешевы и удобны.
Цитата(Danis @ Dec 14 2011, 10:33)
ИМХО, тут можно конечно сделать, но из за 2-x, 3-x подобных устройств использовать С++ со своими возможностями ООП (виртуальные функции и полиморфизм) Вам больше навредит, чем поможет. Сильно не рационально. С++ надо использовать только там, где это действительно необходимо и приемлемо, а не просто ради того чтоб использовать. Вот если бы подобных устройств было десятки, еще можно говорить….
В смысле?
Что значит "десятки устройств"?
Десятки типов устройств?
Или экземпляров?
Типов модулей может быть 2-3-..5..10(это точно перебор, да и 5 - перебор: 2-3, а дальше - много(слишком))
А модулей - сотни(чем больше тем лучше) каждого типа...
У как по-Вашему лучше сделать?
Цитата(Danis @ Dec 14 2011, 10:33)
С++ надо использовать только там, где это действительно необходимо и приемлемо, а не просто ради того чтоб использовать
честный ответ - как глоток свежего воздуха...©
А где ж его использовать?(С++, в смысле)...?
Цитата(_Артём_ @ Dec 14 2011, 13:35)
..А где ж его использовать?(С++, в смысле)...?
ну уж точно не в МК
покрайней мере пока не стоит в полной мере. а вот ООА необходимо юзать всегда. даже когда вы пишите на азме. при этом сама механизация того или иного функционала - уже вторично.(круглый)
Цитата(kolobok0 @ Dec 14 2011, 17:57)
ну уж точно не в МК покрайней мере пока не стоит в полной мере.
покрайней мере пока не стоит в полной мере.Поясните, пожалуйста, какие именно аспекты С++ делают его нерекомендуемым для использования с МК?
Цитата(dxp @ Dec 14 2011, 15:59)
...какие именно аспекты С++ делают его нерекомендуемым для использования с МК?
для этого надо сначала понять, какие плюсы Вы видите в его использовании?
только без взгляда под углом, что это можно сделать. Сделать можно ВСЁ...
а вот плюсы...с этим уже поконкретней.
(круглый)
ЗЫ
Всегда надо идти от задачи. Лично мне не известны такие задачи где требуется си плас плас под МК. За исключением не анжинерных задач - типа попилить бабло. Но это мы не бум рассматривать надеюсь...
Цитата(_Артём_ @ Dec 14 2011, 12:35)
В смысле?
Что значит "десятки устройств"?
Десятки типов устройств?
Или экземпляров?
Что значит "десятки устройств"?
Десятки типов устройств?
Или экземпляров?
Разумеется типов, Вы же сами писали: "два-три близких по системе команд GSM-модема".
Цитата(_Артём_ @ Dec 14 2011, 12:35)
У как по-Вашему лучше сделать?
На чистом Си, нет никаких проблем.
Не хочу переводить тему в категорию Си vs C++. Сам пишу софт в основном для ПК, на С++. В микроконтроллере мне С++ понадобился 1 раз, кода писал приложение для TFT панели, писал свой GUI. Тут С++ со своими возможностями ООП ”рулит”.
Цитата(kolobok0 @ Dec 16 2011, 10:23)
Лично мне не известны такие задачи где требуется си плас плас под МК.
Лично мне не известны такие задачи, где требуется что угодно, кроме текстового редактора (набирать вручную HEX-файлы). Этого, в принципе, достаточно. Мнемокод — уже счастье. Ассемблер, да если еще и с макросами — рай земной.(«нужно человеку буханка хлеба и четверть ведра воды в день, всего остального ему хочется» © забыл чей)
Цитата(kolobok0 @ Dec 16 2011, 15:23)
для этого надо сначала понять, какие плюсы Вы видите в его использовании?
Как обычно - облегчение как проектирования софта, так и написания кода. Активно использую все средства, кроме откровенно тяжёлых, оверхедных. А ваши рассуждения можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ. Кстати, такие холивары (асм vs C) весьма громко гремели лет 10 назад.
Цитата(dxp @ Dec 16 2011, 22:48)
А ваши рассуждения можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ. Кстати, такие холивары (асм vs C) весьма громко гремели лет 10 назад.
Согласен. Но думаю ТС тогда не нужно было вести речь о GSM модемах, а просто задать вопрос по ООП на С++: ”Как лучше объявить в программе переменную-наследника?” Тут все таки, ИМХО для ТС интересно обучение, нежели необходимость применения.
Рекомендую почитать Шилдт Г. C++. Наследование, полиморфизм, инкапсуляция.
Цитата(ReAl @ Dec 16 2011, 13:57)
...текстового редактора...
мы о конечной задачи. не теряйте фокус!!!
(круглый)
Цитата(dxp @ Dec 16 2011, 23:48)
..облегчение как проектирования софта, так и написания кода....можно легко распространить и на С - вон есть асм, зачем ещё какие-то Цэ....
проектирование - это ООА. к способу изложения(язык написания) имеет слабое отношение. Скажем так - ОО язык более гармоничен, но не панацея. Я бы даже больше сказал - если хоть раз строил анализ на данной технологии, то по другому подходить к решению задачи - как то даже и близко не стояло...
написание кода - то немного другое. облегчение можно получить при распределённой разработки но не в ущерб задачи, скорости и т.д. и т.п.. распределённой - это когда теряется мало времени на осмысление новым винтиком в команде фронта работы. Это вот единственный плюс который лично я наблюдаю. Минусов, на мой взгляд, гораздо больше. И МК (чиссо мой взгляд) силён не тем, что можно и на нём "как у больших". А немного другим.
холивар не бум. ну его в баню.
про азм и си под МК... не знаю, что даже ответить. чисто по мне - просче и быстрее на азме(повторюсь - для МК). но тут кому как... у азма всегда был и останется один большой плюс, на мой взгляд:
Что написал - сам дурак(С)
хотя знаю не только азмы, но ещё кучу других языков и ОО и не очень. И не только знаю но и активно пишу на них.
С другой стороны, если рассматривать с точки зрения боевого бизнеса - то тут побеждает оптимум цена-качество-бюджет. Естественно при одинаковом наборе фич зачастую побеждает языки более высокого уровня, при незначительном(или значительном) удорожании конструктива. При этом (как правило) можно выиграть в скорости. Качество - зависит уже от исполнителя больше. Можно на любом языке фигню сморозить. Но это в каждом конкретном случае - своя кухня. надо считать и не всегда однозначно.
(круглый)
Цитата(Danis @ Dec 16 2011, 22:55)
Но думаю ТС тогда не нужно было вести речь о GSM модемах, а просто задать вопрос по ООП на С++: ”Как лучше объявить в программе переменную-наследника?”
Да, можно было спросить не о модемах, а о применении наследования, полиморфизма, инкапсуляции для IAR AVR. Но говорить о реальном примере как-то проще и понятнее.
Цитата(Danis @ Dec 16 2011, 22:55)
Тут все таки, ИМХО для ТС интересно обучение, нежели необходимость применения.
Есть такая необходимость применения, которая может быть реализована средствами Си++.
И да, интересно не приведёт ли применение наследования, полиморфизма, инкапсуляции к нежелательным последствиям (как то: глюки компилятора, возрастанию размера кода, падению быстродействия и тп).
Цитата(Danis @ Dec 16 2011, 22:55)
Рекомендую почитать Шилдт Г. C++. Наследование, полиморфизм, инкапсуляция.
ИМХО, слишком абстрактно (даже для Windows, не говоря о МК).
Цитата(kolobok0 @ Dec 17 2011, 23:46)
проектирование - это ООА.
Это чё?(как расшифровываетсяв смысле?)
Цитата(kolobok0 @ Dec 17 2011, 23:46)
Минусов, на мой взгляд, гораздо больше.
Об чём и речь.Какие минусы?
Цитата(kolobok0 @ Dec 17 2011, 23:46)
И МК (чиссо мой взгляд) силён не тем, что можно и на нём "как у больших". А немного другим.
Чем?
Цитата(kolobok0 @ Dec 17 2011, 23:46)
холивар не бум. ну его в баню.
Это - да. Согласен. И не в баню, а ещё подальше.
Цитата(kolobok0 @ Dec 17 2011, 23:46)
про азм и си под МК... не знаю, что даже ответить. чисто по мне - просче и быстрее на азме(повторюсь - для МК). но тут кому как... у азма всегда был и останется один большой плюс, на мой взгляд:
Что написал - сам дурак(С)
Что написал - сам дурак(С)
Как вам удаётся на асм быстреё чем на Си?
Какие задачи?
QUOTE (kolobok0 @ Dec 18 2011, 04:46)
проектирование - это ООА.
Не знаю, что это такое. Для меня проектирование - это создание "каркаса" программы, определение основных типов, их интерфейсов и взаимодействия. И тут С++ на три головы выше С и на 10 голов выше асма. Благодаря нативной поддержке объектной парадигмы.
Разрабатывая программу на С++ (или любом другом языке, поддерживающим объектный подход), я мыслю объектами реального мира (как рекомендуют классики), которые имеют прямые аналоги в виде типов, определяемых пользователем, (классов). Это выводит процесс разработки программы на значительно более высокий уровень и весьма поднимает достижимый потолок сложности. Даже при разработке простых программ очень удобно (когда уже есть навык) использовать этот же подход - всё получается легко и непринуждённо. Почему нужно от этого отказываться, не понимаю, тем более, что всё это сегодня доступно бесплатно (единственная и естественная плата за это - затраты на изучение языка, который относительно сложен).
QUOTE (kolobok0 @ Dec 18 2011, 04:46)
про азм и си под МК... не знаю, что даже ответить. чисто по мне - просче и быстрее на азме(повторюсь - для МК). но тут кому как...
Ну, если для вас даже по сравнению с С всё проще делать на асме, то все аргументы за С++ будут мимо кассы. Но это не умаляет их. Если таково ваше личное предпочтение, то неплохо бы сделать на этом акцент при высказывании оценок, а то создаётся впечатление, что за вашими словами стоят какие-то объективные обстоятельства, препятствующие эффективному использованию С++ на МК.
QUOTE (kolobok0 @ Dec 18 2011, 04:46)
у азма всегда был и останется один большой плюс, на мой взгляд:
Что написал - сам дурак(С)
Что написал - сам дурак(С)
Это субъективные страхи. Давным давно уже ситуация такова, что 99 целых и 9 в периоде процентов ошибок содержатся в пользовательском коде, я уже и забыл, когда находили более-менее серьёзный баг у компилятора. А если не доверять программным инструментам, то вообще всё надо делать без компа - ведь и САПР печатных плат тоже может в герберах накосячить.
QUOTE (kolobok0 @ Dec 18 2011, 04:46)
С другой стороны, если рассматривать с точки зрения боевого бизнеса - то тут побеждает оптимум цена-качество-бюджет. Естественно при одинаковом наборе фич зачастую побеждает языки более высокого уровня, при незначительном(или значительном) удорожании конструктива. При этом (как правило) можно выиграть в скорости. Качество - зависит уже от исполнителя больше. Можно на любом языке фигню сморозить. Но это в каждом конкретном случае - своя кухня. надо считать и не всегда однозначно.
У меня немного другой взгляд. Задач много, а времени мало, поэтому тратить его на написание низкоуровневого кода, который едва ли лучше по качеству, чем кодогенерация с ЯВУ, слишком расточительно. Ну, и оформление алгоритмических идей на основе языковых концепций, предоставляемых ЯВУ, лично мне доставляет эстетическое удовольствие. Т.е. совмещаем полезное с приятным.
С++ я бы сказал совершенно другой, отличный от С язык. Я раза три пытался вникнуть в него, 2,3 страницы чтения и все, мозги просто отказываются понимать(честное слово). Все
же автор больше математик нежели программист и С++ скорее не язык программирования, а язык создания классов, обьектов и т.п.. Все это лишь мое сложившее мнение, не более.
же автор больше математик нежели программист и С++ скорее не язык программирования, а язык создания классов, обьектов и т.п.. Все это лишь мое сложившее мнение, не более.
QUOTE (Iptash @ Dec 18 2011, 20:24)
С++ я бы сказал совершенно другой, отличный от С язык. Я раза три пытался вникнуть в него, 2,3 страницы чтения и все, мозги просто отказываются понимать(честное слово). Все
же автор больше математик нежели программист и С++ скорее не язык программирования, а язык создания классов, обьектов и т.п.. Все это лишь мое сложившее мнение, не более.
же автор больше математик нежели программист и С++ скорее не язык программирования, а язык создания классов, обьектов и т.п.. Все это лишь мое сложившее мнение, не более.
Тогда С - язык создания процедур.
На самом деле вы, конечно, правы - при всём внешнем сходстве между С и С++ это весьма разные языки. Точнее, С++ может "мимикрировать" под С, но смысла в этом немного. Чтобы понять С++ надо начать немного по-другому думать. Перейти от оперирования обилием переменных и функций, работающих с ними, к оперированию законченными объектами - аналогами объектов внешнего мира. Жизнь сразу приобретёт новые краски. Наверное, вам имеет смысл познакомиться с фундаментальной работой тов. Г.Буча "Объектно-ориентированный анализ и проектирование", отличная книжка, хотя она, можно сказать, не столько о само ЯП С++, сколько о подходах. Имхо, маст рид. Книжка легко доступна в интернетах: например тут или тут.
Цитата(dxp @ Dec 18 2011, 20:58)
... Наверное, вам имеет смысл познакомиться с фундаментальной работой тов. Г.Буча "Объектно-ориентированный анализ и проектирование", отличная книжка, хотя она, можно сказать, не столько о само ЯП С++, сколько о подходах. Имхо, маст рид. Книжка легко доступна в интернетах: например тут или тут.
Спасибо, буду читать.
Цитата(_Артём_ @ Dec 18 2011, 06:05)
...Это чё?(как расшифровываетсяв смысле?).....
я лучше дальше помолчу господа
))Цитата(dxp @ Dec 18 2011, 09:33)
Не знаю, что это такое. Для меня проектирование - это создание "каркаса" программы, определение основных типов, их интерфейсов и взаимодействия....
весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.
рекомендую альма матер учения по ОО:
Гради Буч
Объектно-Ориентированный Анализ и Проектирование
объясняю.
термины
ООА = Объектно Ориентированный Анализ
ООП = Объектно Ориентированное Проектирование
(круглый)
ЗЫ
а то как то расуждать-рассуждаете, а элементарных вещей не знаете.
ЗЫ ЗЫ
плюсы данного подхода апсолютно не в типизации и иже. И (о ужас!!!) даже не в си плас плас
)) Точнее скажем так - язык записи логики работы - вторичен.
QUOTE (kolobok0 @ Dec 19 2011, 11:00)
весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.
ООА = Объектно Ориентированный Анализ
ООА = Объектно Ориентированный Анализ
Ну я вот тоже впервые эту аббревиатуру слышу... Я понимаю, это здорово, конечно, что-то новое подарить миру, и при этом радоваться, что другие этого не знали
Но это, как минимум, не скромно...Никто не может знать все: все основы, все серединки и все верха.
Себе купил недавно эту книгу. Хотелось именно автора Си++ почитать. Пока только положительные эмоции)))
QUOTE (kolobok0 @ Dec 19 2011, 10:00)
я лучше дальше помолчу господа ))
весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.
рекомендую альма матер учения по ОО:
Гради Буч
Объектно-Ориентированный Анализ и Проектирование
))весело с вами господа! вот ратуете за юзанье ОО инструментария, а об основах элементарных не в курсе.
рекомендую альма матер учения по ОО:
Гради Буч
Объектно-Ориентированный Анализ и Проектирование
Правда? Ой, спасибо большое, практически спасли дураков от невежества. Правда, чукча, видимо, не читатель, по крайней мере, не читатель поста №22 (особенно, последних двух предложений) этой темы.
QUOTE (kolobok0 @ Dec 19 2011, 10:00)
объясняю.
термины
ООА = Объектно Ориентированный Анализ
ООП = Объектно Ориентированное Проектирование
термины
ООА = Объектно Ориентированный Анализ
ООП = Объектно Ориентированное Проектирование
ООА - очень неупотребительная аббревиатура. Я её не встречал со времён, когда ознакомился с трудом Г.Буча, это было порядка 10 лет назад. Поэтому ни разу не странно, что люди не догадались, что там некий автор имел в виду (а телепаты, как всегда, в отпуске). Гораздо более употребительная аббревиатура - ООП, тем более, что и речь шла о проектировании. Кстати, не об ОО проектировании, а вообще. Или для вас С++ == ООП?
QUOTE (kolobok0 @ Dec 19 2011, 10:00)
ЗЫ
а то как то расуждать-рассуждаете, а элементарных вещей не знаете.
ЗЫ ЗЫ
а то как то расуждать-рассуждаете, а элементарных вещей не знаете.
ЗЫ ЗЫ
Да, тут есть у нас участники, которые любят порассуждать абстрактно, сыпать малоупотребительными терминами, но не приводят ни одного конкретного примера, хотя дискуссия с ними и началась именно с просьбы показать эти гадкие, негодные средства С++, которые делают жизнь на МК невыносимой. Это вызывает подозрения, что оные аффтары ничем, кроме устаревших лет 10 назад стереотипов, не обладают (наверное, это очень помогает писать ООА/ООП программы на ассемблере).
QUOTE (kolobok0 @ Dec 19 2011, 10:00)
плюсы данного подхода апсолютно не в типизации и иже. И (о ужас!!!) даже не в си плас плас )) Точнее скажем так - язык записи логики работы - вторичен.
)) Точнее скажем так - язык записи логики работы - вторичен.Вот ещё образчик чего-то такого глубокомысленного, что по доступности граничит с потоком сознания. О конкретике уже и речи нет.
Цитата(dxp @ Dec 19 2011, 10:05)
..спасибо большое..
пожалуйста!!! Вы спрашивали
)) а посты ваши были потом...Цитата(dxp @ Dec 19 2011, 10:05)
ООА - очень неупотребительная аббревиатура...Гораздо более употребительная аббревиатура - ООП, тем более, что и речь шла о проектировании...
вообщето перед тем как что то Проектировать надо Анализировать. Опять открыл(наверное) для вас америку?
)) не верю. наверное просто забыли... ну или опять лукавите )) ну да лано. оставим на вашей совести...Цитата(dxp @ Dec 19 2011, 10:05)
...негодные средства С++, которые делают жизнь на МК невыносимой....
простите вы сейчас о чём? где вы нателепортировали такую мысль то? что невыносимая жизня от негодных средств? Наверное опять забыли о чём речь?
))) бывает... Речь шла о том, что не стоит тащить гаубицу в окоп для стрельбы по тараканам. надеюсь моя мысль не глубокая, понятна? (Раневская)
Цитата(dxp @ Dec 19 2011, 10:05)
...О конкретике уже и речи нет.
Что конкретного Вы хотите видеть? конкретика - то уже по задаче. Вы хотите меряться пиписьками или задачами? Вы случаем не дохтуртумас или как там?
с уважением
(круглый)
ЗЫ
Прям как дети - ей богу...
Цитата(haker_fox @ Dec 19 2011, 09:34)
..Но это, как минимум, не скромно...Никто не может знать все...Себе купил недавно..
Простите, не хотел никого обижать.
Если посмотреть выше, то попытки развода на холивар - не от меня исходит. При этом, мягко говоря, люди находятся не в теме.
если говорить про книги, то в данном направлении есть ещё замечательная парта от Кнута (после Страуструпа рекомендую).
Если Вам под форточки - то там есть ышо пара-тройка удачных книг, больше в плоскости оси.
удачи вам
(круглый)
PS
Если речь уже перешла в слив не о чём - то считайте меня эээээээ плохим человеком.
Я заткнулся... Ведь от этого мои знания не уменьшатся
))) (С)
Цитата(kolobok0 @ Dec 19 2011, 13:04)
Если речь уже перешла в слив не о чём - то считайте меня эээээээ плохим человеком.
Я заткнулся... Ведь от этого мои знания не уменьшатся))) (С)
Я заткнулся... Ведь от этого мои знания не уменьшатся
))) (С)Да всё уже ясно с Вами. Пришли, ляпнули ни о чём, не приведя ни одного конкретного примера, нахамили уважаемым людям и свалили
Цитата(dxp @ Dec 14 2011, 15:59)
Поясните, пожалуйста, какие именно аспекты С++ делают его нерекомендуемым для использования с МК?
Самый главный аспект - на порядки более сложный язык по сравнению с С и в то же время не дающий абсолютно никаких реальных "++" по сравнению с С, хотя "рекомендовать" тут нет смысла - каждый использует то что ему ближе, с++ на МК - это наглядный пример "ООП ради самой ООП".
QUOTE (sasamy @ Dec 20 2011, 15:35)
Самый главный аспект - на порядки более сложный язык по сравнению с С
Сложный - да, но как бы эти порядки определить? И кто заставляет сразу метапрограммированием на шаблонах заниматься? Сложность растёт постепенно по мере набора опыта и сложности задач. С++ не заставляет его сразу весь знать. Это целый мир, и каждый в нём находит свою нишу. Кому-то достаточно простых объектов, а кто-то не мыслит жизни без параметризованных типов. С++ позволяет всё то же, что и С, но желающим даёт возможность использовать и более продвинутые средства языка, быстрее, лаконичнее и выразительнее писать более сложные программы.
QUOTE (sasamy @ Dec 20 2011, 15:35)
и в то же время не дающий абсолютно никаких реальных "++" по сравнению с С, хотя "рекомендовать" тут нет смысла - каждый использует то что ему ближе,
Голословное заявление. Кому не даёт реальных ++? Мне даёт. И знаю немало людей, кому тоже даёт.
QUOTE (sasamy @ Dec 20 2011, 15:35)
с++ на МК - это наглядный пример "ООП ради самой ООП".
И опять вопрос (его почему-то приходится всегда задавать оппонентам): а причём тут ООП? Я знаю массу программ на С++, где ООП и не пахнет. А где ООП катит, так оно отлично ложится и даже на самые мелкие МК.
В общем, такая дискуссия пуста, т.к. безпредметна. Надо конкретные аргументы приводить. А в таком ключи можно и на С наехать, дескать, нафиг не нужен, асм форева (проходили 10 лет назад).
Цитата(dxp @ Dec 20 2011, 13:24)
Сложный - да, но как бы эти порядки определить?
Это общеизвестный факт и ничего тут не требуется определять.
Цитата
Кому не даёт реальных ++? Мне даёт.
Вас уже спрашивал колобок о реальных плюсах, вы ему так и не сказали ничего кроме абстрактных "облегчение как проектирования софта, так и написания кода" - только я тоже самое могу сказать со своей стороны про С и это разговор ниочем - спор правши и левши какой рукой удобней ложку держать. Применительно к данной теме - зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?
Цитата
И опять вопрос (его почему-то приходится всегда задавать оппонентам): а причём тут ООП?
Не - это уже феерично - расхваливать преимущества C++ над С и при этом не использовать ни метапрограммирование ни ООП
Господа, может быть не будем заниматься поддержанием многовекового холивара C vs. C++? :-) Пусть каждый выберет себе язык программирования, или пусть пишет сразу в машинных кодах. Главное, чтобы ему удобно было)
Я скажу может крамольную вещь и даже кому-то будет обидно, но ничего - переживете
1. Невозможно действительно грамотно писать на АСМ не зная в достаточной степени процедурно-ориентированного языка программирования
2. Невозможно действительно грамотно писать на Си не зная в достаточной степени С++.
Я уверен, что именно те кто ещё на вы с текущим инструментарием (читай языком), как раз любят теоретизировать о бесполезности языка следующего уровня абстракции.
1. Невозможно действительно грамотно писать на АСМ не зная в достаточной степени процедурно-ориентированного языка программирования
2. Невозможно действительно грамотно писать на Си не зная в достаточной степени С++.
Я уверен, что именно те кто ещё на вы с текущим инструментарием (читай языком), как раз любят теоретизировать о бесполезности языка следующего уровня абстракции.
Цитата(demiurg_spb @ Dec 20 2011, 14:09)
Я уверен, что именно те кто ещё на вы с текущим инструментарием (читай языком), как раз любят теоретизировать о бесполезности языка следующего уровня абстракции.
Специально для вас и прочих теоретиков Не дайте Астронавтам Архитектуры вас запугать
При чём здесь это?
Как часто принимаются новые стандарты с++?
Как они повлияли на необходимость смены технологии и как следствие была-ли велика потребность в изучении лишнего-ненужного материала?
Как часто принимаются новые стандарты с++?
Как они повлияли на необходимость смены технологии и как следствие была-ли велика потребность в изучении лишнего-ненужного материала?
Я не знаю языка C++, хотя и прочитал Г. Шилдта до половины. Без практики знаниями не запасешься. Но знаю точно, что рано или поздно перейду на него. Возможно, к тому времени появится новый язык, возможно, он уже есть. Снова буду догонять. Мир становится сложнее, задачи становятся сложнее, и для решения этих задач нужно применять соответствующие инструменты.
Цитата(sasamy @ Dec 20 2011, 14:28)
Специально для вас и прочих теоретиков Не дайте Астронавтам Архитектуры вас запугать
Ну так не надо витать в облаках. Можно писать ООП на С, и можно писать в чисто процедурном стиле на С++. Но есть хорошее народное наблюдение - шуруп, забитый в стену молотком, держится гораздо лучше, чем гвоздь, закрученный отверткой . С++ позволяет писать в стиле 'С с классами', и даже в таком стиле это гораздо лучше, чем просто С (и для МК в том числе)Не использовать С++ имеет смысл в одном случае - если ты его не знаешь, т.к. этот язык обладает гораздо большей гибкостью, в части создания уродцев, чем С
Так что используйте инструмент, которым владеете, и не поддавайтесь на провокации взять что то новое, исключительно потому, что оно новое
А то будет, как у MS:
Цитата
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Автор - Ron Burk из WDJ.
QUOTE (sasamy @ Dec 20 2011, 11:50)
Применительно к данной теме - зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?
А не зае**тесь сначала множить switch/case там, где должен быть вызов виртуальной функции, а потом шерстить весь код, чтобы найти все switch и не забыть в какой-нибудь из них добавить очередной case?Цитата(Сергей Борщ @ Dec 20 2011, 13:59)
А не зае**тесь сначала множить switch/case там, где должен быть вызов виртуальной функции...
А я вот сделал несколько массивов указателей на функции, и не зае**лся. Или это не про то речь?
QUOTE (sasamy @ Dec 20 2011, 16:50)
Это общеизвестный факт и ничего тут не требуется определять.
Общеизвестный факт конкретно о чём? А я про порядки спрашивал. Сколько порядков и как это определить? Например, насколько сложнее написать С++ класс по сравнению с С структурой? Конкретный вопрос. На сколько порядков?
QUOTE (sasamy @ Dec 20 2011, 16:50)
Вас уже спрашивал колобок о реальных плюсах, вы ему так и не сказали ничего кроме абстрактных "облегчение как проектирования софта, так и написания кода" -
Это вы попутамши - там не было вопросов о плюсах "плюсов", там началось с того, что было категорично заявлено: "нафиг не надо", а вопросы были с обратной стороны: "что именно нафиг не надо?".
Вы хотите конкретики? На какие темы из С++? Про отделение интерфейса от реализации и построение кода по более безопасной модели (классы и инкапуляция и абстракция данных) надо рассказывать? А про возможность быстро, просто и безопасно расширять функциональность объектов путём повторного использования кода (наследование) надо рассказывать? А про параметризованные типы, когда можно, например, получить кольцевой буфер для uint8_t, а можно для float или вообще структур:
ring_buffer<uint8_t, 32> TxBuf;
ring_buffer<float, 10> DataPool;
надо рассказывать? Мне вот думается, что нет, т.к. по вашим постам я знаю, что вы далеко не новичок в нашем деле и должны прекрасно знать эти возможности и их преимущества. Надеюсь, не нужно доказывать, что это простые и полезные средства языка, практически не тянущие оверхеда, весьма кстати при разработке софта в том числе и на МК. ЯП С не даёт ничего похожего. При той же реализации кольцевых буферов, это придётся в каждом случае делать руками со всеми вытекающими (трудозатраты, ошибки), а тут можно хоть структуры метать или типизированные указатели (а не void*).
QUOTE (sasamy @ Dec 20 2011, 16:50)
какой рукой удобней ложку держать. Применительно к данной теме - зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?
Про это мне не известно, это автор темы знает, что ему лучше подходит. Но вообще-то там вопрос был не о способе выбора, а о размещении реализации. Симпатичное, ПМСМ, решение было предложено с буфером и placement new. Кстати, именно вместе со switch.
QUOTE (sasamy @ Dec 20 2011, 16:50)
Не - это уже феерично - расхваливать преимущества C++ над С и при этом не использовать ни метапрограммирование ни ООП
Куда более феерично заявлять, что без метапрограммирования и ООП это уже не С++. Я вам выше привёл основные средства языка, они покрывают 90% потребностей программ для МК и отлично работают.
Что касается метапрограммирования, то С++ вообще не рассчитан на это и не предназначался для этих целей. То, что его и тут сумели применить, добавляет ему очков. А ООП - это лишь одно и, я бы сказал, даже не основное средство языка. Хотя если применять к месту, то отличный механизм для организации полиморфного поведения - аналог сишних таблиц указателей на функции, только лаконичный (писанины в разы меньше), безопасный (нет проблем с правильной инициализацией таблиц) и куда более сопровождаемый.
QUOTE (ViKo @ Dec 20 2011, 13:13)
А я вот сделал несколько массивов указателей на функции, и не зае**лся. Или это не про то речь?
Речь была о switch/case:QUOTE (sasamy @ Dec 20 2011, 11:50)
зачем тут виртуальные ф-ции когда можно сделать простой switch/case ?
А вам три вопроса:
1) А как, по-вашему, реализованы виртуальные функции в плюсах?
2) А не зае**тесь ползать по своим массивам добавляя новые/удаляя ненужные функции? Попутно: не боитесь добавить новую функцию не в ту ячейку массива или удалить не ту функцию?
3) Ну и ради чего этот закат солнца вручную, если в плюсах такой же механизм реализуется в виде виртуальных функций автоматически, без лишней писанины и без опасности глупых ошибок/опечаток?
Цитата(Сергей Борщ @ Dec 20 2011, 15:43)
А вам три вопроса:
1) А как, по-вашему, реализованы виртуальные функции в плюсах?
2) А не зае**тесь ползать по своим массивам добавляя новые/удаляя ненужные функции? Попутно: не боитесь добавить новую функцию не в ту ячейку массива или удалить не ту функцию?
3) Ну и ради чего этот закат солнца вручную, если в плюсах такой же механизм реализуется в виде виртуальных функций автоматически, без лишней писанины и без опасности глупых ошибок/опечаток?
1) А как, по-вашему, реализованы виртуальные функции в плюсах?
2) А не зае**тесь ползать по своим массивам добавляя новые/удаляя ненужные функции? Попутно: не боитесь добавить новую функцию не в ту ячейку массива или удалить не ту функцию?
3) Ну и ради чего этот закат солнца вручную, если в плюсах такой же механизм реализуется в виде виртуальных функций автоматически, без лишней писанины и без опасности глупых ошибок/опечаток?
Если это ко мне вопросы, то:
1) Я плюсов не знаю, увы мне!
2) За..трахивало маленько, но у меня был план (макет, шаблон, стиль?), которого придерживался. Все более-менее структурировано. Мимо не промахивался.
3) Я плюсов не знаю, увы мне!
P.S. Намекните, кто-нибудь, что это такое, виртуальные функции?
upd. Сам прочитал.
QUOTE (Сергей Борщ @ Dec 20 2011, 20:43)
1) А как, по-вашему, реализованы виртуальные функции в плюсах?
А я как раз сегодня про это читал у Страутстрапа
Через таблицу указателей...
Цитата(XVR @ Dec 20 2011, 14:44)
Не использовать С++ имеет смысл в одном случае - если ты его не знаешь
Если ты хорошо знаешь С использовать С++ нет вообще никакого смысла.
http://yosefk.com/c++fqa/picture.html#fqa-6.5
Цитата
One thing is always true: where you can use C++, you can use C. In particular, if someone gave you C++ interfaces, a thin layer of wrappers will hide them. Using C instead of C++ has several practical benefits: faster development cycle, reduced complexity, better support by tools such as debuggers, higher portability and interoperability. When C++ is an option, C is probably a better option.
По сути С++ дублирует функционал С и во многих случаях уступает ему при этом.
QUOTE (sasamy @ Dec 21 2011, 10:01)
Если ты хорошо знаешь С использовать С++ нет вообще никакого смысла.
Не используйте, разрешаем. Если ты хорошо знаешь ассемблер, использовать С нет вообще никакого смысла.Цитата(sasamy @ Dec 21 2011, 12:01)
По сути С++ дублирует функционал С и во многих случаях уступает ему при этом.
Может приведете конкретные примеры этих многих случаев? Было бы очень интересно почитать.
Цитата(Сергей Борщ @ Dec 21 2011, 12:12)
Если ты хорошо знаешь ассемблер, использовать С нет вообще никакого смысла.
Не нужно утрировать - хотя я понимаю что вы не со зла чушь сказали - видимо аргументов в пользу С++ просто нет. Кстати у C++ нет ни единого ABI ни name mangling, так что ассемблер даже лучше чем С++
QUOTE (sasamy @ Dec 21 2011, 16:01)
Это точка зрения одного человека. Она может быть ошибочной, а может быть правильной. На самом деле он прав! Только правда у каждого своя. Зачем навязывать правду? Делится ее - пожалуйста, навязывать не надо.
Про навязывание, это я не Вам, уважаемый sasamy
QUOTE (sasamy @ Dec 21 2011, 16:40)
Не нужно утрировать - хотя я понимаю что вы не со зла чушь сказали - видимо аргументов в пользу С++ просто нет. Кстати у C++ нет ни единого ABI ни name mangling, так что ассемблер даже лучше чем С++
Вот это да... А это что же тогда? Там есть раздел про Си++.
Видимо, он имел ввиду единый, общий для разных компиляторов name mangling. Он же не стандартизован и все компиляторы делают его по своему, хотя за последний стандарт языка не знаю.
QUOTE (sasamy @ Dec 21 2011, 10:40)
хотя я понимаю что вы не со зла чушь сказали - видимо аргументов в пользу С++ просто нет.
Мне они не нужны - я его использую. Хотелось бы как раз от вас услышать аргументы, разъсняющие, в чем же я так "заблуждаюсь". Кстати, аргумент в виде сообщений №38 и №41 вы игнорируете намеренно? Толстовато троллите, ох толстовато.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.