|
|
  |
Вопрос по С++ |
|
|
|
Dec 24 2011, 15:12
|
Местный
  
Группа: Свой
Сообщений: 252
Регистрация: 9-10-08
Из: Московская обл.
Пользователь №: 40 797

|
Цитата(sasamy @ Dec 24 2011, 16:09)  Ищите по-лучше - там много где макросы используются. А кто говорит что макросы в С++ вообще не нужны? Что я пропустил? Условная компиляция там везде, это и есть основное назначение макросов в С++. Цитата(sasamy @ Dec 24 2011, 16:09)  Одного мало ? Где? Когда? Я опять что-то пропустил? Цитата(sasamy @ Dec 24 2011, 16:09)  Кстати - если макросы совсем не нужны в С++ - на кой хрен в C++11 включили поддержку variadic macro из стандарта C99 ? В общем кому нужен С++ - используйте на здоровье - мне он не нужен, может только иногда  Ну вот опять.. напротив, макросы в С++ нужны, с этим никто не спорит. Просто там где в С использовались макросы, в С++ взамен появились более надежные, гибкие и удобные конструкции, во многих местах, но не везде - условную компиляцию по другому не реализуешь, да и громоздкие конструкции на базе шаблонов иногда удобно засунуть в макрос просто ради удобства чтения кода. С последним тезисом тоже спорить бессмысленно, каждому свое
|
|
|
|
|
Dec 24 2011, 16:52
|
Гуру
     
Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847

|
Цитата(sasamy @ Dec 23 2011, 22:34)  Там один клоун просил использования макросов - но мне самому что-то не хочется больше писать. У вас не просили примеры применения макросов, от вас просили удачных примеров на С, а вы дали ссылка на С++ библиотеку. То, что вам писать больше не хочется это заметно, ибо писать нечего Цитата Об это даже в заголовке написано по ссылке - не думайте что все кругом совсем дебилы, я не думаю, что все. Пока вы один тут клоуном выступаете Цитата Я мог бы вам дать ссылки на исходники ядра Linux Не надо, я знаю, где ядра лежат Цитата где макросы очень эффективно используются Мы вроде про С++ говорили, а не про макросы? Цитата но вы же ответите в своем стиле - я это напишу красиво - один класс с парой виртуальных ф-ций Все ядро Linux написано в ООП стиле. А то, что не на С++ объясняется исключительно идеосинкрозией Торвальдса на С++ Цитата при этом не приводя ни строчки своего кода, Пардон, я не понял, что вы хотели увидеть код. Я так думал, что вы вылезли сюда исключительно полить помоями С++ и всех его приверженцев. Цитата поэтому я вам дал ссылку на библиотку С++ - можете начать отсюда Нафига оно мне? Я и так boost использую. И то, что возможности препроцессора С не полностью покрываются возможностями С++ я тоже знаю, но ведь речь шла не об этом. К сожалению, я не смогу привести пример вашего куска кода на С++, т.к. по этому куску совершенно непонятно, что он должен был делать. Но чисто внешне, это должно быть чем то таким: Код template<class Dev1, class Dev2> class CmdLineDevChoise { Dev1 dev1; Dev2 dev2; public: void init() { char* name=get_cmd_line_device_name(); if (strcmp(name,dev1.get_name())==0) dev1.init(); else if (strcmp(name,dev2.get_name())==0) dev2.init(); else abort(); } };
// Usage: CmdLineDevChoise<MmcDev,SPI1Dev> ssp1; И так же чисто внешне, этот кусок должен быть сделан немного по другому PS. Последний крендель, с черезмерным ЧСВ, который пытался научить всю конференцию С++, ссылаясь на каких то старших товарищей из IBM, и проявляя при этом невежество, упертость и хамство, закончил баном. Вы уверенно шагаете по его стопам
|
|
|
|
|
Dec 24 2011, 17:12
|
Гуру
     
Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847

|
Цитата(sasamy @ Dec 24 2011, 21:06)  Это вы о себе ? Нет, о вас. Я не пытаюсь тут (и где либо еще) рассуждать о вещах, в которых ничего не понимаю, и не даю советов о том, чего не понимаю другим Цитата И не боюсь я ваших бананов  Это модераторам решать
|
|
|
|
|
Dec 24 2011, 17:55
|
Cундук
    
Группа: Участник
Сообщений: 1 478
Регистрация: 13-11-06
Из: Ростов-на-Дону
Пользователь №: 22 269

