[Flexz 0]

Ищите по-лучше - там много где макросы используются.

А кто говорит что макросы в С++ вообще не нужны? Что я пропустил? Условная компиляция там везде, это и есть основное назначение макросов в С++.

 

Одного мало ?

Где? Когда? Я опять что-то пропустил?

 

Кстати - если макросы совсем не нужны в С++ - на кой хрен в C++11 включили поддержку variadic macro из стандарта C99 ?

В общем кому нужен С++ - используйте на здоровье - мне он не нужен, может только иногда :)

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

С последним тезисом тоже спорить бессмысленно, каждому свое :)

[xvr 12]

Там один клоун просил использования макросов - но мне самому что-то не хочется больше писать.

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

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

я не думаю, что все. Пока вы один тут клоуном выступаете :1111493779:

Я мог бы вам дать ссылки на исходники ядра 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, и проявляя при этом невежество, упертость и хамство, закончил баном. Вы уверенно шагаете по его стопам :maniac:

 

 

[sasamy 0]

проявляя при этом невежество, упертость и хамство

 

Это вы о себе ? Заметьте мое терпение закончилось по отношению к вам в самом конце. И не боюсь я ваших бананов :)

[xvr 12]

Это вы о себе ?

Нет, о вас. Я не пытаюсь тут (и где либо еще) рассуждать о вещах, в которых ничего не понимаю, и не даю советов о том, чего не понимаю другим

И не боюсь я ваших бананов :)

Это модераторам решать

 

[syv 0]

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

Опять же. Вы пытаетесь спрятать проблемы, абстрагироваться от них.

Извините за сравнение, как пресловутый страус.

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

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

Инкапсуляция называется.

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

Т. е. реально вы будете иметь ряд виртуальных функций для управления по моменту и по скорости.

Но Вам один фиг придется написать весь комплект математических моделей для каждой из машин в классах потомках.

Дык задал уже все вопросы в прошлый раз. Для...

Приношу свои извинения за то, что заставил Вас написать столь длинный пример.

Поверьте, я не со зла.

Я только хотел сказать, что под общепринятым понятием может скрываться хренова туча разнородных объектов.

Добавлю только, что трансформатор - тоже электрическая машина.

А внешних свойств с остальными вращающимися машинами у него практически нет.

Хотя его тоже можно включить и выключить. :)

И плавно переходим к кактусам.

Сравниваем мой и Ваш.

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

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

Что касается "стоячих" электрических машин трансформаторов и асинхронников с заторможенным фазным ротором, то здесь вообще для меня не ясно, что делать. Поскольку назначение этих девайсов совершенно иное, чем у вращающихся машин.

И в результате наши классы получились бы полностью разными.

Потому как построены на разных подходах при достаточно общей постановке задачи.

А других постановок задач в нашем беспокойном и яростном мире ожидать не приходится.

Если же всё это писать на уровне переменных и функций, то это будет гора неструктурированного кода, где все связи между объектами (переменными и функциями) будут жить только в голове у программиста (вот где раздолье для кактусов :) ). А код, который организует управление этими объектами будет очень похож на то, что в зарубежной литературе называют "spaghetti code". Развивать такой проект - требует изрядно сил и внимания на удержание в фокусе всех этих мелких и не очень объектов и нюансов их взаимодействия, а сопровождение такого кода ужасно.

А вот здесь Вы неправы.

Помимо мира "чистых" программистов существует такой же огромный мир программистов промавтоматики.

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

И ничего, тысячи людей зарабатывают тем, что сопровождают такие проекты. И даже модифицируют их, когда этого требует производство. Быстро и качественно. Иначе лишат сладкого.

Там тоже есть свои кактусы. И свои методы. И специально обученные люди.

И чтобы было понятно - поясню. Речь идет о нескольких миллионах строк кода.

Вы почему-то подразумеваете тут какой-то дополнительный объект, а на самом деле это (модель) то, что просто заменяет пачку переменных и функций, с помощью которого вы в программе контролируете поведение реального объекта.

А с каких это пор модель перестала быть самостоятельным объектом?

На самом деле у Вас есть два объекта - сам реальный объект и его виртуальная модель.

И хорошо, если Вы не ошиблись, когда только начинали проектировать базовый класс.

Или вдруг не поменялись свойства нижнего объекта таким образом, что Вам придется перелопачивать практически все.

Иначе наварите таких макарон, что спагетти покажутся царским лакомством....

 

[sasamy 0]

Не надо, я знаю, где ядра лежат

 

И естественно не разбираетесь в нем.

 

А то, что не на С++ объясняется исключительно идеосинкрозией Торвальдса на С++

 

Вы с ним лично знакомы ? хотя странно что вы не сказали в своем стиле - он С++ не знает :)

 

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

 

А о чем ? лично я говорил именно об этом - препроцессор С намного удобней и мощней встроенных средств С++.

 