|
Цитата(dxp @ Dec 24 2011, 10:44)  Речь идёт не о прямом соответствии - понятно, что объекты реального мира всегда сложнее, разнообразнее, шире и подробнее. Программно создаются только модели этих объектов с разной степенью подробности тех или иных аспектов реального объекта. Вот о моделях и речь. При проектировании гораздо проще и удобнее оперировать более-менее законченной моделью, нежели сонмом переменных и функций, составляющих эту модель. Опять же. Вы пытаетесь спрятать проблемы, абстрагироваться от них. Извините за сравнение, как пресловутый страус. На самом деле, весь этот сонм переменных и функций никуда физически не исчезает. Он прячется по разным, порой труднодоступным закоулкам, которые программист предусмотрел для них. Инкапсуляция называется. Ведь рано или поздно Вам, таки, придется излагать математическую модель для каждой из электрических машин в отдельности. Т. е. реально вы будете иметь ряд виртуальных функций для управления по моменту и по скорости. Но Вам один фиг придется написать весь комплект математических моделей для каждой из машин в классах потомках. Цитата(dxp @ Dec 24 2011, 10:44)  Дык задал уже все вопросы в прошлый раз. Для... Приношу свои извинения за то, что заставил Вас написать столь длинный пример. Поверьте, я не со зла. Я только хотел сказать, что под общепринятым понятием может скрываться хренова туча разнородных объектов. Добавлю только, что трансформатор - тоже электрическая машина. А внешних свойств с остальными вращающимися машинами у него практически нет. Хотя его тоже можно включить и выключить.  И плавно переходим к кактусам. Сравниваем мой и Ваш. Я бы сделал в базовом классе вращающихся машин в первую очередь виртуальные функции, позволяющие осуществить управление по моменту и по скорости. Если бы у нас дополнительно стояла задача серво управления, то еще добавил бы виртуальных функций для точного перемещения. Что касается "стоячих" электрических машин трансформаторов и асинхронников с заторможенным фазным ротором, то здесь вообще для меня не ясно, что делать. Поскольку назначение этих девайсов совершенно иное, чем у вращающихся машин. И в результате наши классы получились бы полностью разными. Потому как построены на разных подходах при достаточно общей постановке задачи. А других постановок задач в нашем беспокойном и яростном мире ожидать не приходится. Цитата(dxp @ Dec 24 2011, 10:44)  Если же всё это писать на уровне переменных и функций, то это будет гора неструктурированного кода, где все связи между объектами (переменными и функциями) будут жить только в голове у программиста (вот где раздолье для кактусов  ). А код, который организует управление этими объектами будет очень похож на то, что в зарубежной литературе называют "spaghetti code". Развивать такой проект - требует изрядно сил и внимания на удержание в фокусе всех этих мелких и не очень объектов и нюансов их взаимодействия, а сопровождение такого кода ужасно. А вот здесь Вы неправы. Помимо мира "чистых" программистов существует такой же огромный мир программистов промавтоматики. А там код весь код именно такой - неструктурированный, где все связи между объектами изначально были только в головах механика и технолога, которые рисовали циклограммы технологического процесса. Потом к этому делу приложились программисты, которые и понятия не имеют о реальных механизмах машины и процессах, происходящих в ней. И ничего, тысячи людей зарабатывают тем, что сопровождают такие проекты. И даже модифицируют их, когда этого требует производство. Быстро и качественно. Иначе лишат сладкого. Там тоже есть свои кактусы. И свои методы. И специально обученные люди. И чтобы было понятно - поясню. Речь идет о нескольких миллионах строк кода. Цитата(dxp @ Dec 24 2011, 10:44)  Вы почему-то подразумеваете тут какой-то дополнительный объект, а на самом деле это (модель) то, что просто заменяет пачку переменных и функций, с помощью которого вы в программе контролируете поведение реального объекта. А с каких это пор модель перестала быть самостоятельным объектом? На самом деле у Вас есть два объекта - сам реальный объект и его виртуальная модель. И хорошо, если Вы не ошиблись, когда только начинали проектировать базовый класс. Или вдруг не поменялись свойства нижнего объекта таким образом, что Вам придется перелопачивать практически все. Иначе наварите таких макарон, что спагетти покажутся царским лакомством....
|
|
|
|
|
Dec 24 2011, 18:17
|
Знающий
   
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858

|
Цитата(XVR @ Dec 24 2011, 20:52)  Не надо, я знаю, где ядра лежат  И естественно не разбираетесь в нем. Цитата А то, что не на С++ объясняется исключительно идеосинкрозией Торвальдса на С++ Вы с ним лично знакомы ? хотя странно что вы не сказали в своем стиле - он С++ не знает  Цитата И то, что возможности препроцессора С не полностью покрываются возможностями С++ я тоже знаю, но ведь речь шла не об этом. А о чем ? лично я говорил именно об этом - препроцессор С намного удобней и мощней встроенных средств С++.
|
|
|
|
|
Dec 24 2011, 20:31
|
Местный
  
Группа: Участник
Сообщений: 214
Регистрация: 22-03-10
Из: Саратов
Пользователь №: 56 123

|
Цитата(sasamy @ Dec 24 2011, 22:17)  А о чем ? лично я говорил именно об этом - препроцессор С намного удобней и мощней встроенных средств С++. Покажите, пожалуйста, как с помощью препроцессора повторить некий кусок кода N раз, при условии, что N заранее не известно и передаётся откуда-нибудь из вне в виде целочисленного литерала. Очень типичная такая задача кодогенерации, надо например, короткую задержку NOP-ами сделать, и количество их как-то вычисляется. Я вам потом покажу, если захотите, как это делается на препроцессоре и на шаблонах. Будет возможность сравнить.
|
|
|
|
|
Dec 24 2011, 21:20
|
Знающий
   
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858

|
Цитата(neiver @ Dec 25 2011, 00:31)  Очень типичная такая задача кодогенерации, надо например, короткую задержку NOP-ами сделать Для вас типичная - для меня нетипичная и даже бесполезная в какой-то мере  кросплатформенность должна быть. В linux например богомипсы для точных задержек вычисляются при инициализации ядра и на основании их вычисляются точные програмные задержки. Цитата Я вам потом покажу, если захотите, как это делается на препроцессоре и на шаблонах. Будет возможность сравнить. Покажите, если хотите - я не против  кажется в avr-libc на препроцессоре задержки сделаны.
|
|
|
|
|
Dec 25 2011, 04:58
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
QUOTE (Прохожий @ Dec 25 2011, 00:55)  Опять же. Вы пытаетесь спрятать проблемы, абстрагироваться от них. Извините за сравнение, как пресловутый страус. Ну, тогда вы, используя тот же С, тоже прячетесь от проблем, абстрагируетесь от них. Давайте на асме - вот там будет полный набор ничем не прикрытых проблем. QUOTE (Прохожий @ Dec 25 2011, 00:55)  На самом деле, весь этот сонм переменных и функций никуда физически не исчезает. Он прячется по разным, порой труднодоступным закоулкам, которые программист предусмотрел для них. Инкапсуляция называется. Оно не прячется, а убирается с глаз долой, т.к. в месте использования совершенно не нужно и только мешает. Представьте себе, что вам по вашему подходу сделали автомобиль, чтобы управлять которым вам приходится не только руль крутить и педали нажимать, но и регулировать давление в безнопроводе, подкручивать в зависимости от оборотов двигателя угол опережения зажигания, устанавливать концентрацию бензина в смеси (побогаче делать или победнее) и ещё десяток регулировок, которыми в современной машине управляет бортовая электроника автоматически. Удобно будет этим пользоваться? Как часто будете ошибаться? С какой скоростью будете ехать? Как часто в аварии попадать? Даже если не пользоваться этими регулировками постоянно, а оставить их в каком-то оптимальном для большинства режимов работы положении, то просто наличие их на панели управления будет мешать и иногда всё равно какая-нибудь не та кнопка будет нечаянно нажиматься. Зато никакого страусизма - всё лежит на виду. Кстати, ваши любимые ПЛК - ярчайший пример подхода, который вы критикуете. Именно ПЛК и возникли как реализация идеи: спрятать все нюансы и сложности поглубже внутрь, наружу оставить только простой интерфейс, чтобы этим можно было легко пользоваться без риска наделать ошибок в реализации. При этом ещё остаётся возможность изменять реализацию без всякого риска порушить систему из-за несовместимости. Например, можно полностью переделать внутренности, заменить на плате главный микроконтроллер (скажем, с меги128 на какой-нить кортекс), повысить быстродействие, улучшить другие свойства, включая цену, и всё это без риска и проблем - отделение интерфейса от реализации в полный рост. Та самая инкапсуляция и абстракция. QUOTE (Прохожий @ Dec 25 2011, 00:55)  Ведь рано или поздно Вам, таки, придется излагать математическую модель для каждой из электрических машин в отдельности. Т. е. реально вы будете иметь ряд виртуальных функций для управления по моменту и по скорости. Но Вам один фиг придется написать весь комплект математических моделей для каждой из машин в классах потомках. Конечно. Я ведь в прошлый раз так и написал, что нужно очень чётко знать предметную область. Приведённый пример был, исходя из одного подхода. Если у вас другой, то и реализация тоже будет другой. Но общность подхода это не меняет - есть вполне чётко выделенный этап проектирования, который поддержан средствами языка, и это есть хорошо. Нужно только научиться этим пользоваться. QUOTE (Прохожий @ Dec 25 2011, 00:55)  А вот здесь Вы неправы. Помимо мира "чистых" программистов существует такой же огромный мир программистов промавтоматики. А там код весь код именно такой - неструктурированный, где все связи между объектами изначально были только в головах механика и технолога, которые рисовали циклограммы технологического процесса. Потом к этому делу приложились программисты, которые и понятия не имеют о реальных механизмах машины и процессах, происходящих в ней. Только сложность программ для микропроцессоров и для ПЛК несоизмерима. И сделано это намеренно - программирование ПЛК должно быть как можно более простым, т.к. рассчитано на менее подготовленных в программировании людей, основной упор в знаниях которых сделан на предметную область, в которой они работают. Именно это обстоятельство и породило ПЛК как класс. QUOTE (Прохожий @ Dec 25 2011, 00:55)  И ничего, тысячи людей зарабатывают тем, что сопровождают такие проекты. И даже модифицируют их, когда этого требует производство. Быстро и качественно. Иначе лишат сладкого. Там тоже есть свои кактусы. И свои методы. И специально обученные люди. И чтобы было понятно - поясню. Речь идет о нескольких миллионах строк кода. Вы сравниваете несравнимые вещи - уровень проектирования ПЛК и уровень разработки этих ПЛК. Моему сыну на прошлый день рождения подарили электронный конструктор, пацан 8 лет влёт собирает разные схемы ( миллионы строк... сотни схем) с генераторами, датчиками (звука, освещённости), в короткий сроки и без особых проблем, совершенно не разбираясь в электронике. Потому что, кто-то позаботился о том, чтобы спроектировать как собственно эти строительные кубики, так и методологию их использования. Точно так же как и в ПЛК. Но вот если спуститься с уровня использования ПЛК на уровень их проектирования, то в полной рост полезут протоколы обмена, работа с низкоуровневыми данными, многозадачность и т.д. и т.п. И средства программирования там совершенно иные. И уровень подготовки программистов требуется тоже совершенно иной.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Dec 25 2011, 07:43
|
Местный
  