[neiver 0]

А о чем ? лично я говорил именно об этом - препроцессор С намного удобней и мощней встроенных средств С++.

Покажите, пожалуйста, как с помощью препроцессора повторить некий кусок кода N раз, при условии, что N заранее не известно и передаётся откуда-нибудь из вне в виде целочисленного литерала. Очень типичная такая задача кодогенерации, надо например, короткую задержку NOP-ами сделать, и количество их как-то вычисляется. Я вам потом покажу, если захотите, как это делается на препроцессоре и на шаблонах. Будет возможность сравнить.

[sasamy 0]

Очень типичная такая задача кодогенерации, надо например, короткую задержку NOP-ами сделать

 

Для вас типичная - для меня нетипичная и даже бесполезная в какой-то мере :) кросплатформенность должна быть. В linux например богомипсы для точных задержек вычисляются при инициализации ядра и на основании их вычисляются точные програмные задержки.

 

Я вам потом покажу, если захотите, как это делается на препроцессоре и на шаблонах. Будет возможность сравнить.

 

Покажите, если хотите - я не против :) кажется в avr-libc на препроцессоре задержки сделаны.

[dxp 65]

Опять же. Вы пытаетесь спрятать проблемы, абстрагироваться от них.

Извините за сравнение, как пресловутый страус.

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

 

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

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

Инкапсуляция называется.

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

 

Удобно будет этим пользоваться? Как часто будете ошибаться? С какой скоростью будете ехать? Как часто в аварии попадать? Даже если не пользоваться этими регулировками постоянно, а оставить их в каком-то оптимальном для большинства режимов работы положении, то просто наличие их на панели управления будет мешать и иногда всё равно какая-нибудь не та кнопка будет нечаянно нажиматься. Зато никакого страусизма - всё лежит на виду.

 

Кстати, ваши любимые ПЛК - ярчайший пример подхода, который вы критикуете. Именно ПЛК и возникли как реализация идеи: спрятать все нюансы и сложности поглубже внутрь, наружу оставить только простой интерфейс, чтобы этим можно было легко пользоваться без риска наделать ошибок в реализации. При этом ещё остаётся возможность изменять реализацию без всякого риска порушить систему из-за несовместимости. Например, можно полностью переделать внутренности, заменить на плате главный микроконтроллер (скажем, с меги128 на какой-нить кортекс), повысить быстродействие, улучшить другие свойства, включая цену, и всё это без риска и проблем - отделение интерфейса от реализации в полный рост. Та самая инкапсуляция и абстракция.

 

 

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

Т. е. реально вы будете иметь ряд виртуальных функций для управления по моменту и по скорости.

Но Вам один фиг придется написать весь комплект математических моделей для каждой из машин в классах потомках.

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

 

 

А вот здесь Вы неправы.

Помимо мира "чистых" программистов существует такой же огромный мир программистов промавтоматики.

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

Только сложность программ для микропроцессоров и для ПЛК несоизмерима. И сделано это намеренно - программирование ПЛК должно быть как можно более простым, т.к. рассчитано на менее подготовленных в программировании людей, основной упор в знаниях которых сделан на предметную область, в которой они работают. Именно это обстоятельство и породило ПЛК как класс.

 

И ничего, тысячи людей зарабатывают тем, что сопровождают такие проекты. И даже модифицируют их, когда этого требует производство. Быстро и качественно. Иначе лишат сладкого.

Там тоже есть свои кактусы. И свои методы. И специально обученные люди.

И чтобы было понятно - поясню. Речь идет о нескольких миллионах строк кода.

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

 

Точно так же как и в ПЛК. Но вот если спуститься с уровня использования ПЛК на уровень их проектирования, то в полной рост полезут протоколы обмена, работа с низкоуровневыми данными, многозадачность и т.д. и т.п. И средства программирования там совершенно иные. И уровень подготовки программистов требуется тоже совершенно иной.

 

[neiver 0]

Для вас типичная - для меня нетипичная и даже бесполезная в какой-то мере :) кросплатформенность должна быть. В linux например богомипсы для точных задержек вычисляются при инициализации ядра и на основании их вычисляются точные програмные задержки.

Ой сделайте мне такие точные задержки, чтоб до такта, и кросплатформанно чтоб на AVR, MSP430, STM8 и на всём с Cortex M3 ядром. Очень хочу! :santa2: Шутка.

 

Покажите, если хотите - я не против :) кажется в 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 тактов в зависимости от контекста использования. Ну да ладно, что мы привязались к этим задержкам, суть не в них, а в кодогенерации. Жду контрпримера...

[sasamy 0]

Я покажу вариант на шаблонах, вариант на препроцессоре остаётся за вами - покажите как с помощью этого мощнейшего инструмента кодогенерации решить такую тривиальнейшую задачу, как 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 строк нет смысла писать

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