Группа: Участник
Сообщений: 214
Регистрация: 22-03-10
Из: Саратов
Пользователь №: 56 123

|
Цитата(sasamy @ Dec 25 2011, 01:20)  Для вас типичная - для меня нетипичная и даже бесполезная в какой-то мере  кросплатформенность должна быть. В linux например богомипсы для точных задержек вычисляются при инициализации ядра и на основании их вычисляются точные програмные задержки. Ой сделайте мне такие точные задержки, чтоб до такта, и кросплатформанно чтоб на AVR, MSP430, STM8 и на всём с Cortex M3 ядром. Очень хочу!  Шутка. Цитата(sasamy @ Dec 25 2011, 01:20)  Покажите, если хотите - я не против  кажется в avr-libc на препроцессоре задержки сделаны. Я покажу вариант на шаблонах, вариант на препроцессоре остаётся за вами - покажите как с помощью этого мощнейшего инструмента кодогенерации решить такую тривиальнейшую задачу, как N раз повторить кусок кода. Задача решаемая и для неё есть готовые решения. Код template<unsigned N> inline void Nops() { asm volatile("nop"); Nops<N - 1>(); } template<> inline void Nops<0>(){} Всего 6 строчек кода. И кстати, кросплатформенно. Использовать просто: Код Nops<10>(); Причем N может быть не только целым литералом, это может быть любое целочисленное константное выражение. А на счет avr-libc, то там задержки сделаны в виде обычных функций с ассемблерными вставками: Код void _delay_loop_1(uint8_t __count) { __asm__ volatile ( "1: dec %0" "\n\t" "brne 1b" : "=r" (__count) : "0" (__count) ); } Они к сожалению не дают точности до такта, издержки на установление цикла не детерминированы и могут составлять от 1 и до примерно 10 тактов в зависимости от контекста использования. Ну да ладно, что мы привязались к этим задержкам, суть не в них, а в кодогенерации. Жду контрпримера...
|
|
|
|
|
Dec 25 2011, 10:37
|
Знающий
   
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858

|
Цитата(neiver @ Dec 25 2011, 11:43)  Я покажу вариант на шаблонах, вариант на препроцессоре остаётся за вами - покажите как с помощью этого мощнейшего инструмента кодогенерации решить такую тривиальнейшую задачу, как N раз повторить кусок кода. Препроцессор С Тьюринг-неполный и только средствами препроцессора циклы и прочее задача нетривиальная (если вообще разрешимая). Но вот какая штука - UNIX написана программистами для программистов и тут это сделать элементарно. rep_example.c Код #include "rep.h"
#define REPN(s, N) REP##N(s) #define EXPR_REP asm volatile("nop");
REPN(EXPR_REP, 10) Цитата sasa@sasa-laptop:~/tst$ ./rep.sh 100 && cpp rep_example.c # 1 "rep_example.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "rep_example.c" # 1 "rep.h" 1 # 2 "rep_example.c" 2
asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); asm volatile("nop"); rep.sh Код #!/bin/bash
echo "#define REP0(s) " > rep.h echo "#define REP1(s) s" >> rep.h
for N in $(seq 1 $[$1 -1]) do echo "#define REP$[N+1](s) s REP$N(s)" >> rep.h done То что сгенерировалось в rep.h Код #define REP2(s) s s #define REP3(s) s REP2(s) #define REP4(s) s REP3(s) #define REP5(s) s REP4(s) #define REP6(s) s REP5(s) #define REP7(s) s REP6(s) #define REP8(s) s REP7(s) #define REP9(s) s REP8(s) #define REP10(s) s REP9(s) #define REP11(s) s REP10(s) #define REP12(s) s REP11(s) #define REP13(s) s REP12(s) #define REP14(s) s REP13(s) .......... полностью думаю все 100 строк нет смысла писать
Сообщение отредактировал sasamy - Dec 25 2011, 15:23
|
|
|
|
|
Dec 25 2011, 10:46
|
Cундук
    
Группа: Участник
Сообщений: 1 478
Регистрация: 13-11-06
Из: Ростов-на-Дону
Пользователь №: 22 269