[syv 0]

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

Когда сильно припекает - можно и на АСМ-е. :)

Но это бывает крайне редко. Практически никогда.

А мне приходилось в юности и на PDP-11 в кодах...

Но я никогда не провел бы прямой аналогии:

код->Асм->С->С++.

Пмсм, это выглядит вот так:

код

|

Асм->С

|

С++.

Оно не прячется, а убирается с глаз долой, т.к. в месте использования совершенно не нужно и только мешает. Представьте себе, что вам по вашему подходу сделали автомобиль, чтобы...

У меня нет автомобиля. Управлять я им не умею. Но аналогия понятна.

И отражает она лишь исключительно Ваш жизненный и профессиональный опыт.

Хоть мне и трудно - продолжу про автомобиль.

Автоматическая коробка передач. По Вашей методологии на всех автомобилях должна быть только такая.

Но это далеко не так. Даже на пафосных дорогих автомобилях есть оба варианта.

Почему?

Кстати, ваши любимые ПЛК - ярчайший пример подхода, который вы критикуете. .... Та самая инкапсуляция и абстракция.

Для начала - вовсе не критикую.

Подход как подход. Годится для большого количества программистов

В определенных ситуациях незаменим.

Сам пользуюсь на верхнем уровне при изготовлении HMI.

Но у него есть свои недостатки.

И не везде он годится.

Возвращаясь к Вашему примеру про ПЛК.

Все, что Вы описали - естественный процесс.

А то, что Вы делаете руками - искусство.

И повторить реальность - не выйдет.

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

Соглашусь - инструментами надо владеть.

Но и плодить лишние псевдосущности в виде не всегда нужных классов тоже не имеет смысла.

Только сложность программ для микропроцессоров и для ПЛК несоизмерима. И сделано это намеренно - программирование ПЛК должно быть как можно более простым, т.к. рассчитано на менее подготовленных в программировании людей, основной упор в знаниях которых сделан на предметную область, в которой они работают. Именно это обстоятельство и породило ПЛК как класс.

Беда в том, что я плотно знаком со всеми подходами.

Техническая сложность программирования ПЛК несоизмеримо Выше, чем МК.

Особенно, когда код состоит из сотен тысяч строк на один ПЛК.

А таких ПЛК в системе далеко не один.

И все это связано сетью.

Плюс к этому - верхний уровень и HMI глобального и локального уровня.

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

Ну Вы же далеко не сноб.

Зачем же принижать квалификацию профессионалов в той области, с которой Вы сталкиваетесь крайне редко?

То, что Вы изложили - дилетантизм, простите за резкость.

Я не буду ничего объяснять в этой ветке, поскольку она не о ПЛК.

Если кому интересно - могу изложить отдельно.

Точно так же как и в ПЛК. Но вот если спуститься с уровня использования ПЛК на уровень их проектирования, то в полной рост полезут протоколы обмена, работа с низкоуровневыми данными, многозадачность и т.д. и т.п. И средства программирования там совершенно иные. И уровень подготовки программистов требуется тоже совершенно иной.

Это отдельная тема.

Только скажу одно - спроектировать ПЛК может любой выпускник ВУЗ-а. Для этого ничего не надо, кроме небольшого набора знаний, которые у него есть.

А вот сделать проект средней по сложности линии - вряд ли.

И это не голословное утверждение. Это многократно проверено на практике.

[xvr 12]

Препроцессор С Тьюринг-неполный и только средствами препроцессора циклы и прочее задача нетривиальная (если вообще разрешимая). Но вот какая штука - UNIX написана программистами для программистов и тут это сделать элементарно.

Угу, вместо 3 строк на С++ отдельный хидер и скрипт-генератор (для С). Да здравствует С и Unix! :cranky:

 

Кстати, ваш пример с 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. Зарекался я вам что либо писать, но не удержался ...

 

 

 

[sasamy 0]

Да здравствует С и 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. Зарекался я вам что либо писать, но не удержался ...

 

Не хотел ругать вас но вы сами таки напросились :)

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

[sonycman 1]

Только скажу одно - спроектировать ПЛК может любой выпускник ВУЗ-а. Для этого ничего не надо, кроме небольшого набора знаний, которые у него есть.

А вот сделать проект средней по сложности линии - вряд ли.

И это не голословное утверждение. Это многократно проверено на практике.

Ну да, конечно, то то я смотрю, у нас на заводе повсюду ПЛК одних и тех же солидных фирм, а вот программы для них пишут все подряд, включая тех же недавних студентов.

А качество кода Вы оцениваете по его количеству, похоже - стопицот мильёнов строк - это крутизна, доступная только мегапрограммистам ПЛК? :laughing:

 

Впрочем, есть и родной, разработанный на заводе ПЛК, который здорово уступает по надёжности импортным. Наверняка студентами разработан :)