|
Цитата(dxp @ Dec 25 2011, 08:58)  Ну, тогда вы, используя тот же С, тоже прячетесь от проблем, абстрагируетесь от них. Давайте на асме - вот там будет полный набор ничем не прикрытых проблем. Когда сильно припекает - можно и на АСМ-е.  Но это бывает крайне редко. Практически никогда. А мне приходилось в юности и на PDP-11 в кодах... Но я никогда не провел бы прямой аналогии: код->Асм->С->С++. Пмсм, это выглядит вот так: код | Асм->С | С++. Цитата(dxp @ Dec 25 2011, 08:58)  Оно не прячется, а убирается с глаз долой, т.к. в месте использования совершенно не нужно и только мешает. Представьте себе, что вам по вашему подходу сделали автомобиль, чтобы... У меня нет автомобиля. Управлять я им не умею. Но аналогия понятна. И отражает она лишь исключительно Ваш жизненный и профессиональный опыт. Хоть мне и трудно - продолжу про автомобиль. Автоматическая коробка передач. По Вашей методологии на всех автомобилях должна быть только такая. Но это далеко не так. Даже на пафосных дорогих автомобилях есть оба варианта. Почему? Цитата(dxp @ Dec 25 2011, 08:58)  Кстати, ваши любимые ПЛК - ярчайший пример подхода, который вы критикуете. .... Та самая инкапсуляция и абстракция. Для начала - вовсе не критикую. Подход как подход. Годится для большого количества программистов В определенных ситуациях незаменим. Сам пользуюсь на верхнем уровне при изготовлении HMI. Но у него есть свои недостатки. И не везде он годится. Возвращаясь к Вашему примеру про ПЛК. Все, что Вы описали - естественный процесс. А то, что Вы делаете руками - искусство. И повторить реальность - не выйдет. Цитата(dxp @ Dec 25 2011, 08:58)  Конечно. Я ведь в прошлый раз так и написал, что нужно очень чётко знать предметную область. Приведённый пример был, исходя из одного подхода. Если у вас другой, то и реализация тоже будет другой. Но общность подхода это не меняет - есть вполне чётко выделенный этап проектирования, который поддержан средствами языка, и это есть хорошо. Нужно только научиться этим пользоваться. Соглашусь - инструментами надо владеть. Но и плодить лишние псевдосущности в виде не всегда нужных классов тоже не имеет смысла. Цитата(dxp @ Dec 25 2011, 08:58)  Только сложность программ для микропроцессоров и для ПЛК несоизмерима. И сделано это намеренно - программирование ПЛК должно быть как можно более простым, т.к. рассчитано на менее подготовленных в программировании людей, основной упор в знаниях которых сделан на предметную область, в которой они работают. Именно это обстоятельство и породило ПЛК как класс. Беда в том, что я плотно знаком со всеми подходами. Техническая сложность программирования ПЛК несоизмеримо Выше, чем МК. Особенно, когда код состоит из сотен тысяч строк на один ПЛК. А таких ПЛК в системе далеко не один. И все это связано сетью. Плюс к этому - верхний уровень и HMI глобального и локального уровня. Цитата(dxp @ Dec 25 2011, 08:58)  Вы сравниваете несравнимые вещи - уровень проектирования ПЛК и уровень разработки этих ПЛК. Моему сыну на прошлый день рождения подарили электронный конструктор, пацан 8 лет влёт собирает разные схемы (миллионы строк... сотни схем) с генераторами, датчиками (звука, освещённости), в короткий сроки и без особых проблем, совершенно не разбираясь в электронике. Потому что, кто-то позаботился о том, чтобы спроектировать как собственно эти строительные кубики, так и методологию их использования. Ну Вы же далеко не сноб. Зачем же принижать квалификацию профессионалов в той области, с которой Вы сталкиваетесь крайне редко? То, что Вы изложили - дилетантизм, простите за резкость. Я не буду ничего объяснять в этой ветке, поскольку она не о ПЛК. Если кому интересно - могу изложить отдельно. Цитата(dxp @ Dec 25 2011, 08:58)  Точно так же как и в ПЛК. Но вот если спуститься с уровня использования ПЛК на уровень их проектирования, то в полной рост полезут протоколы обмена, работа с низкоуровневыми данными, многозадачность и т.д. и т.п. И средства программирования там совершенно иные. И уровень подготовки программистов требуется тоже совершенно иной. Это отдельная тема. Только скажу одно - спроектировать ПЛК может любой выпускник ВУЗ-а. Для этого ничего не надо, кроме небольшого набора знаний, которые у него есть. А вот сделать проект средней по сложности линии - вряд ли. И это не голословное утверждение. Это многократно проверено на практике.
|
|
|
|
|
Dec 25 2011, 11:30
|
Гуру
     
Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847

|
Цитата(sasamy @ Dec 25 2011, 14:37)  Препроцессор С Тьюринг-неполный и только средствами препроцессора циклы и прочее задача нетривиальная (если вообще разрешимая). Но вот какая штука - UNIX написана программистами для программистов и тут это сделать элементарно. Угу, вместо 3 строк на С++ отдельный хидер и скрипт-генератор (для С). Да здравствует С и Unix! Кстати, ваш пример с 10 nop'ами можно даже в С сделать компактно и без генератора: Код #define R2(n) n; n #define R4(n) R2(n); R2(n) #define R8(n) R4(n); R4(n)
R8(asm volatile("nop")); R2(asm volatile("nop")) Я не утверждаю, что в С++ препроцессор не нужен (я и сам его часто использую), я утверждаю, что в С++ очень часто (но не всегда!) без него можно обойтись. PS. Что касается Линуса Торвальдса, то лично я с ним не знаком, но я знаком с его высказыванием на тему С++ (см например тут). Так же есть проект по написанию драйверов на С++ ( MOOL). Я не уверен, что Линус знает С++ в тонкостях, но если вам очень хочется это узнать, я могу у него спросить. Что касается моих познаний в Linux'е, то я думаю, что загружаемый драйвер (в С и С++ версиях), который я написал, дает некоторую уверенность, что я немного в кернеле разбираюсь  Очень древняя его С версия лежит тутPPS. Зарекался я вам что либо писать, но не удержался ...
|
|
|
|
|
Dec 25 2011, 11:59
|
Знающий
   
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858

|
Цитата(XVR @ Dec 25 2011, 15:30)  Да здравствует С и Unix! Да - согласен. Цитата Кстати, ваш пример с 10 nop'ами можно даже в С сделать компактно и без генератора: Кстати для особо одаренных - 1000 штук вы тоже будете вручную набивать ? речь помоему о кодогенерации. Цитата Что касается моих познаний в Linux'е, то я думаю, что загружаемый драйвер (в С и С++ версиях), который я написал, дает некоторую уверенность, что я немного в кернеле разбираюсь  То что вы написали говнокод на С++ влоб переписав кусок кода на С совершенно не разобравшись что он делает, при этом не поняли что это из ядра Linux, __setup - это стандартный макрос ядра и он в свою очередь тоже разворачивается в код, говорит что вы скорей всего знакомы поверхностно. http://lxr.free-electrons.com/source/inclu...nux/init.h#L245Вот что сгенерировал препроцессор. Причем код генерируется платформо-зависимый. Код # 740 "arch/arm/mach-mx23/device.c" static char *cmdline_device_ssp1; static int cmdline_device_ssp1_setup(char *dev) { cmdline_device_ssp1 = dev + 1; return 0; } static const char __setup_str_cmdline_device_ssp1_setup[] __attribute__ ((__section__(".init.rodata"))) __attribute__((aligned(1))) = "ssp1"; static struct obs_kernel_param __setup_cmdline_device_ssp1_setup __attribute__((__used__)) __attribute__ ((__section__(".init.setup"))) __attribute__((aligned((sizeof(long))))) = { __setup_str_cmdline_device_ssp1_setup, cmdline_device_ssp1_setup, 0 }; void mx23_init_ssp1(void) { if (!cmdline_device_ssp1 || !strcmp(cmdline_device_ssp1, "mmc")) mx23_init_mmc(); else if (!strcmp(cmdline_device_ssp1, "spi1")) mx23_init_spi1(); else printk("<3>" "Unknown %s assignment '%s'.\n","ssp1", cmdline_device_ssp1); } static char *cmdline_device_ssp2; static int cmdline_device_ssp2_setup(char *dev) { cmdline_device_ssp2 = dev + 1; return 0; } static const char __setup_str_cmdline_device_ssp2_setup[] __attribute__ ((__section__(".init.rodata"))) __attribute__((aligned(1))) = "ssp2"; static struct obs_kernel_param __setup_cmdline_device_ssp2_setup __attribute__((__used__)) __attribute__ ((__section__(".init.setup"))) __attribute__((aligned((sizeof(long))))) = { __setup_str_cmdline_device_ssp2_setup, cmdline_device_ssp2_setup, 0 }; void mx23_init_ssp2(void) { if (!cmdline_device_ssp2 || !strcmp(cmdline_device_ssp2, "nand_mfc")) mx23_init_nand_mfc(); else if (!strcmp(cmdline_device_ssp2, "spi2")) mx23_init_spi2(); else printk("<3>" "Unknown %s assignment '%s'.\n","ssp2", cmdline_device_ssp2); } Цитата PPS. Зарекался я вам что либо писать, но не удержался ... Не хотел ругать вас но вы сами таки напросились
Сообщение отредактировал sasamy - Dec 25 2011, 12:26
|
|
|
|
|
Dec 25 2011, 12:17
|

Любитель
    
Группа: Свой
Сообщений: 1 864
Регистрация: 20-08-06
Из: Тольятти
Пользователь №: 19 695

|
Цитата(Прохожий @ Dec 25 2011, 14:46)  Только скажу одно - спроектировать ПЛК может любой выпускник ВУЗ-а. Для этого ничего не надо, кроме небольшого набора знаний, которые у него есть. А вот сделать проект средней по сложности линии - вряд ли. И это не голословное утверждение. Это многократно проверено на практике. Ну да, конечно, то то я смотрю, у нас на заводе повсюду ПЛК одних и тех же солидных фирм, а вот программы для них пишут все подряд, включая тех же недавних студентов. А качество кода Вы оцениваете по его количеству, похоже - стопицот мильёнов строк - это крутизна, доступная только мегапрограммистам ПЛК? Впрочем, есть и родной, разработанный на заводе ПЛК, который здорово уступает по надёжности импортным. Наверняка студентами разработан
|
|
|
|
|
  |
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0
|
|
|