Примеры инициализации периферии STM32F103 без использования библиотек

1. Настройка преобразования первых 8ми регулярных каналов АЦП по пинку из программы с использованием канала DMA
void ADC_init(void)
{
// настройка ADC1
RCC->APB2ENR |= RCC_APB2ENR_ADC1EN; // такты на ADC1
ADC1->SMPR2 |= ADC_SMPR2_SMP0 | ADC_SMPR2_SMP1
| ADC_SMPR2_SMP2 | ADC_SMPR2_SMP3 | ADC_SMPR2_SMP4
| ADC_SMPR2_SMP5 | ADC_SMPR2_SMP6 | ADC_SMPR2_SMP7; // количество циклов преобразования 239.5
ADC1->SQR1 |= ADC_SQR1_L_2 | ADC_SQR1_L_1 | ADC_SQR1_L_0; // длина последовательности регулярных каналов = 8;
// добавление в последовательность каналов
ADC1->SQR2 |= ADC_SQR2_SQ8_2 | ADC_SQR2_SQ8_1 | ADC_SQR2_SQ8_0 //канал 7
| ADC_SQR2_SQ7_2 | ADC_SQR2_SQ7_1; // канал 6
ADC1->SQR3 |= ADC_SQR3_SQ6_2 | ADC_SQR3_SQ6_0 //канал 5
| ADC_SQR3_SQ5_2 //канал 4
| ADC_SQR3_SQ4_1 | ADC_SQR3_SQ4_0 //канал 3
| ADC_SQR3_SQ3_1 //канал 2
| ADC_SQR3_SQ2_0; // канал 1
//канал 0 включен по умолчанию т.к. в младших битах SQ3 0
// ADC1->CR2 |= ADC_CR2_CONT; // включаем если нужно непрерывное преобразование последовательности в цикле
ADC1->CR2 |= ADC_CR2_DMA //включаем работу с DMA
| ADC_CR2_EXTTRIG //включаем работу от внешнего события
| ADC_CR2_EXTSEL //выбираем триггером запуска регулярной последовательности событие SWSTART
| ADC_CR2_JEXTSEL; // выбираем триггером запуска выделенной последовательности событие JSWSTART дабы эти каналы не отнимали у мк времени
ADC1->CR1 |= ADC_CR1_SCAN; // включаем автоматический перебор всех каналов в последовательности
//макросы для включения/выключения АЦП с DMA
#define ADC_ON ADC1->CR2 |= ADC_CR2_ADON; \
ADC1->CR2 |= ADC_CR2_SWSTART; \
DMA1_Channel1->CCR |= DMA_CCR1_TCIE | DMA_CCR1_EN; //включаем преобразование прерывание DMA
#define ADC_OFF ADC->CR2 &= (~(ADC_CR2_ADON)); \
DMA1_Channel1->CCR &= (~(DMA_CCR1_TCIE | DMA_CCR1_EN)); //выключаем преобразование и прерывание DMA
return;
}
Настройка DMA для АЦП
DMA1_Channel1->CPAR = ADC1_BASE+0x4C; // Загружаем адрес регистра DR
DMA1_Channel1->CMAR = pADC_readbuf_addr->Buf_Addr; //грузим адрес буфера обмена
DMA1_Channel1->CNDTR = 8; //длина буфера
DMA1_Channel1->CCR |= DMA_CCR1_MINC //инкремент адреса памяти
| DMA_CCR1_PSIZE_0 //размерность данных периферии 16 бит
| DMA_CCR1_MSIZE_0 //размерность данных памяти 16 bit
| DMA_CCR1_CIRC; // закольцевать буфер
2. Настройки SPI2 в режиме мастера для работы с DMA
void SPI_init(void)
{
// SPI2 init
RCC->APB1ENR |= RCC_APB1ENR_SPI2EN; // такты на SPI2
GPIOB->CRH &= (~(GPIO_CRH_CNF13_0 | GPIO_CRH_CNF15_0)); //настройка выводов для SPI
GPIOB->CRH |= (GPIO_CRH_MODE13 | GPIO_CRH_MODE15
| GPIO_CRH_CNF13_1 | GPIO_CRH_CNF15_1); // AF Push-Pull out
SPI2->CR1 |= SPI_CR1_BR_1 //настройка делителя
// | SPI_CR1_BR_0 //комментируя или раскомментируя эти строки можно изменять значение делителя
// | SPI_CR1_BR_2
| SPI_CR1_SSM // программное управление слэйвом
| SPI_CR1_SSI // при программном управлении слэйвом данный бит должен быть 1
| SPI_CR1_MSTR // Режим мастера
| SPI_CR1_SPE; // разрешить SPI2
SPI2->CR2 |= SPI_CR2_RXDMAEN // разрешить передачу принятых данных через DMA
| SPI_CR2_TXDMAEN; // Разрешить принимать данные для передачи через DMA
return;
}
Настройка DMA для работы с SPI2 на прием и передачу
RCC->AHBENR |= RCC_AHBENR_DMA1EN; //такты
// 4 канал DMA1 RX SPI2 -> память
DMA1_Channel4->CPAR = SPI2_BASE+0x0C; // адрес DR
DMA1_Channel4->CMAR = pSPI2_readbuf_addr->Buf_Addr; //адрес буфера приема
DMA1_Channel4->CNDTR = 12; // размер транзакции
DMA1_Channel4->CCR |= DMA_CCR4_MINC //инкремент адреса буфера
| DMA_CCR4_PSIZE_0; //размерность данных SPI 16 бит (происходит автоматическое преобразование 16->8 бит)
// 5 канал DMA1 память -> TX SPI2
DMA1_Channel5->CPAR = SPI2_BASE+0x0C; //адрес DR
DMA1_Channel5->CMAR = pSPI2_writebuf_addr->Buf_Addr; //адрес буфера передачи
DMA1_Channel5->CNDTR = 12; // размер транзакции
DMA1_Channel5->CCR |= DMA_CCR5_MINC //инкремент адреса буфера
| DMA_CCR5_DIR; // направление передачи из памяти в периферию
Транзакция запускается следующим куском кода:
void SPI2_start (void) // По сути это переинициализация каналов DMA
{
DMA1_Channel4->CPAR = SPI2_BASE+0x0C; //DR Base
DMA1_Channel4->CMAR = pSPI2_readbuf_addr->Buf_Addr;
DMA1_Channel4->CNDTR = 12;
DMA1_Channel5->CPAR = SPI2_BASE+0x0C; //DR Base
DMA1_Channel5->CMAR = pSPI2_writebuf_addr->Buf_Addr;
DMA1_Channel5->CNDTR = 12;
DMA1_Channel4->CCR |= DMA_CCR4_TCIE | DMA_CCR4_EN;
DMA1_Channel5->CCR |= DMA_CCR5_EN;
return;
}
Результаты обрабатываются по прерыванию завершения работы канала DMA работающего на прием данных от SPI:
void DMAChannel4_IRQHandler (void)
{
DMA1_Channel4->CCR &= (~(DMA_CCR4_TCIE | DMA_CCR4_EN)); // выключаем канал приемника и его прерывание
DMA1->IFCR |= DMA_IFCR_CTCIF4 | DMA_IFCR_CGIF4; //очищаем флаги
DMA1_Channel5->CCR &= (~(DMA_CCR5_EN)); // выключаем канал передатчика
pCurrent_mode->stat.led_data_send = 0; // выставляем нужные флаги для дальнейшей работы с данными
HC595_OUT;
pCurrent_mode->stat.read_key_data_ready=1;
return;
}
3. Инициализация USART:
void UART_init(void)
{
// USART3 init
RCC->APB1ENR |= RCC_APB1ENR_USART3EN; // такты на USART3
GPIOB->CRH &= (~(GPIO_CRH_CNF10_0)); //Настройка порта передатчика
GPIOB->CRH |= (GPIO_CRH_MODE10 | GPIO_CRH_CNF10_1); // AF Push-Pull out (TX)
// GPIOB->CRH &= (~(GPIO_CRH_CNF11)); // Настройка порта приемника
// GPIOB->CRH &= (~(GPIO_CRH_MODE11));
// GPIOB->CRH |= (GPIO_CRH_CNF11_1);
// GPIOB->BSRR |= GPIO_ODR_ODR11; // Input Pull-up (RX)
USART3->CR1 |= USART_CR1_UE; // Разрешить USART3
USART3->BRR = 0x0271; // 57600 baud
USART3->CR1 |= USART_CR1_TE; //Разрешить передатчик
}
Передача байта:
while ((USART3->SR & USART_SR_TXE) != USART_SR_TXE);
USART3->DR = 'D';
4. Инициализация таймера TIM1 для генерации ШИМ по двум каналам
// Timer1 init
RCC->APB2ENR |= RCC_APB2ENR_TIM1EN; //такты
TIM1->CCER = 0; //обнуляем CCER (выключаем каналы)
TIM1->ARR = 100; // максимальное значение, до которого таймер ведет счет
TIM1->PSC = 7200-1; // предделитель
TIM1->BDTR |= TIM_BDTR_MOE; // Разрешаем вывод сигнала на выводы
//для первого ШИМ-сигнала используем канал 1
TIM1->CCR1 = 50; //задаем скважность в регистр сравнения канала (значения от 0 до TIM1->ARR)
TIM1->CCMR1 |= TIM_CCMR1_OC1M_1 | TIM_CCMR1_OC1M_2; // Включаем режим канал в режим ШИМ
TIM1->CCER |= TIM_CCER_CC1E; // Разрешаем вывод не инвертированного сигнала на ногу МК
//для второго ШИМ-сигнала используем канал 4
TIM1->CCR4 = 50; //задаем скважность в регистр сравнения канала (значения от 0 до TIM1->ARR)
TIM1->CCMR2 |= TIM_CCMR2_OC4M_1 | TIM_CCMR2_OC4M_2; // Включаем канал в режим ШИМ
TIM1->CCER |= TIM_CCER_CC4E; // Разрешаем вывод не инвертированного сигнала на ногу МК
TIM1->CR1 |= TIM_CR1_CEN; // Запускаем счет
Теперь для управления скважностью нужного канала меняем значения в регистрах TIM1->CCR1 и TIM1->CCR4. Т.к. у нас глубина счета установлена 100, то задавая значение от 0 до 100 получим скважность в процентах :)
5. Отключение выводов JTAG и ремап SPI1
// alternative func enable
RCC->APB2ENR |= RCC_APB2ENR_AFIOEN;
AFIO->MAPR |= AFIO_MAPR_SWJ_CFG_JTAGDISABLE; // disable JTAG
// remap SPI1 to port B
AFIO->MAPR |= AFIO_MAPR_SPI1_REMAP;
Сами ноги для ремапнутого SPI1 надо инициализировать явно (т.е. настройки портов GPIO после включения ремапа никак не изменятся.
- +8
- 19 февраля 2013, 17:28
- Ultrin
код 100% рабочий, т.к. выковырян из текущего проекта, в котором на DMA висят 2 SPI и АЦП, + 1 из каналов используется для перекачки данных памяти из буфера в буфер. Все это работает одновременно.
Управляется выставлением флагов в контрольной переменной. Флаги соответственно придумывайте сами под свои задачи.
Управляется выставлением флагов в контрольной переменной. Флаги соответственно придумывайте сами под свои задачи.
из мелких кортексов у меня только тот что на дискавери установлен, да и та лежит в ящике и не используется… так что по компаратору не подскажу. Остальные камни все 103c8t6.
А мне f0 и наверное f3 показались как-бы более продуманными, чем f1. Хотя я только начал разбираться с микроконтроллерами, но, например SPI в f0 не только 8 или 16, а от 4 до 16, и есть битик NSSP — если его установить то контроллер после каждой передачи будет дергать nss, у АЦП есть режимы auto-off и появился бит ADRDY теперь не так «включите и потупите, маленько, пока не стабилизируется» а «включите и подождите пока ADRDY». Как-то так. Но вот компатор, примитивная периферия, а туплю с ним люто.
А мне f0 и наверное f3 показались как-бы более продуманными, чем f1.Ну это неудивительно, F1 первые, и потому сыроваты. Уже начиная с F2 периферию подфиксили. F0 и F3 еще позже появились.
Ну это неудивительно, F1 первые, и потому сыроваты. Уже начиная с F2 периферию подфиксили. F0 и F3 еще позже появились.
Порядок появления семейств STM32:
1/ F2
2/ F1
3/ F4
4/ F0
5/ F3
- well-man2000
- 22 февраля 2013, 11:04
- ↑
- ↓
Да, точно:
Jun 2007 F1
Apr 2010 L1
Nov 2010 F2
Sep 2011 F4
Feb 2012 F0
Jun 2012 F3
Jun 2007 F1
Apr 2010 L1
Nov 2010 F2
Sep 2011 F4
Feb 2012 F0
Jun 2012 F3
- well-man2000
- 22 февраля 2013, 12:07
- ↑
- ↓
Только разобраться в этом без datasheet не раельно.Полностью поддерживаю.
Как раз для ИНИЦИАЛИЗАЦИИ удобнее пользовать STD LIB.
Сравним.
Вот что предлагается ТС
USART3->CR1 |= USART_CR1_UE; // Разрешить USART3
USART3->BRR = 0x0271; // 57600 baud
USART3->CR1 |= USART_CR1_TE; //Разрешить передатчик
А вот с использованием библиотеки
/* Configure USART1 */
USART_InitStructure.USART_BaudRate = 57600;
USART_InitStructure.USART_WordLength = USART_WordLength_8b;
USART_InitStructure.USART_StopBits = USART_StopBits_2;
USART_InitStructure.USART_Parity = USART_Parity_No;
USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
USART_Init(USART1, &USART_InitStructure);
USART_Cmd(USART1, ENABLE);
В первом случае — некие магические числа, во втором вполне осмысленные значения, которые легко воспринять и через год и через два.
Это уже потом, когда не грех и поторопиться, пишем сразу в регистры
USART1->DR = USARTTxBuffer[USARTTxCounter++];
В конкретном случае у либы есть один большой недостаток: в обязательном порядке нужно инициализировать все поля структуры, иначе можно наступить на очень неприятные грабли с плавающими ошибками. Так что хотя я и обеими руками за читабельность, но приводить SPL в качестве примера я бы не стал. Ну и, на мой вкус, она, все-таки, слишком многословна. Даже в приведенном вами примере слово USART встречается слишком часто, хотя в подавляющем большинстве случаев это бесполезный шум ухудшающий читабельность.
приводить SPL в качестве примера я бы не стал.Топик называется «Примеры инициализации периферии STM32F103 без использования библиотек».
И я обращал внимание, что инициализация с использованием SPL выходит яснее, чем пример приведенный Автором.
Ну и, на мой вкус, она, все-таки, слишком многословна. Даже в приведенном вами примере слово USART встречается слишком часто
Ну, объявите вместо
USART_InitTypeDef USART_InitStructure;
примерно так
USART_InitTypeDef UIS;
И количество слов USART сократится примерно на 30%. :)
в подавляющем большинстве случаев это бесполезный шум ухудшающий читабельность.Про вкус фломастеров спорить не готов. :) Мне нравится. Я у себя примерно также поступаю
void LPS331_Init (void);
void LPS331_WriteByte(uint8_t addr,uint8_t data);
void LPS331_Read( uint8_t* pdata, uint8_t addr, uint8_t num);
............
//Определение адресов регистров LPS331
#define LPS331_REF_P_XL 0x08
#define LPS331_REF_P_L 0x09
#define LPS331_REF_P_H 0x0A
#define LPS331_WHO_AM_I 0x0F
...........
uint8_t LPS331_STATUS;
LPS331_Data_t LPS331_Press,LPS331_Temp;
uint16_t LTC2452_Data;
И количество слов USART сократится примерно на 30%. :)Чем засоряется текст не настолько существенно. В подобных ситуациях, на мой взгляд, гораздо читабельнее выглядит так называемый fluent синтаксис, но это реализуемо только на С++. Скажем, обсуждаемая инициализация могла бы выглядеть примерно так:
USART usart(USART1);
usart.baudRate(57600)
.wordLength(USART::WordLength_8b)
.parity(USART::Parity_No)
.flowControl(USART::None)
.mode(USART::Rx | USART::Tx)
.enable();
(это только один из возможных вариантов)
Помимо большей читабельности эта штука может разворачиваться в код практически 1:1 с вариантом описанным в топике, то есть весьма компактно.
Слишком сложная, неестественная конструкция. Если нужна абстракция в этом месте я бы предпочел передавать строку 9600N8 и т.п. или как в SPL если важно количество тактов.
Хотя я так думаю про большинство конструкций на C++ :)
Хотя я так думаю про большинство конструкций на C++ :)
Кстати, насчет строки. С ней действительно будет не очень хорошо, а вот такой вариант вполне можно сделать:
То есть для типовых режимов предусмотреть константы, а то, что ими не покрывается — доконфигурировать явно. Ну а если режим не стандартный, то конфигурировать так, как описано выше, задавая все параметры.
USART usart(USART1, USART::Config_57600N8RXTX);
usart.flowControl(USART::None)
.enable();
То есть для типовых режимов предусмотреть константы, а то, что ими не покрывается — доконфигурировать явно. Ну а если режим не стандартный, то конфигурировать так, как описано выше, задавая все параметры.
В данном случае нет никакого плюса либы, так как за значением полей структур точно так же надо лазить в какой-то файл и искать. Что в либе искать, что в файле от CMSIS, одинаково. А магические числа все в обычном двоичном формате и означают номер канала для АЦП и делитель для USART. Больше магических чисел нет, только поля регистров, которые так же понятны. (Кстати, когда я пишу с либой — использую даташит при заполнении полей структур ничуть не меньше, чем при написании без либы :D )
P.S. На самом деле данная тема не для выяснения плюсов и минусов метода или либо-срача. Лично для меня (я как-то уже писал) вопрос об использовании/не использовании либы непринципиален и его решение зависит от фазы луны и желания левой пятки правой ноги. Сегодня я пишу без либ, завтра с STMPeriphLib, послезавтра с самодельной либой и т.д.
P.S. На самом деле данная тема не для выяснения плюсов и минусов метода или либо-срача. Лично для меня (я как-то уже писал) вопрос об использовании/не использовании либы непринципиален и его решение зависит от фазы луны и желания левой пятки правой ноги. Сегодня я пишу без либ, завтра с STMPeriphLib, послезавтра с самодельной либой и т.д.
В данном случае нет никакого плюса либы, так как за значением полей структур точно так же надо лазить в какой-то файл и искать.В нормальных редакторах/IDE они сами вываливаются.

Ничего искать не надо. А вот биты регистров — действительно искать.
P.S. На самом деле данная тема не для выяснения плюсов и минусов метода или либо-срача.Ухожу, ухожу, ухожу… :)
Лично для меня (я как-то уже писал) вопрос об использовании/не использовании либы непринципиаленДля меня — то-же. См. мой ответ evsi: «я обращал внимание, что инициализация с использованием SPL выходит яснее, чем пример приведенный Автором.»
кейл раньше этого не умел. Сейчас проще.Вообще-то — это SlickEdit. Он такие вещи умел делать от рождения, т.е. всегда.
Кейлом не пользуюсь очень давно, в силу некоторых причин. Каких — не скажу, а то тут будет полный ПЦ.
Он такие вещи умел делать от рождения, т.е. всегда.Ты уверен? Он появился еще в древнедосовые времена, тогда автокомплита вроде еще не было.
ад из израиль
никак не пойму, почему быдлокодинг катится в сраное гавно?
почему все так сложно? хотя бы по сравнению с авр
никак не пойму, почему быдлокодинг катится в сраное гавно?
почему все так сложно? хотя бы по сравнению с авр
- kalobyte-ya
- 20 февраля 2013, 14:49
- ↓
т.н. «fluent синтаксис» мне нравится больше
GPIOB->CRH &= (~(GPIO_CRH_CNF10_0));
а это как-то уж за гранью зла
GPIOB->CRH &= (~(GPIO_CRH_CNF10_0));
а это как-то уж за гранью зла
- kalobyte-ya
- 20 февраля 2013, 15:05
- ↑
- ↓
GPIOB->CRH &= (~(GPIO_CRH_CNF10_0));По крайней мере, это полностью однозначно. Кстати, скобки здесь лишние.
а это как-то уж за гранью зла
GPIOB->CRH &= ~GPIO_CRH_CNF10_0;
Логические операции НЕ и И, больше ничего, обычная алгебра, не сложнее, чем в 1 классе, только битовая.Проще не сделаешь.
А т.н. «fluent синтаксис» — путь к
На мой взгляд, это достоинство — код получается недвусмысленный, а это самый важное условие простоты. Можно сравнить пример C++ из «Темной сторона C++» (PDF, стр. 23 и далее). Если в C мы видимА потом они рассказывают, что видите ли всё так сложно и глючно из-за «функционала».
baz = foo->bar(3);
то понимаем, что foo — указатель на структуру с полем bar, в котором указатель на функцию. Неясен только тип baz (он же тип значения bar).
А в C++ baz может быть reference, foo — классом с собственным оператором ->, bar — методом. Виртуальным, в большой иерархии классов. Или переопределенным на каком-то этапе. Перегруженным. Перегруженным с аргументами по умолчанию. Или вообще принимающим не int, а bool или enum, так что компилятор сообразит преобразовать типы. И неизвестно еще, что именно возвращает bar — может быть, нужно будет приводить тип к типу baz. И, кстати, может быть оператор = тоже переопределен. Как и оператор (). А может быть, при конверсии будет даже временный объект создан, с конструкторами и деструкторами. Может быть, тут шаблоны включаются — и не один. Кстати, текущее пространство имен неизвестно.
И автор оригинальной презентации находит еще есть какие-то варианты с typeof и алиасами, но тут уже я пас :)
А т.н. «fluent синтаксис» — путь кВ руках таких как вы — однозначно. Потому что то, что вы процитировали, не имеет никакого отношения к тому, что написал я.
Потому что то, что вы процитировали, не имеет никакого отношения к тому, что написал я.Имеет самое прямое отношение. Потому что это замена двух элементарных операций на какое-то очередное говно.
Имеет самое прямое отношение.Нет.
Потому что это замена двух элементарных операций на какое-то очередное говно.Говно, это то, что отстаиваете вы. Подозреваю отстаиваете потому, что вам никогда не доводилось заглядывать в собственный код спустя какое-то время или его сопровождать.
Говно, это то, что отстаиваете вы.Говно — это твои явы и оопы. Мне нравится техника за то, что в ней всё честно. Сколько не разводи политики, никаких добавочных коэффициентов в законе Ома не появится. Программирование для компа скатили в быдлокодинг, где всё занимает гигабайты, требует гигагерцы и качает обновление через интернет. В электронике пока ещё Си и Ассемблер. Если я смогу кого-нибудь убедить, что элементарная бинарная логика проще и надёжней, чем городить классы, может отдалиться тот день, когда вы своё сраное болото в каждый выключатель притащите.
или переносить его на другой МКНа компе так и не научились ничего переносить. Даже под вашим линухом под каждым дистрибутивом (которых развелось, как грязи) свои пакеты, которые больше ни к кому не подходят. А каждая программа на сраной яве тащит за собой кучу нативных бинарников, начиная от SQLite, заканчивая всякими нейронными сетями, потому что своего нифига нету кроме раздутых менеджеров и прочих паттернов (зато всё ресурсов жрёт как стадо слонов). Которые тоже нужно тащить трёх видов, несмотря на то, что к железу эти библиотеки не имеют никакого отношения. Как вы собрались переносить что-то для МК — секрет. Учитывая, что в разных МК (кроме какойнить игрушечной ардуйни) совершенно разный набор периферии, с разными возможностями.
Шли бы в какую-нибудь политику или литературу, нет, надо именно технику изгаживать
На компе так и не научились ничего переносить.Вы — да.
свои пакеты, которые больше ни к кому не подходят.Пакеты разные, но софтина одна. К тому же «ни к кому не подходят», мягко говоря, не правда.
Как вы собрались переносить что-то для МК — секрет.Для вас — да.
Шли бы в какую-нибудь политику или литературуЯ вам в попутчики не гожусь.
надо именно технику изгаживатьНе изгаживать, а развивать. А то с такими как вы телега осталась бы основным видом транспорта.
Холивары — это всегда вкусно. Но тут я вынужден поддержать lifeover-а, совершенно не надо городить больше кода когда можно сделать меньше. С другой стороны можно написать быдло-код в котором будет течь память и на простой си. В таком случае возникает потребность в инструментах более лучшего класса, где такие проблемы решены. ( С -> C# / Java ). Но код написанный на чистом си, или даже асме будет в любом случае лучше чем код на C# или Java который действительно ужасен, если копнуть глубже
С# как и жаба тянет за собой килотоны говнаОсобенно C#. Жабе стоит отдать должное, там небольшая JRE, которая мгновенно ставится и не мешается.
А вот дотнет… Это просто дикий ад. Нужно ставить все версии фреймворков. Инсталляторы разбросаны по сайту M$, что так просто не соберёшь (особенно, если учесть всякие сервис-паки, в которых надо ещё разобраться). Инсталляторы фреймворков тормозные, что-то докачивают (даже если считаются оффлайновыми), гадят временными папками на все(!) локальные диски и не удаляют их. Что-там evsi говорил, я не там ищу причины дерьмовости современного софта?
Хрен с ней, с установкой (хотя у меня и с ней не возникало проблем). Зато .net приложения после накатывания фреймворков (а в новых виндах этого даже и не требуется) неотличимы от нативных. В том числе и по скорости. Да и аппетиты до памяти вполне сравнимы с нативными.
Вот на WM2003 это напрягало — два фреймворка по пять метров ставились на рамдиск, а ОЗУ было 64МБ на все. На МК пока что фреймворк — дикий оверхед. Но на ПК все пучком.
Вот на WM2003 это напрягало — два фреймворка по пять метров ставились на рамдиск, а ОЗУ было 64МБ на все. На МК пока что фреймворк — дикий оверхед. Но на ПК все пучком.
Да и аппетиты до памяти вполне сравнимы с нативными.А это — тем более. По памяти с Си сравниться очень трудно. Тут принято её экономить. Хотя бы сравнить, сколько занимает мультистрока по сравнению с контейнером строк в какомнить оопе.
Ну и на С++ придётся память ОЧЕНЬ транжирить, чтобы сделать также хреново, как на интерпретируемых. Заводить под строки буферы максимальной длины и не подрезать после того, как изменений уже не будет, и прочее.
Тут принято её экономить.Что вовсе не значит, что это удается сделать. Причина в традиционных менеджерах памяти для С и в особенностях того, как в С идет работа с памятью. Скажем, фрагментация памяти может (и приводит) к ее значительному перерасходу. К слову, «выделить и обрезать» — один из способов увеличить фрагментацию памяти.
Причина в традиционных менеджерах памяти для С и в особенностях того, как в С идет работа с памятью.Хм, а они где-то ещё используются, традиционные менеджеры? В MSVC, который я в основном применяю, используется встроенный менеджер винды, например.
Хм, а они где-то ещё используются, традиционные менеджеры? В MSVC, который я в основном применяю, используется встроенный менеджер винды, например.Он не менее традиционен и от фрагментации не спасает. Принципиально решить вопрос с фрагментацией можно только с помощью GC, а это плохо сочетается с организацией работы с памятью в С.
В MSVC, который я в основном применяю, используется встроенный менеджер винды, например.Встроенный в винду — далеко не лучшая штука. Borland C++ ставит свой менеджер поверх виндового и в WinRAR'е (программа, между прочим, использующая интенсивные вычисления!) далеко обходит по производительности MSVC, хотя оптимизатор кода в BCC на уровне Delphi (т.е. на порядок отстает от MSVC).
В синтетических тестах.Тормозящую жабу встречал. Говорят, правда, что тормозит не сама жаба, а swing (один из ее гуи-тулкитов, вроде устаревший).
Тормозящего дотнета не встречал. Бывает, что поскрипываю зубами, видя, сколько оно выжрало ОЗУ (но максимум добрых слов обычно достается нативным программам — браузерам (без исключения), фокситу, скайпу, стиму, ноду, эксплореру — впрочем, в последнем 90% жрут довески, и часть из них как раз дотнетовская. и сильно радует, что дотнет-довески при сбоях не рушат эксплорер, да и сами сохраняют 90% работоспособности даже после тяжелых ошибок вроде out of memory или AV в подключенной нативной библиотеке).
Говорят, правда, что тормозит не сама жаба, а swing (один из ее гуи-тулкитов, вроде устаревший).Да, так они и говорят: «просто gc невовремя запустился», «просто всё остальное слишком быстро работает» и тому подобное по вкусу.
да и сами сохраняют 90% работоспособности даже после тяжелых ошибокХорошие нативные программки тоже прекрасно обрабатывают ошибки. Если их пишут не привыкшие к дотнетам и дельфи, где ошибки просто игнорятся.
Хорошие нативные программки тоже прекрасно обрабатывают ошибки. Если их пишут не привыкшие к дотнетам и дельфи, где ошибки просто игнорятся.Кстати, учитывая отсутствие SEH в С — при вылетании AV в недрах GDI+ из-за попытки загрузить кривой JPEG она благополучно грохнется (либо придется весь SEH ручками делать, что не столь уж просто). QTTabBar на дотнете только перестает картинки показывать (и то, иногда чинится сам собой, без перезапуска).
но максимум добрых слов обычно достается нативным программам — браузерам (без исключения), фокситу, скайпу, стиму, ноду, эксплореруЭЙ! не гони на фоксит ридер! только что открыл три десятка (35 если быть точным) пдфников общим объемом под триста (272) метров. скушал (читать: показал) и не подавился. при этом памяти съел 223метра. и открывал это все меньше минуты.
Фоксит жрет до полугига. Не опера, но при дефиците памяти (у меня типично 4.2GB system commit при наличии 2.75GB физической памяти) это заметно.
Нод и дискипер жрут скромнее, по три сотни на рыло. Скайп — от полугига после запуска до полутора через недельку, стим тоже от полугига до гига. Лидируют опера и эксплорер — 1-2ГБ.
Нод и дискипер жрут скромнее, по три сотни на рыло. Скайп — от полугига после запуска до полутора через недельку, стим тоже от полугига до гига. Лидируют опера и эксплорер — 1-2ГБ.
ой, про Р2Р не надо. у меня вот мюторрент висит и не подает признаков жизни. правда, те самые фотки млечного пути тянутся… ;) чего ему поплохело — хз. единственное что можно подозревать — на разделе для закачек всего пара гиг свободного места осталось.
а про хххDC я давно уже забыл. и не жалею.
кстати о «хороших маленьких програмках» в известно чьей классификации ;). меня этот самый мюторрент реально напрягает — чуть что, виснет и где-то лочится. помогает только полный ребут. то-ли дело transmission…
а про хххDC я давно уже забыл. и не жалею.
кстати о «хороших маленьких програмках» в известно чьей классификации ;). меня этот самый мюторрент реально напрягает — чуть что, виснет и где-то лочится. помогает только полный ребут. то-ли дело transmission…
У меня он имеет свойство не отзываться и не тянуть. Сбой вроде как-то связан с косяками тех костылей, что там накручены вокруг кэширования дискового IO и с обилием завершенных, но не удаленных торрентов.
Но менять мюторрент на что-то другое не хочется. Обычно оно или выглядит как макос — красиво, работает, но до тонких настроек не доберешься, или представляет из себя недописанный клон мюторрента.
Но менять мюторрент на что-то другое не хочется. Обычно оно или выглядит как макос — красиво, работает, но до тонких настроек не доберешься, или представляет из себя недописанный клон мюторрента.
и с обилием завершенных, но не удаленных торрентов.так в том и трабла, что последнее время больше пары-тройки торрентов у меня не бывает. а этот путь вообще один был. ну да ладно, опять подниму проксю, и вернусь к transmission.
Но менять мюторрент на что-то другое не хочется. Обычно оно или выглядит как макос — красиво, работает, но до тонких настроек не доберешься, или представляет из себя недописанный клон мюторрента.я давно торренты на проксю скинул. единственно, недавно сервер лег. пока перебиваюсь локальным мюторрентом.
Стоит заметить, из всего перечисленного на дотнете только пара расширений к эксплореру (из пары десятков установленных). Остальные дотнетовские программы при отборе по «кто тут всю память выжрал?!» скромненько остаются в списке «так, это мелочь, это тоже». Хотя одну я недавно выкинул из автозагрузки, решив что незачем тратить 50МБ памяти (на самом деле меньше, из этих 50МБ 90% — shared memory, т.е. длл-ки и иже с ними) и иконку в трее на то, что я в последний раз использовал пару лет назад.
Вопрос как всегда в деньгах. Кто заплатит та разработку быстрых, компактных программ?Самые лучшие программы — чаще всего написаны just for fun. Коммерческое говно в первую очередь должно производить впечатление на потребыдло, поэтому оно такое раздутое. А для опенсорса (в меньшей мере, просто бесплатного) и тем более энтузиастов это не нужно.
А вы разве не самым лучшим пользуетесь?Пользуюсь хорошими программками, разумеется, по возможности. Но не для всего есть очень хорошие программки, приходится довольствоваться тем, что есть. Иногда приходится отказываться от хорошего — линуховое ядро классное, но организация ФС, GUI, софт меня совершенно не устраивают.
И что? Много изменилось? В те времена оно походило на нечто пригодное только для «пописать под это софт на асме». ЕМНИП там не было даже толкового GUI API и возможности использовать динамически связываемые библиотеки, из-за чего везде гуй был ручками и на редкость примитивен (по поведению, видом он косил под всякие скины из ХР, лонгхорна и прочего гламура).
я не говорю только си, а самое главное я не говорю не использовать других инструментов. Пример Bison/Yacc как компилятор-компиляторов (http://ru.wikipedia.org/wiki/Yacc). Я далеко не против perl, php и всего остального, но зачем? когда можно сделать то же меньшими средствами. С другой стороны, код на перле
Вызывает вот такую беду:
Вырывает 2.5 метра в жопу
С другой стороны ся:
#!/usr/bin/perl
print "Hello, world!\n";
Вызывает вот такую беду:
int@home:~/perl# valgrind perl ./test.plКлючевое слово здесь
==9909== Memcheck, a memory error detector
==9909== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==9909== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==9909== Command: perl ./test.pl
==9909==
Hello, world!
==9909== Warning: bad signal number 0 in sigaction()
==9909==
==9909== HEAP SUMMARY:
==9909== in use at exit: 116,964 bytes in 521 blocks
==9909== total heap usage: 664 allocs, 143 frees, 145,987 bytes allocated
==9909==
==9909== LEAK SUMMARY:
==9909== definitely lost: 6,404 bytes in 16 blocks
==9909== indirectly lost: 110,560 bytes in 505 blocks
==9909== possibly lost: 0 bytes in 0 blocks
==9909== still reachable: 0 bytes in 0 blocks
==9909== suppressed: 0 bytes in 0 blocks
==9909== Rerun with --leak-check=full to see details of leaked memory
==9909==
==9909== For counts of detected and suppressed errors, rerun with: -v
==9909== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 6)
definitely lost: 6,404 bytes in 16 blocks
==9909== indirectly lost: 110,560 bytes in 505 blocks
This is perl 5, version 14, subversion 2 (v5.14.2) built for i486-linux-gnu-thread-multi-64intКод на php:
(with 77 registered patches, see perl -V for more detail)
#!/usr/bin/php
<?php
echo "hello world\n";
?>
Вырывает 2.5 метра в жопу
int@home:~/perl# valgrind php ./test.php
==10873== Memcheck, a memory error detector
==10873== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==10873== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==10873== Command: php ./test.php
==10873==
hello world
==10873==
==10873== HEAP SUMMARY:
==10873== in use at exit: 39,284 bytes in 2,568 blocks
==10873== total heap usage: 18,244 allocs, 15,676 frees, 2,529,924 bytes allocated
==10873==
==10873== LEAK SUMMARY:
==10873== definitely lost: 0 bytes in 0 blocks
==10873== indirectly lost: 0 bytes in 0 blocks
==10873== possibly lost: 0 bytes in 0 blocks
==10873== still reachable: 39,284 bytes in 2,568 blocks
==10873== suppressed: 0 bytes in 0 blocks
==10873== Rerun with --leak-check=full to see details of leaked memory
==10873==
==10873== For counts of detected and suppressed errors, rerun with: -v
==10873== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 67 from 12)
int@home:~$ php -v
PHP 5.4.4-12 (cli) (built: Jan 21 2013 19:13:44)
Copyright (C) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (C) 1998-2012 Zend Technologies
С другой стороны ся:
#include <stdio.h>
int main(void)
{
printf("hello world! \n");
return 0;
}
int@home:~$ gcc test.c -o test -Wall -g
int@home:~$ valgrind ./test
==11008== Memcheck, a memory error detector
==11008== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==11008== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==11008== Command: ./test
==11008==
hello world!
==11008==
==11008== HEAP SUMMARY:
==11008== in use at exit: 0 bytes in 0 blocks
==11008== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==11008==
==11008== All heap blocks were freed — no leaks are possible
==11008==
==11008== For counts of detected and suppressed errors, rerun with: -v
==11008== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 6)
int@home:~$
Using built-in specs.Где мои ошибки в этих примерах?
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
Как это? здесь есть задача вывести hello world на экран.
Вы, в своём тесте, взяли 3 совершенно разных инструмента, и сравнили их на синтетическом тесте по одному из параметров. Естественно интерпретируемые языки требуют больше ресурсов, чем нативный код. Это ясно даже без эксперимента, не стоило Вам так стараться.
Только какие выводы можно сделать из Вашего эксперимента?
Производительность и требования к ресурсам никогда небыли сильной стороной у интерполируемых языков. Но у них есть куча других плюсов.
Это как сравнить легковой автомобиль, грузовик и автобус по расходу топлива. Какой смысл сравнивать разные инструменты на неспецифических для них задачах?
Совершенно согласен, инструменты разные. Задача одна. Здесь я скорее хотел показать правильность выбора инструмента для задачи «hello world». И правильно, не имеет смысл использовать скриптовый (данные) языки для решения этой задачи, но не имеет смысла и использования и для более сложных задач, которые одинаково просто могут решатся на сях и других языках. Пример использование сложных сторонних библиотек прикрученных к жабе или сишарпу. Пример Emgucv на C# и простой OpenCV для C. Другой вопрос если человек не будет знать С(С++), но будет знать жабу. Тогда он возьмет естественно жабу, т.е далеко не оптимальный инструмент, и из-за его выбора буду страдать исключительно я (как конечный пользователь продукта)
но не имеет смысла и использования и для более сложных задач, которые одинаково просто могут решатся на сях и других языках.Ключевые слова «одинаково просто». Желательно так же их не только произносить, но и применять на практике. Потому как прикладных задач, которые «одинаково просто» делаются на С во многих направлениях уже просто не осталось. Причем, зачастую задач достаточно низкоуровневых, практически системных. Того, что раньше традиционно действительно делалось на С.
Имхо, все библиотеки будь-то венды будь-то лини имеют стандартные вызовы, которые легко вызываются из си. Другой вопрос что и там могут быть ошибки, но это другой вопрос. Намедни имело дело с libcurl в сях, при вызове http сайтов утечек нету, но как только HTTPS где то посреди lib openssl течет память. Если я все то же сделаю в пыхе я буду иметь в 10 раз большую утечку, и в 10 раз меньшую производительность. Раз я уже начал про curl я не думаю что это по сложности кода https://raw.github.com/bagder/curl/master/docs/examples/simple.c сильно отличается от этого http://curl.haxx.se/libcurl/php/examples/simpleget.html
Имхо, все библиотеки будь-то венды будь-то лини имеют стандартные вызовы, которые легко вызываются из си.И что?
Если я все то же сделаю в пыхе я буду иметь в 10 раз большую утечку, и в 10 раз меньшую производительность.Может быть. А может быть и нет. Зависит от того, как это реализовано в php. В жабе вся эта часть на самой же жабе и написана и там утечек нет. К слову, в данном случае лимитирующий фактор внешний ввод-вывод, так что производительность врядли будет отличаться в 10 раз. Если кормить реальными урлами из инета, то вообще врядли будет отличаться.
Господа, ну как может пыха быть быстрее и менее глючной си, на которой она кстати написана
код run.c
код simple.c curl для С (идентичен с примера)
код для пыхи (идентичен с примера)
То что думает valgrind про C
что valgrind думает про пыху:
int@home:~$ ./run
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
Curl C Elapsed time: 256 millisecs
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
Curl PHP Elapsed time: 274 millisecs
код run.c
#include <stdio.h>
#include <sys/time.h>
#include <unistd.h>
int main(void)
{
struct timeval start, end;
long mtime, secs, usecs;
gettimeofday(&start, NULL);
system("~/simple",NULL);
gettimeofday(&end, NULL);
secs = end.tv_sec - start.tv_sec;
usecs = end.tv_usec - start.tv_usec;
mtime = ((secs) * 1000 + usecs/1000.0) + 0.5;
printf("\n\nCurl C Elapsed time: %ld millisecs\n\n", mtime);
gettimeofday(&start, NULL);
system("php ~/simple.php");
gettimeofday(&end, NULL);
secs = end.tv_sec - start.tv_sec;
usecs = end.tv_usec - start.tv_usec;
mtime = ((secs) * 1000 + usecs/1000.0) + 0.5;
printf("\n\nCurl PHP Elapsed time: %ld millisecs\n\n", mtime);
return 0;
}
код simple.c curl для С (идентичен с примера)
#include <stdio.h>
#include <curl/curl.h>
int main(void)
{
CURL *curl;
CURLcode res;
curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "https://google.com/");
/* example.com is redirected, so we tell libcurl to follow redirection */
curl_easy_setopt(curl, CURLOPT_HEADER, 0L);
/* Perform the request, res will get the return code */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
/* always cleanup */
curl_easy_cleanup(curl);
}
return 0;
}
код для пыхи (идентичен с примера)
#!/usr/bin/php
<?php
//
// A very simple example that gets a HTTP page.
//
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, "https://google.com/");
curl_setopt ($ch, CURLOPT_HEADER, 0);
curl_exec ($ch);
curl_close ($ch);
?>
То что думает valgrind про C
==12105==Ошибки в openssl
==12105== HEAP SUMMARY:
==12105== in use at exit: 48,004 bytes in 3,104 blocks
==12105== total heap usage: 5,253 allocs, 2,149 frees, 292,138 bytes allocated
==12105==
==12105== LEAK SUMMARY:
==12105== definitely lost: 0 bytes in 0 blocks
==12105== indirectly lost: 0 bytes in 0 blocks
==12105== possibly lost: 0 bytes in 0 blocks
==12105== still reachable: 48,004 bytes in 3,104 blocks
==12105== suppressed: 0 bytes in 0 blocks
==12105== Rerun with --leak-check=full to see details of leaked memory
==12105==
==12105== For counts of detected and suppressed errors, rerun with: -v
==12105== Use --track-origins=yes to see where uninitialised values come from
==12105== ERROR SUMMARY: 3525 errors from 46 contexts (suppressed: 75 from 10)
что valgrind думает про пыху:
==12117==Имеет ли разница 2.8 метра или 288кб?
==12117== HEAP SUMMARY:
==12117== in use at exit: 89 bytes in 5 blocks
==12117== total heap usage: 21,589 allocs, 21,584 frees, 2,814,651 bytes allocated
==12117==
==12117== LEAK SUMMARY:
==12117== definitely lost: 0 bytes in 0 blocks
==12117== indirectly lost: 0 bytes in 0 blocks
==12117== possibly lost: 0 bytes in 0 blocks
==12117== still reachable: 89 bytes in 5 blocks
==12117== suppressed: 0 bytes in 0 blocks
==12117== Rerun with --leak-check=full to see details of leaked memory
==12117==
==12117== For counts of detected and suppressed errors, rerun with: -v
==12117== Use --track-origins=yes to see where uninitialised values come from
==12117== ERROR SUMMARY: 3505 errors from 47 contexts (suppressed: 138 from 14)
Господа, ну как может пыха быть быстрее и менее глючной си, на которой она кстати написанаО «быстрее» никто не говорил. Речь шла о «если и медленее, то на практике это не заметно».
Кстати, «глючен» не С (разве что с компиляторами такая беда иногда приключается), а код, который на нем написан.
Имеет ли разница 2.8 метра или 288кб?Зависит от того, что именно вы собираетесь делать.
Curl C Elapsed time: 256 millisecsО да, огромная разница. А если увеличить размер странички и лить ее с далекого-далекого сервера в интернетах?
Curl PHP Elapsed time: 274 millisecs
Имеет ли разница 2.8 метра или 288кб?Если вычесть статические потребности (0 для С, 2.5МБ для PHP) — потребление память оказывается одинаковым. Чем больше собственное потребление памяти программой, тем менее существенна будет разница. Например, 1.000ГБ против 1.002ГБ.
Точно. Как мой друг сказал,
напоминает про Резерфорда и его ученика, в журнале заметка была. Ученик очень гордился, что он много работает, Резерфорд его спрашивает: Что и в выходные? ДА! что и по ночам — да! Когда же вы думаете в таком случае?.. Так вот, когда же развиватели остановятся, чтобы подумать.Не остановятся пока сами не утонут в своём болоте.
Билл Гейтс сказал, что 640 кБ хватит всем.Я не фанат Билла Гейтс’а, но, справедливости ради, он такого не говорил.
Я не фанат Билла Гейтс’а, но, справедливости ради, он такого не говорил.Гм, а ты уверен? Как можно с очевидностью говорить о том, что дошло до тебя через 10 рук?
Что точно можно сказать — например, то, что браузер жрёт много памяти и медленно работает. Это факт. То, что я вижу своими глазами. А то, что кто-то написал или сказал — просто мнение.
Нет, FF жрет память на то, чтобы обеспечить отсутствующую в links функциональность. Если она тебе не нужна — возьми линкс. Если нужна — прекрати ныть, что за эту фуонкциональность приходится платить.
Впрочем, сравнение с оперой таки заставляет задуматься, действительно ли FF нужна эта память. Опера все же поэкономичней, при более-менее сравнимой функциональности.
Впрочем, сравнение с оперой таки заставляет задуматься, действительно ли FF нужна эта память. Опера все же поэкономичней, при более-менее сравнимой функциональности.
Не пользуюсь по возможности.ога. по прежнему плюеетесь и пользуетесь лисой. несмотря на.
«Ресурсов больше» — это ничего не сказать. Это пиздец просто. Быдлокодеры совсем с жиру взбесилисьопять про лису напомнить? и про привычный инет, в который вы каждый день ходите. а от линкса отказались. (догадываюсь по каким причинам)
если спокойно это хаваешь.меня это более чем устраивает. я предпочитаю личный комфорт ресурсам, а не экономию ради экономии.
Потому как прикладных задач, которые «одинаково просто» делаются на С во многих направлениях уже просто не осталосьНе осталось тех, кто хорошо напишет на Си эти вещи. Впрочем, те, кто не способен освоить указатели, работу с памятью, битовые потоки и операции, ничего хорошего не напишут ни на чём. Кто способен — всякое говно вроде яв не будет использовать.
Их есть и много.Мало тех, кто готов и хочет писать программки, которые просто будут делать свое дело. Мало тех, кто способен использовать указатели. Для большинства, одиночный указатель — проблема и ограниченные шаблоны использования, двойной — вынос мозга (мозжечка, скорее), тройной — даже не слышал. Битовые потоки операции — ещё сложнее. А ведь это простые вещи вроде молотка и гвоздей. Если мастер не умеет их использовать, то он никакой не мастер и никакие инструменты не помогут.
Только никому не нужна программа, которая устареет задолго до релиза.Хорошей программе вообще нечего устаревать. А всякая платная однодневная ерунда — не нужна.
Суть в том, что заклепочками ты самолет не собереш.Без заклёпочек — тоже. А не умея даже заклёпочку забить и не стукнуть по пальцу — тем более.
И что совреенные инструменты давно перешагнули сложность молотка.Да, какую-нить IDE, занимающую 10GB и запускающуюся пол часа трудно сравнить по практичности и простоте с молотком.
Я умею забить гвоздь. Но я не буду собрать самолет гвоздями.
Да, какую-нить IDE, занимающую 10GB и запускающуюся пол часа трудно сравнить по практичности и простоте с молотком.Равно как и десятитонный паровой молот. Или автоматический станок, сваривающий или склепывающий детали самолета. Молоток в глубоком пролете.
Мало тех, кто готов и хочет писать программки, которые просто будут делать свое дело.Их немало. Я как раз только таких на работу и беру.
Хорошей программе вообще нечего устаревать.Вы не поверите, но большинство программ пишутся не для того, что бы вы могли любоваться красотой исполнения, а для решения вполне реальных повседневных задач у вполне конкретных людей. А эти задачи имеют свойство изменяться, появляться и исчезать. И программа, которая не решает эти изменившиеся или новые задачи этим конкретным людям не нужна, с их точки зрения программа устарела.
Здесь я скорее хотел показать правильность выбора инструмента для задачи «hello world».
Это просто синтетический тест, который мало о чем говорит, и результаты (в данном случае) были заранее известны. Выбор оптимального инструмента – это очень сложная задача, нужно учитывать очень много факторов, а не просто сравнение по одному из критериев. Более того, в разных условиях, для одной и той же задачи, могут быть разные оптимальные инструменты.
В данном случае, если Вы уж находились в консоли, то оптимальным результатом для вывода на экран «hello world» могло бы быть
int@home:~$ echo "Hello World!"
Как сказать у нас то и критериев не много все от чего мы можем отталкиваться это конфиг системы пользователя, + удобность работы, но это скорее дизайн. Я не беру во внимание критерии «удобности» программисту. Если вы пишете программу и за это зарабатываете деньги, будьте любезны писать качественно
кстати в данном случае
кстати в данном случае
int@home:~$ valgrind echo «hello world\n»
==11449== Memcheck, a memory error detector
==11449== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==11449== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==11449== Command: echo hello\ world\\n
==11449==
hello world\n
==11449==
==11449== HEAP SUMMARY:
==11449== in use at exit: 0 bytes in 0 blocks
==11449== total heap usage: 30 allocs, 30 frees, 1,985 bytes allocated
==11449==
==11449== All heap blocks were freed — no leaks are possible
==11449==
==11449== For counts of detected and suppressed errors, rerun with: -v
==11449== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 6)
Как сказать у нас то и критериев не много все от чего мы можем отталкиваться это конфиг системы пользователя, + удобность работы, но это скорее дизайн
Нет, критериев очень много. Есть, например, трудозатраты на написание ПО, есть время, затраченное на разработку. Почему вы их так просто списываете со счетов? Могут быть специфические требования к переносимости программы на другие платформы без прекомпиляции и т. д.
Если вы пишете программу и за это зарабатываете деньги, будьте любезны писать качественно
Золотые слова (с). Только в разработке ПО никто, увы, не отменял закон «перехода количества в качество». Быстро, Качественно, Дёшево – выбирайте две опции из трех, чудес не бывает.
кстати в данном случае
Опять же все зависит от критериев оценки. Ели Вам нужно «одноразово» вывеси определенное сообщение в консоль – сомневаюсь, что вы будете писать программу на С.
Из принятие во внимание только одного критерия ничего хорошего не выходит. Это наглядно показывают гонка мегагерц, гонка мегапикселей и гонка миллисекунд отклика. Первая принесла тормозные 4-гигагерцовые печки netburst/prescott (шутка ли, C2D производительнее и экономичнее при втрое меньшей тактовой), вторая — шумные многомегапиксельные матрицы с песчинку размером (под говенным объективом, зачастую, который обеспечивал минимальный элемент изображения в сотню пикселей размером), третья — искусство измерения миллисекунд и 18-битные матрицы вместо 24-битных.
Знаете, в конкретно данный момент ваш «правильный выбор» С для написания HelloWorld не является правильным для меня. Более того, он совершенно невозможен.
В конкретно данный момент для меня правильной является
И даже C# вариант будет выигрывать у чистого С, потому как программа на C# будет выполнять поставленную перед ней задачу (компилятор нативный в .NET), а вот С программа так и останется лежать в исходниках.
В конкретно данный момент для меня правильной является
print "Hello, World!" -- Yes, this is Lua
Только потому что Lua у меня есть, а вот компилятора С нет.И даже C# вариант будет выигрывать у чистого С, потому как программа на C# будет выполнять поставленную перед ней задачу (компилятор нативный в .NET), а вот С программа так и останется лежать в исходниках.
То есть не причина? Давайте посмотрим, так ли притянуто за уши?
Что бы написать на Lua, я: открыл интерпретатор, вбил строку, получил результат. Пускай я потратил минуту времени и 1 метр памяти.
Что бы сделать то же самое на Си, я должен был бы: открыть браузер, найти компилятор, скачать его, установить его, написать код, скомпилировать, запустить. Сколько времени ушло на исполнение такой программы? Сколько оперативки оно заняло?
Что бы написать на Lua, я: открыл интерпретатор, вбил строку, получил результат. Пускай я потратил минуту времени и 1 метр памяти.
Что бы сделать то же самое на Си, я должен был бы: открыть браузер, найти компилятор, скачать его, установить его, написать код, скомпилировать, запустить. Сколько времени ушло на исполнение такой программы? Сколько оперативки оно заняло?
Про то, что «правильный выбор» в 90% случаев есть результат взвешенной оценки. А набор критериев и веса при них у каждого свои.
Производительность и требования к ресурсам никогда небыли сильной стороной у интерполируемых языков.Но и слабой стороной производительность многих «интерпретируемых» языков давно уже не является. В кавычках, поскольку в той же жабе и дотнете не так просто определить, интерпретируемый он или компилируемый. Когда появились первые реализации JIT еще как-то было понятно — вот байткод, а вот его скомпилированная версия. С появлением HotSpot-а все перемешалось в кучу, одна и та же часть кода может интерпретироваться, а спустя какое-то время превратиться в нативный бинарник скомпилированный на ходу под конкретный процессор.
Но и слабой стороной производительность многих «интерпретируемых» языков давно уже не является.Не является потому что раньше им приходилось завоёвывать право на жизнь. Тогда и придирались сильнее. Теперь, когда мозги зомбированы этой хренью, достаточно отговорок «вы ничего не понимаете, не несите ересь».
Как это?Вот так вот. Не подозревал, что подобное уточнение для вас в нове.
Чем больше кода тем больше ошибок, тем больше утечек тем больше патчей и стараний закрыть костыли костылями.Количество бинарного кода и количество исходного кода — две разные вещи. Перечисленные вами проблемы это проблемы, преимущественно, исходников, а не бинарников.
И даже если «ничего не делающая программа» умудряется сожрать 2.5мб памяти, это плохо.Это никак. И ничего не говорит о самой программе и/или количестве проблем в ней. Писанная на асме программа на несколько сотен байт все равно взаимодействует с операционкой, со всеми теми мегабайтами кода (вариант ембеддед пока оставим в стороне). Вас это, почему-то, не смущает.
т.е интерпретатор был написан не из исходников? т.е если напишу скажем так (что явно неправильно):
То мой выходной бинарник не будет иметь этой проблемы? Компилируется на ура, работает — нет.
Как вы думаете конечный пользователь предпочтет что бы программу в одно и тоже время можно было запустить >9000 раз или всего 1 при 4мб озу и скрипте на php.
void f(void)
{
char *a = malloc(3);
strcpy(a,"1234");
}
То мой выходной бинарник не будет иметь этой проблемы? Компилируется на ура, работает — нет.
Как вы думаете конечный пользователь предпочтет что бы программу в одно и тоже время можно было запустить >9000 раз или всего 1 при 4мб озу и скрипте на php.
что-то не вник в предложение. Из исходников и в них вся та же проблема. Чем больше кода — тем больше ошибок.Точно. По мере усложнения задачи размер кода на С будет расти быстрее. Что, как бы, намекает.
Но признаю иметь Jvm который таже написан на сях(с++) который также вызовет все тоже из либц + еще дополнительно куча говна значительно хуже чем просто иметь либцДа, я в курсе, что вы предпочитаете свое говно вместо проверенного.
А зачем? В libc вот всё самое необходимое. На все случаи жизни всё равно не напихаешь,В итоге программа использует кучу сторонних библиотек.
так что «очень функционален» — как раз подходит для синтетических тестов…Нет, для вполне реального софта. Был у меня, кстати, несколько лет назад подобный проект. Из стороннего только ant, да и тот только для сборки, а не часть программы.
Как и для жабы.Мой ответ вам не понравится, но, тем не менее, не только же вы его прочитаете. Так вот: сколько С-шных библиотек пишутся с тестами? для жабы этот процент весьма высок, из широко используемого — большинство. И покрытие тестами тоже весьма высоко, как правило авторы стремятся к 100% покрытию. Это значит, что все условные переходы и каждая строчка кода проверяется тестом. Это, безусловно, не гарантирует полное отсутствие ошибок, но количество ошибок в пересчете на строчку кода значительно ниже. Есть и другие существенные моменты. Скажем, если используется несколько С-шных либ и в каждой используется свой менеджер памяти, то скрестить их безболезненно в одной программе зачастую весьма нетривиальная задача, чреватая появлением ошибок или утечек. В жабе эта проблема отсутствует в принципе. Да и утечку устроить не так просто.
Так вот: сколько С-шных библиотек пишутся с тестами?Насколько я знаю, из широко используемого — почти всё. Вот, так, например.
Скажем, если используется несколько С-шных либ и в каждой используется свой менеджер памяти, то скрестить их безболезненно в одной программе зачастую весьма нетривиальная задача, чреватая появлением ошибок или утечек.Да, есть такое. Впрочем, обычно причина в авторах библиотек, которые зачем-то решили извратиться. А не в самом Си.
Да и утечку устроить не так просто.Да и без утечек памяти не напасёшься.
Насколько я знаю, из широко используемого — почти всё. Вот, так, например.Первый на вскидку взятый zlib нормальных тестов не имеет.
Впрочем, обычно причина в авторах библиотек, которые зачем-то решили извратиться.Прежде чем критиковать решение авторов библиотеки, видимо, стоит, все-таки, задуматься над причинами.
А не в самом Си.Ну да. Проблема в сложившейся традиционной инфраструктуре, в частности типичным решениям в аллокаторе.
Да и без утечек памяти не напасёшься.Думаю, JVM целенаправленно выбирает java haters и съедает на их компьютерах всю память.
Первый на вскидку взятый zlib нормальных тестов не имеет.Угу. Сам на баг напоролся когда-то, пришлось городить «workarround». Впрочем, и явалибы не такие уж безупречные.
Прежде чем критиковать решение авторов библиотеки, видимо, стоит, все-таки, задуматься над причинами.Причины представляю. Впрочем, это всё равно не повод городить. В крайнем случае, можно в отладочной версии нагородить что нужно, а в релизной применять стандартное.
Думаю, JVM целенаправленно выбирает java haters и съедает на их компьютерах всю память.И убунта, похоже, также поступает.
Но размер кода все равно будет меньше суммы (ваш код+универсальной vm/интерпретатора)Кстати, вы, почему-то, постоянно выводите за рамки качество и проверенность кода сводя все к арифметической сумме размеров. Что, вобщем-то, некорректно, поскольку код написанный вами проверяли, в лучшем случае, только вы. libc и jvm работают уже много лет у миллионов пользователей.
Да при том, что Hello World (ну, в данном случае это «экран чорным залить») на OpenGL будет намного проще и экономичнее к ресурсам, чем оно же на Unreal Engine 3. А вот Gears of War на чистом OpenGL уже будет в разы больше и сложнее, чем на UE3, а учитывая, что у авторов UE3 немалый опыт в написании быстрых и мощных движков — еще и намного глючнее, тормознее и прожорливей.
Надо различать статические издержки и динамические.
Надо различать статические издержки и динамические.
какая мне разница сколько из них ест сама жаба — 10метров или 10кил?Жаба — это вообще жесть. Как отхватит себе здоровенный кусок. Жаба она и есть жаба, даже если это софт. Причём предлагается догадаться сколько ей понадобится. Типичное издевательство «угадай сколько я хочу, а не то упаду, а дашь больше — всё равно спасибо не скажу». Вот и приходится своп раздувать до неприличных размеров.
Жабе и этого мало зачастую.покажите десктопную жабопрогу способую проглотить 4-8гиг и не подавиться.
(пережим фоток млечного пути и подобные операции не рассматриваем)
А своп включать не хочется, потому что винда так медленней работает и больше подтупливает.у вас что то не то в консерватории.
а в диком потреблении памяти жабой.спорно. очень. давайте пройдемся по функционально насыщенным IDE.
эклипс 250метров. (стартует 10сек)
слик сотню.
авростудия6 200метров (стартует полторы минуты)
авростудия4 полтинник.
кокос 130 (тот же эклипс строго говоря)
кодеблок полтинник
кейл полтинник
кактус11 110метров (без проекта)
надоело запускать.
вполне нормальные цифры.
Вы пропустили «почти ничего не делающие» в перечислении.«Ничего не делающие» в твоём представлении на деле означает «делающие кучу всякой херни, а основную задачу делающие паршиво». А «делающие» —
Делали бы новомодные «программисты» тот же Therac-25, он бы играл музыку, показывал фильмы и интернеты, а своё дело делал ещё хуже, чем оригинал. Начал бы качать обновления посреди сеанса и завис.
насчет асма — размер, скорость.По размерам исходного кода и скорости написания асм как бы не в лидерах. Кстати, по поводу скорости исполнения там тоже не все так просто и однозначно.
Насчет си — размер, скоростьРазмер кода работы, например, с базой данных и, опять-таки, скорость написания такого кода тоже будет оставлять желать лучшего.
Хотя все зависит от задачи.Именно. «Размер и скорость» это тоже не абсолютные характеристики без указания на то, размер и скорость чего имеются в виду.
С# как и жаба тянет за собой килотоны говнаСейчас каждая система тянет за собой «килотонны говна». На досуге попробуйте сделать du -sh /lib. Замечу, эти все килотонны написаны на С, что, как бы, намекает, что применение асма или С не гарантирует «размер и скорость».
Кстати, по поводу скорости исполнения там тоже не все так просто и однозначно.Об этом есть неплохой текст: "Не тормозит". Да, не надо смотреть на домен. Этот кусочек текста как раз таки по делу.
Сейчас каждая система тянет за собой «килотонны говна».Даже эта?

Или эта?

Или может эта?

Что-то я не заметил говна. Всё при себе, и всё только по делу.
«Размер и скорость» это тоже не абсолютные характеристики без указания на то, размер и скорость чего имеются в виду.Да, разумеется. Если качество важнее, размер и скорость — понятно чего. Если же на качество плевать, то эти слова приобретают другой смысл, который ты назвал.
Слушай, мы же не школьники. Пройдись-ка анализатором зависимостей на предмет что твои «легкие» программы требуют для запуска.
Ты опять пропускаешь суть. Даже, если программе требуется дополнительный компонент (например, SmartSniff лучше работает с winpcap (хотя может и без)), всё равно программка вполне хорошенькая.
Также и OpenGL.
А какое-нибудь говно на qt тащит за собой мешок зависимости просто чтобы диаложик отрисовать (да ещё в какомнить глянцевом стиле).
Также и OpenGL.
А какое-нибудь говно на qt тащит за собой мешок зависимости просто чтобы диаложик отрисовать (да ещё в какомнить глянцевом стиле).
Даже эта?Тянет, тянет. Оно лежит в %WINDIR%\System32. Называется kernel32.dll, user32.dll и еще куча аналогичных (это не считая того, что в свою очередь тянут эти DLL-ки). В сумме говна набегает на несколько дотнетов.
Или эта?
Или может эта?
Что-то я не заметил говна. Всё при себе, и всё только по делу.
Во первых, далеко не все. Ему не нужна хрень вроде user32, shell32 и иже с ними — у него есть свои механизмы для этих задач.
Во вторых, дотнет просто теряется на фоне всего этого. Все перечисленные тобой программы тянут за собой винду, которая даже в версии Windows 98 весила около полугигабайта.
И в третьих, .net FX — стандартная вещь. Равно как и JRE.
Есть только одна программка, которая легкая и ничего с собой не тянет. Это memtest86+.
Во вторых, дотнет просто теряется на фоне всего этого. Все перечисленные тобой программы тянут за собой винду, которая даже в версии Windows 98 весила около полугигабайта.
И в третьих, .net FX — стандартная вещь. Равно как и JRE.
Есть только одна программка, которая легкая и ничего с собой не тянет. Это memtest86+.
еще какой-то десяток лет назад, БИОС можно было прошить только с 5.25" дисковода, поскольку прошивающая часть БИОСа ничего другого кроме него и ISA-видеокарты(если хочется увидеть коды ошибок) не признавала.
Сейчас же, та же БИОС может прошить себя хоть с винчестера, хоть с флешки.
А еще сами программы-прошивальщики весьма привередливы к БИОСу, как и многочисленные утилиты конфигурации CMOS-памяти т.к. настройки там хранящиеся целиком зависят от версии БИОСа, и только малая часть этих данных как-то документирована.
Так же я только краем застал времена когда надо было указывать конфигурацию винчестера чтобы БИОС принял его, что было до этого — трудно себе представить. Например ноут TOSHIBA T-1200 или как он там правильно пишется, хоть он и x86 совместимый, но многие программы не шли из-за нестандартного БИОСа. Это сейчас интерфейс БИОСа как-то устаканился, но не факт что даже сейчас все безоблачно и все же где-то имеются конфликты и какая-то программа(под чистым ДОСом) не идет из-за особенностей конкретного БИОСа.
Взять тот же UEFI, пришедший ему на смену…
Сейчас же, та же БИОС может прошить себя хоть с винчестера, хоть с флешки.
А еще сами программы-прошивальщики весьма привередливы к БИОСу, как и многочисленные утилиты конфигурации CMOS-памяти т.к. настройки там хранящиеся целиком зависят от версии БИОСа, и только малая часть этих данных как-то документирована.
Так же я только краем застал времена когда надо было указывать конфигурацию винчестера чтобы БИОС принял его, что было до этого — трудно себе представить. Например ноут TOSHIBA T-1200 или как он там правильно пишется, хоть он и x86 совместимый, но многие программы не шли из-за нестандартного БИОСа. Это сейчас интерфейс БИОСа как-то устаканился, но не факт что даже сейчас все безоблачно и все же где-то имеются конфликты и какая-то программа(под чистым ДОСом) не идет из-за особенностей конкретного БИОСа.
Взять тот же UEFI, пришедший ему на смену…
- Alexeyslav
- 26 февраля 2013, 01:49
- ↑
- ↓
В этом я не сомневаюсь, и тут снова начинается тоже самое. Те же дот.неты в глубине используют тот же си а потом и вовсе асм. Но в силу того что, интерпретатор/компилятор/либа/еще_какой_кусок_говна имеет в себе ошибку из-за неграмотности (скорее всего), невнимательности, еще какого гемороя. Начинается разрастание этой ошибки по всем инстанциям. Так зачем плодить чужие ошибки, когда можно своих наделать.
Так в своем говне хотя бы копаться удобнее.
Так в своем говне хотя бы копаться удобнее.
Но в силу того что, интерпретатор/компилятор/либа/еще_какой_кусок_говна имеет в себе ошибку из-за неграмотности (скорее всего), невнимательности, еще какого гемороя.Тоже самое можно сказать о сложности, которая резко нарастает с увеличением громоздкости системы. И тоже хорошо аукается в конечном итоге.
Справедливости ради, скорее всего, в самой жабе ошибок весьма немного (хотя может просто хорошо прячут :) ). Но этого нельзя сказать о дополнительных библиотеках.
е же дот.неты в глубине используют тот же си а потом и вовсе асм. Но в силу того что, интерпретатор/компилятор/либа/еще_какой_кусок_говна имеет в себе ошибку из-за неграмотности (скорее всего), невнимательности, еще какого гемороя. Начинается разрастание этой ошибки по всем инстанциям.Ровно такая же проблема существует с операционками и сторонними либами. Предлагаете перестать их использовать и «копаться в своем говне»?
Но код написанный на чистом си, или даже асме будет в любом случае лучшеДаже если вспомнить милый агрегат therac-25, запрограммированный на ассемблере, которому сносило крышу просто от того, что опытный юзер успевал вбить все настройки процедуры менее чем за 8 секунд? Как бы там ни было, но на С# я таких шедевров пока не видел.
На ассемблере нужно выискивать не такие случат. С сишечкой получше, но AV неспроста держит пальму первенства среди выдаваемых сишными прогами ошибок. А вот для дельфи типичны софтовые исключения типа «List index out of bounds» и иже с ними — ты сам это признавал. И в 50% случаев после такой ошибки можно спокойно работать дальше, и во всех них виноваты исключительно авторы программы.
Проги на С# тоже сбоят, но гораздо реже, и таких ошибок как AV не выдает практически никогда. Плюс вместо бессмысленного дампа дотнет выдает полезную отладочную информацию, из которой часто можно выявить причину ошибки даже не будучи программистом. Так что качественного софта на шарпе куда больше.
Проги на С# тоже сбоят, но гораздо реже, и таких ошибок как AV не выдает практически никогда. Плюс вместо бессмысленного дампа дотнет выдает полезную отладочную информацию, из которой часто можно выявить причину ошибки даже не будучи программистом. Так что качественного софта на шарпе куда больше.
На компе так и не научились ничего переносить.Игры научились. Оно и неудивительно — продаж на одной платформе уже недостаточно, чтобы окупить дорогущую игру, приходится делать сразу под все, на чем можно продать.
Да и среди опенсорса немало кроссплатформенного.
Учитывая, что в разных МК (кроме какойнить игрушечной ардуйни) совершенно разный набор периферии, с разными возможностями.И что с того? Если это нормальный проект, а не «помигать диодиком», то периферийно-зависимая часть выносится в HAL размером 5-10% от проекта. Переписывать 10% или 100% — почувствуйте разницу.
Уважаемый. Ну продолжайте же в существующий топик. Зачем ещё и этот загаживать? :)
При всем уважении Вы не правы. Тем более, что отвечали на пост kalobyte-ya, совершенно не прочитав того что написал Evsy.
Запись
выглядит аккуратней и более читаема чем простая инициализация регистров, и НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ к строке:
Запись
USART usart(USART1);
usart.baudRate(57600)
.wordLength(USART::WordLength_8b)
.parity(USART::Parity_No)
.flowControl(USART::None)
.mode(USART::Rx | USART::Tx)
.enable();
выглядит аккуратней и более читаема чем простая инициализация регистров, и НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ к строке:
GPIOB->CRH &= (~(GPIO_CRH_CNF10_0));
Вы знаете как винда при прорисовке окна выводит пиксели фрейма? Какой бит куда устанавливает, какие блокировки использует, какой байт в какую область памяти пишет? Разве вам это требуется знать при создании программы?
Вы пишите свою собственную функцию с учетом всех нативных настроек системы (цвета, толщина, стиль...).
Или вы просто не уважаете пользователя, и говорите: «Ты мудак, и не понимаешь, что моя вырвиглазная палитра в приложение единственно доступное решение. А то что ты не можешь прочесть белый текст на ядовитом фоне — не моя проблема. А мое приложение работает зато очень быстро.»
Вы пишите свою собственную функцию с учетом всех нативных настроек системы (цвета, толщина, стиль...).
Или вы просто не уважаете пользователя, и говорите: «Ты мудак, и не понимаешь, что моя вырвиглазная палитра в приложение единственно доступное решение. А то что ты не можешь прочесть белый текст на ядовитом фоне — не моя проблема. А мое приложение работает зато очень быстро.»
Я не знаток C++ потому не могу Вам сказать все конкретные преимущества данного метода, но, из собственной практики, при работе над текущим проектом меня не раз посещали мысли что какой-то определенный кусок кода реализовать в виде классов с методами было бы гораздо удобней и писанины меньше. Но т.к. начал писать на СИ, то переделывать все в плюсы уже неохота. На них надо начинать писать с проектов попроще, чтоб мозг перестроить, т.к. там мыслить надо несколько иначе.
Перечитай это:
На мой взгляд, это достоинство — код получается недвусмысленный, а это самый важное условие простоты. Можно сравнить пример C++ из «Темной сторона C++» (PDF, стр. 23 и далее). Если в C мы видимТебе это действительно надо, чтобы без бутылки нельзя было разобраться? Вот кольцевой буфер, простейшая структурка, обратиться 3-4 строчки. neiver умудрился нагородить классов на несколько экранов, и ещё ошибку сделать. Если тебе кажется, что простой способ не подходит, ищи более простой! Иначе ты не инженер.
baz = foo->bar(3);
то понимаем, что foo — указатель на структуру с полем bar, в котором указатель на функцию. Неясен только тип baz (он же тип значения bar).
А в C++ baz может быть reference, foo — классом с собственным оператором ->, bar — методом. Виртуальным, в большой иерархии классов. Или переопределенным на каком-то этапе. Перегруженным. Перегруженным с аргументами по умолчанию. Или вообще принимающим не int, а bool или enum, так что компилятор сообразит преобразовать типы. И неизвестно еще, что именно возвращает bar — может быть, нужно будет приводить тип к типу baz. И, кстати, может быть оператор = тоже переопределен. Как и оператор (). А может быть, при конверсии будет даже временный объект создан, с конструкторами и деструкторами. Может быть, тут шаблоны включаются — и не один. Кстати, текущее пространство имен неизвестно.
И автор оригинальной презентации находит еще есть какие-то варианты с typeof и алиасами, но тут уже я пас :)
Вы же свои глупости повторяетеТо, что я говорю, глупости только с вашей точки зрения. Да и повторяю я только вам, остальные, по большей части, уже давно это поняли и без меня.
и в них, к сожалению, начинают верить.Ну не все же живут в выдуманном вами мире, а те, кто имеет дело с реальностью давно пришли к тем же выводам, что и я.
Ну не все же живут в выдуманном вами мире, а те, кто имеет дело с реальностью давно пришли к тем же выводам, что и я.Это тебе кажестся. Я уже давно понял, что 100% чего угодно — дерьмо, но тем лишь ценнее хорошие крупицы.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said «to piss you off», but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the «nice» library features of the language like STL and Boost and other
total and utter crap, that may «help» you program, but causes:
— infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
— inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic «object model» crap.
So I'm sorry, but for something like git, where efficiency was a primary
objective, the «advantages» of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a «real database». They use «nice object-oriented libraries».
They use «nice C++ abstractions». And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.
But I'm sure you'd like it more than git.
Linus
Смотришь на это, ощущение что у разработчиков/дизайнеров стойкий запор. Они пыжатся, тужатся… не «выходит каменный цветок». Все изменения ради изменений, а не ради улучшений. Надо же показать что пользователю есть за что платить.
К сожалению это не только в винде.
Ubuntu: Unity, в котором dock не может и одной трети того, что могут AWN, DockBarX, Cairo-dock, Gnome-Do и Во. В котором «главное меню» жутко неудобное, без категорий. Да, поиск спасает, но надо знать что искать. Дистрибутив для новичков? Да. Откуда им знать что нужная им программа называется?
MAc OS X: Тут никогда не утруждали пользователя процессом под названием «думать». Сама ОС не плохая, но шиш чего настроишь. Большая часть последних изменений вообще не касается ОС (напоминалка, сообщения и шашки-карты выдаются как новые возможности). Зачем это делать? Больше нечего придумать?
Винда: Еще в 7-ке все «упростили». Например до настроек сети идти гораздо дольше чем было в XP. Теперь — вообще через <цензура>.
Что за мода такая? Пытаются упростить понятное, проверенное и удобное, в результате делают страшное, неудобное и псевдопростое. Простое ровно до того момента, когда пользователь захочет чего-то большего чем просто смотреть порнушку в браузере.
Неужели среднестатистический пользователь отупел?
Ну ладно винда с яблоками, но ubuntu то куда (пишу об этом т.к. предпочитаю linux другим ОС)? Да я знаю, есть Arch, Gentoo, т.п. Проблема в том что ubuntu lдля многих стал синонимом «Linux», особенно для новых пользователей.
Почему никто не пытается идти обратным путем? Вместо упрощения всего помогать пользователям научиться. Ресурсы которые тратятся на «упрощение» тратить на создание какого-нибудь интерактивного самоучителя, поставляемого с системой. Ведь упрощается только то что на поверхности, тем самым отдаляя пользователя от того что внутри. Когда пользователю понадобится разобраться во внутренностях, ему будет гораздо сложнее. Система должна быть однородной и прозрачной сверху и донизу.
Поколение «фастфуда» врядли сможет понять крик души хлебороба. Arduino, это «игрушка», «хобби», «только макетка- а уж в серию пойдёт специализированное изделие», «за простоту надо платить». С ЕГЭ тоже сначала поигрались, потом пустили в серию. Теперь все расплачиваемся. Я тоже вырастил детей на LEGO,- был молод и глуп. Теперь только я знаю, что планку с монтажными отверстиями можно изогнуть и получить простое и нестандартное решение, которое смогут повторить и другие моделисты. Они же, в первую очередь, ищут готовую деталь, не найдя которую, начинают городить огород из имеющихся шаблонов. И да, они делают свои конструкции, но в них нет ни простоты ни изящества решений. И это во всём, чего не возьмись. Пол века назад простенький Луноход гоняли. Теперь поумнели на новых технологиях и Фобос-Грунт даже не улетел.
Последнее, чего бы я хотел, это чтобы С стал похож на С++.
Мало что понял… Знаю только что сейчас проги леплят всякими конструкторами и они огромные, тогда как раньше программы занимали места меньше (и на диске и в озу) Конечно нельзя сравнить текстовый интерфейс например 5-го ворда под дос и ворда из новых офисов, но все равно новые программы хотять слишком много…
Если подумать то даже 10 мегабайт, это ж 10 000 000 символов, таким количеством букв/знаков можно описать дофига всего, даже представить не могу… а для новых программ это очень мало… Вот здесь мне кажется что-то не то, не так должно быть
«Дьявол в деталях», на лицо явная архитектурная ошибка. Я было подумал что исправление могли замержить только в платную версию. Подход в стиле «гонка вооружений», когда вы за счет железа исправляете недостатки ПО, ни к чему хорошему не приведет и не важно что там на носу…
Существует мнение, что основная задача, которую решает ООП — это создание дополнительного объёма кода на пустом месте. Просто в США была норма программирования: 300 строк в день. Сложно написать 300 вменяемых строк в день. А если это всё заворачивается в интерфейсы и классы, да ещё есть автогенераторы из UML и т.д. В общем, индустриальное счастье. И ещё с умным видом можно рассуждать о паттернах. Поэтому тема и была раскручена. И в ООП нет ничего, что позволяет решать ту или иную задачу элегантнее (не путать с системами типов).
А я согласен с вами. Мне кажется, дело в том, что раньше и железо, и софт, и даже интернет-ресурсы разрабатывали профессионалы для профессионалов. Компьютеры были распространены главным образом среди людей, которые знали в них толк, и поэтому производители ориентировались на эту группу, выпуская действительно годные продукты.
Сейчас же рынок расширился до такого уровня, что компьютеры превратились в «бытовую технику», с соответствующими пользователями. Ну и производителям приходится делать всякие вау-спецэффекты, а также отказываться от интересных направлений для хакеров в пользу массового продукта для ламеров. К примеру, что сейчас с устройствами UMPC, ультрамобильными компьютерами (не планшетами!) с аппаратной клавиатурой? Нету их. Потому что делать однотипные планшеты для просмотра видеороликов и сидения в социальных сетях куда как проще и надежнее с точки зрения бизнеса, чем делать интересные, но мало кому нужные хакерфоны, хакерпады и хакербуки.
Нет, конечно нельзя утверждать что все стало хуже:) Технологии все-же развиваются, хотя и непрямым путем… видимо по спирали:)
Но «прозрачности» в win7 я отключаю сразу, она у меня выглядит как старая добрая win98, только более надежная и удобная.
> нормального человека
Значит то, что я видимо ненормальный — очень кстати :)
Это тебе кажестся.Да нет, вобщем. Вы это убедительно доказали и не раз.
P.S. надергать из интернета фраз на любой вкус можно сколько угодно.
P.P.S. я могу покритиковать С++ (и не раз это делал) куда как убедительнее, чем в приведенной вами цитате (тем более, что аргументация там свидетельствует о плохом знании критикуемого предмета), но другого сравнимого по мощности и распространенности инструмента для низкоуровневого программирования просто нет.
Не думаю.А стоило бы. К тому же, как я уже писал, С++ я критиковал и не раз, в том числе и тут, в сообществе.
Хотя бы потому, что слова Линуса для меня куда ценнее.Кто бы сомневался. Ведь они соответствуют вашим представлениям. Хотя и расходятся с реальностью. Наезжать на ++ из-за производительности, как это делает он, несусветная чушь, поскольку в самом языке нет ничего, что бы к этому приводило. К слову, ядро линукса таки написано во многих местах в ООП-стиле, разве что закат солнца делается вручную.
Кто бы сомневался. Ведь они соответствуют вашим представлениям.Дело не в словах, а в человеке. Он вообще няшка.
И нотч тоже, хоть и выбрал яву.
в ООП-стилеВ ООП-стиле — это сраться о том, обращаться к локальным полям с «this->» или нет. Брюс Эккель считает, что не надо, поскольку нечего делать работу за компилятор. Другие с тем же вдохновением доказывают, что надо. И это самый простейший пример. Искренне захочешь разобраться и научиться — не сможешь, поскольку вы там сами не можете решить как правильно. А если пойти дальше, куда больше вылезет всего.
Отделить некоторый кусочек и снабдить его интерфейсом — это не ооп стиль, а обычное сишное дело.
Дело не в словах, а в человеке.Ни один человек не может быть прав всегда и во всем.
Искренне захочешь разобраться и научиться — не сможешь,Вы даже не пытаетесь.
поскольку вы там сами не можете решить как правильно.«Вы сами» это кто?
Отделить некоторый кусочек и снабдить его интерфейсом — это не ооп стиль, а обычное сишное дело.От того, что вы его категорически не хотите так называть, он им быть не перестанет.
Вы продолжаете говорить о том, в чем не разбираетесь.Я практик и говорю о том, что вижу. Если в популярном продукте, который пишут далеко не студенты и не новички перекроили интерфейсы, что принесло всем головной боли, и что в явовской библиотеки половина интерфейсов уже «deprecated», так и говорю. Вижу, что 95% софта, начиная от Паинта, заканчивая Матлабом становятся уродливей, тяжелей и кривей, а полезных функций добавляется два грамма, так и говорю.
А не вычитал несколько определений в книжке, и объясняю всем, кто смотрит чуть на мир чуть шире, что они ничего не понимают.
Я практик и говорю о том, что вижу.Судя по тому, что вы пишете — вы теоретик, причем слабо подготовленный.
что в явовской библиотеки половина интерфейсов уже «deprecated»Я же говорю — вы теоретик, причем слабо подготовленный. До половины там еще ой как далеко, хотя с момента появления жабы прошло уже почти 20 лет, а за это время и сама жаба, и системы, на которых она работает, изменились и сильно.
В вашем фильтре не хватает «способных учиться».Я считаю, что учиться — это в первую очередь думать, а не тупо зубрить определения, как в школе заставляют. Такие «умеющие учиться» спокойно хавают всё, что скормят. А потом объясняют тем, кто думать умеют, что они ничего не понимают. Потому не могут даже представить, что кто-то мог прочитать те же определения, подумать, сопоставить с известными фактами и своим опытом и не согласиться.
Я считаю, что учиться — это в первую очередь думатьНо сами этого не делаете.
Потому не могут даже представить, что кто-то мог прочитать те же определения, подумать, сопоставить с известными фактами и своим опытом и не согласиться.Легко. Достаточно не пропускать пункта «думать» и разобраться в предмете критики. Два эти пункта вам никак не даются.
Вы путаете «умеют думать» и «умеют выдумывать», в результате своими выдумками заменяете знания и факты, а из них делаете выводы.По-моему, всё наоборот. В средние века быдло верило в ведьм (и жгло их на кострах). А научные знания считались выдумкой. Ничего с тех времён не изменилось. Желание сделать проще, надёжней, аккуратней — ересь и выдумка. Глючное, кривое и дерьмовое — стандарт.
По-моему, всё наоборот.Кто бы сомневался. Я ж говорю — вы живете в выдуманном вами мире.
В средние века быдло верило в ведьм (и жгло их на кострах). А научные знания считались выдумкой. Ничего с тех времён не изменилось.С тех пор знания и вера поменялись местами. Вот только вы этого не заметили и продолжаете знания заменять верой.
Желание сделать проще, надёжней, аккуратней — ересь и выдумка.Вы пока продемонстрировали желание пообливать грязью не вдаваясь в подробности. Желанич сделать проще, надежней и аккуратней не заметно.
С тех пор знания и вера поменялись местами.Ничего не поменялось. Также единичные люди иногда создают хорошие вещи, а остальные — стремятся всё запоганить (продолжая пользоваться этими вещами).
вы живете в выдуманном вами миреЯ не представляю насколько нужно уйти в свой виртуальный мир и потерять связь с реальностью, чтобы считать ваше «развитие» хорошим. Одноразовые розетки, одноразовый софт. Только дерьмовую розетку сколько не лакируй, контакты из фольги всё равно видно. Софт — предполагается, что это что-то сложное и можно рассказывать басни, оправдывая тормоза, глюки, бестолковость и постоянное скачивание обновлений через интернет.
Вы пока продемонстрировали желание пообливать грязью не вдаваясь в подробности.Угу. У меня вообще нет достаточных слов ненависти, чтобы это описать в подробностях. Браузер запускается пол часа — всех устраивает. Разумный человек бы вышвырнул эту поделку и не стал бы ей пользоваться. Но нет, продолжают верить, что обновление — это улучшение. Ничего не изменилось со средневековья.
Также единичные люди иногда создают хорошие вещи, а остальные — стремятся всё запоганить (продолжая пользоваться этими вещами).Не обольщайтесь, тех, кто, как и вы, стремится все запоганить продолжая этим пользоваться, меньшинство. К счастью.
P.S. надоело. как сделаете что-нибудь сами и разберетесь в предмете обсуждения, можно будет продолжить. если, конечно, к тому времени, вы будете отстаивать свою точку зрения и продолжать предлагать подходы полувековой давности, которые тысячи раз доказали свою нежизнеспособность.
Не обольщайтесь, тех, кто, как и вы, стремится все запоганить продолжая этим пользоваться, меньшинство.Я бесполезными поделками на всяких явах и оопах почти не пользуюсь. Вы сами пользуетесь операционными системами и множеством других вещей, написанных на Си.
как сделаете что-нибудь сами и разберетесь в предмете обсуждения, можно будет продолжить.Не хочу ничего делать на явах и оопах, и может даже кого-нить отговорить смогу, тогда на одно глючное дерьмо будет меньше.
И что? дело не в системах, а в поставленной задаче. Имхо стоит довольствоваться рациональным минимумом инструментов дабы получить простое работающее решение. Если надо обработать строку, можно это сделать и в жабе, бесспорно, но лучше взять инструмент специально разработанный для этого (perl). Если надо написать алгоритм мигания диодом, можно это написать на яве, но зачем, можно воспользоваться си. Другой вопрос что некоторые не хотят пользоваться именно оптимальными инструментами для решения задачи, в силу незнания оных. Так и получается, используем яву для мигания светодиодом.
Если надо обработать строку, можно это сделать и в жабе, бесспорно, но лучше взять инструмент специально разработанный для этого (perl).Будет ли это быстрее вопрос отдельный. Но если задача не ограничивается «обработать строку», то перл вполне может оказаться не самым лучшим инструментом. Впрочем это тоже отдельная тема. Гораздо существеннее два других пункта — знание инструмента на момент выбора и сопровождаемость полученной софтины.
Другой вопрос что некоторые не хотят пользоваться именно оптимальными инструментами для решения задачи, в силу незнания оных.Оптимальный инструмент выбирается из тех, которые разработчик знает и готов сопровождать. Декларации авторов инструмента о том, для каких целей он создавался играют куда меньшую роль.
P.S. пример с перлом явно неудачный, как на мой вкус. из моих знакомых любителей перла они все в один голос признают, что типичный перловый скрипт — write only.
Твое незнание оптимального инструмента оказывается моей проблемой. Зачем мне лишняя проблема? Так и получается что Гейтс орал что всем на 20 лет хватит 640к. И так бы и вышло писали бы люди грамотно, а не плодили костыли, для закрытия других костылей. Самый главный вопрос, где ваша жаба в авр-ках? Если на ней можно сделать то же что и на сях
Твое незнание оптимального инструмента оказывается моей проблемой.Отвечу вашими же словами:
Имхо стоит довольствоваться рациональным минимумом инструментов дабы получить простое работающее решение.Перл в рациональный минимум не входит. К тому же насчет «незнания» вы погорячились. На перле я действительно не пишу, но это вовсе не значит, что мой инструментарий ограничен жабой.
Если на ней можно сделать то же что и на сяхЧто-то можно, что-то нельзя.
мм? dmitry.gr/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit
Конечно методом налаживания костылей друг на друга. Но в тоже время linux on avr
Конечно методом налаживания костылей друг на друга. Но в тоже время linux on avr
Вот ещё www.harbaum.org/till/nanovm/. Что удивляться, компьютер — он и есть компьютер, даже если это межка или даже какой-нить малюсенький PIC.
Твое незнание оптимального инструмента оказывается моей проблемой. Зачем мне лишняя проблема?Неправильный выбор — это не только ява.
Выбор оверкилла обычно приводит к тому, что ты получаешь жручий и раздутый, но работоспособный инструмент.
Выбор недокилла приводит к тому, что ты получаешь компактный, быстрый, но постоянно глючащий инструмент.
Выбирай.
Если надо обработать строку, можно это сделать и в жабе, бесспорно, но лучше взять инструмент специально разработанный для этого (perl).Сишная строковая библиотека позволяет решать многие задачи по обработке текста куда проще и оптимальней, чем перл. И уж конечно куда оптимальней, чем средства других языков.
Регулярки при желании не трудно добавить, использовав соответствующую библиотечку.
эээ. строковая замена? да, с применением strstr, memcpy, malloc действительно решает проще чем перл с его s/// :)
А ещё в Си очень хорошо реализовано формирование набора строк из строки с разделителем >1 символа. С этим прекрасным циклом и указателями в простоте не сравниться ни какая оопешная array = string.slice(separator)
А ещё в Си очень хорошо реализовано формирование набора строк из строки с разделителем >1 символа. С этим прекрасным циклом и указателями в простоте не сравниться ни какая оопешная array = string.slice(separator)
Много чего. В сишной библиотеке кроме strstr есть много менее известных функций. А если уметь их применять не только по стандартным шаблонам, можно сделать многое. TCHAR помогает сделать полностью переносимо между системами с поддержкой юникода или без. А сама работа со строкой просто как с кусочком памяти позволяет вообще всё. Причём максимально быстро и просто.
К тому-же в последних ядрах можно писать модули на C++. Прекращайте срач. Все зависит не от языка, а от того, кто на нем пишет. Многим просто не под силу из-за слабоумия или лени освоить ООП, поэтому для них С++ — олицетворение зла.
- coredumped
- 20 февраля 2013, 18:03
- ↑
- ↓
хехе, это люди, до которых тебе далеко очень ;)Я прекрасно знаю кто это. Просто нужно было остановить срач в самом начале :) Лучший способ — задать идиотский вопрос.
- coredumped
- 20 февраля 2013, 21:17
- ↑
- ↓
GLib serves as an implementation of such fundamental types and algorithms (linked lists, hash tables and so forth), the GLib Object System provides the required implementations of a flexible extensible and intentionally easy to map (into other languages) object-oriented framework for C.— developer.gnome.org/gobject/stable/pr01.html
Хватит притягивать за уши то, чего нет. И прятать слона.
Уважаемый Lifelover , а вам не надоело воевать с ветряными мельницами? Вы сами себе придумали уютный мирок (с Сшекчтой и AVRочкой) и просто поливаете говном все, что выходит за рамки Вашей уютной идеологии.
Я не имею ничего против С и AVR – но это всего лишь инструменты. Это хорошие инструменты для своих задач, но это не единственные существующие инструменты. Есть множество других инструментов, которые позволяют решать определенные задачи более продуктивно.
А Вы заладили, как старый дед, «А вот раньше… А вот раньше…». При этом абсолютно без аргументации. От прямых вопросов Вы уходите, а в качестве аргументов приводите сриншоты интерфейсов, картинки с иконками и найденные на просторах Интернета цитаты уважаемых и не очень людей.
Оглянитесь вокруг. Если, по-вашему, ООП так ужасен — то почему данная концепция получила такое широкое распространение? Неужели все настолько глупы, и лишь только Вы «знаете правду»?
Я не имею ничего против С и AVR – но это всего лишь инструменты. Это хорошие инструменты для своих задач, но это не единственные существующие инструменты. Есть множество других инструментов, которые позволяют решать определенные задачи более продуктивно.
А Вы заладили, как старый дед, «А вот раньше… А вот раньше…». При этом абсолютно без аргументации. От прямых вопросов Вы уходите, а в качестве аргументов приводите сриншоты интерфейсов, картинки с иконками и найденные на просторах Интернета цитаты уважаемых и не очень людей.
Оглянитесь вокруг. Если, по-вашему, ООП так ужасен — то почему данная концепция получила такое широкое распространение? Неужели все настолько глупы, и лишь только Вы «знаете правду»?
Ваша ненависть к простоте
У меня нет ненависти к простоте, наоборот, я восхищаюсь простыми и лаконичными решениями. Но не все задачи имеют простое решение. Даже если абстрагироваться от программирования. Вот Вы, например, знаете простое доказательство теоремы Ферма? Ведь формулировка теоремы – проста и лаконична, а доказательство требует совершенно другого мат. аппарата.
Как правильно заметил Vga – Вы путаете простоту и примитивность. Перфокарты – предельно простой способ хранения информации. Только, почему-то, сейчас перфокартами никто не пользуется, несмотря на всю его простоту.
Разве что в общем описании. На деле это совершенно ужасающий агрегат. Там даже вместо головок уже микросхема с электромагнитом, магниторезистором, термодатчиком, МЭМС-актуатором и хрен знает чем еще, а читаемый сигнал так слабо похож на биты, что обрабатывается специальным математическим аппаратом, причем ЕМНИП — вероятностным.
Значит есть ещё более простое решение.
Вы опять уходите от ответа. Вы знаете простое доказательство теоремы Ферма? Вы знаете какой-то простой и универсальный алгоритм для решения NP-полных задач?
Вот Вы, где-то в комментариях, поливали говном применение нейросетей. На самом деле данный класс алгоритмов действительно не является самым простым и производительным. Более того, в таких алгоритмах (нейросети, генетический алгоритм) присутствует фактор чистой случайности, чистый «random». И решения получаются суб-оптимальными.
Но, ели вы знаете боле простое решение, поведайте миру – и мировая известность Вам гарантированна.
Ты не так понял, я SQLite наоборот люблю
Извиняюсь, если я неправильно Вас понял, просто в Вашем потоке негатива тяжело понять – что Вы любите а что нет. Вот как интерпретировать Вашу фразу «заканчивая всякими нейронными сетями»?
А что Вас смущает в использовании SQLite из других ЯП? SQLite – удачный проект, и он получил широкое распространение. Или Вы считаете, что ели SQLite написан на С, то и использовать его имеют право только те программы, которые написаны на С? Использование ORACLE со средой .NET Вас не смущает?
А используют, потому что сами на своих труъ-языках подобного не имеют.Нет. Используют потому, что незачем изобретать велосипед. Так же, как никто не пишет себе собственное ядро, а берут готовый линукс. Точно таким же образом берут и другие готовые компоненты, написанные на любых языках, включая яву.
А также типичная сипрога (минус гламурная раскраска, в остальном все то же самое), дельфипрога (сам такое писал), сиплюсплюспрога (и такое тоже), чтоугодно прога. Типичный your app, от языка программирования не зависит. Только от способностей дизайнера интерфейса (что-то мне подсказывает, что тут им тут и не пахнет).
Ява обычно крутится где-то в энтерпрайзах и серверах, так что 90% софта на ней 99% людей и в глаза не видели. Из оставшихся 10% девять — это софт для J2ME и Android. Оставшийся процент заглядывает на ПК. Среди него есть хорошие вещи — эклипс, например.
Ява обычно крутится где-то в энтерпрайзах и серверах, так что 90% софта на ней 99% людей и в глаза не видели. Из оставшихся 10% девять — это софт для J2ME и Android. Оставшийся процент заглядывает на ПК. Среди него есть хорошие вещи — эклипс, например.
Мне и мультиви не нравится. Вот это — квадрокоптер. А мультивии — ардуйня с моторчиками, которая кое как держится в воздухе, если ветерок не дунет.
Я то Вас не устраивает в данной программе? Дизайн? Сочетание цветов?То, она ещё хуже, чем текстовый конфиг.
Серьезный, профессиональный софт — во многом еще более заумный фильтр. К тому же, хрен он что сделает без соответствующей системы датчиков, да и скорее всего требует немалую производительность. Даже его авторы не построят аналогичное на железе мультиви. Хотя скорее всего смогут реализовать лучше, чем сейчас есть.
Алсо как раз в мультиви AFAIK все довольно простенько. Что посложнее не позволяют примененные датчики, производительность процессора и познания авторов.
Алсо как раз в мультиви AFAIK все довольно простенько. Что посложнее не позволяют примененные датчики, производительность процессора и познания авторов.
Мне и мультиви не нравится
Ок, не нравится – не покупаете, на стройте свой коптер на основе MultiWii. В чем проблема?
Вы опять уходите от прямых вопросов. И, зачем-то приводите скриншоты каких-то программ. Глупо оценить программы исходя из вершено вида.
То, она ещё хуже, чем текстовый конфиг.
Дык, опять же, никто Вас не заставляет пользоваться данной программой, можно конфигурацию записывать прямо в EEPROМ, набрав данные в HEX редакторе…
Мультиви – отрытый проект, который держится на энтузиастах. Вы, абсолютно бесплатно, получаете последнюю прошивку, программу для конфигурирования … И, вместо того, чтобы сказать спасибо разработчикам данной платформы — Вы опять поливаете все говном…
Глупо оценить программы исходя из вершено вида.Эту, как раз, можно. Она вся из интерфейса и состоит.
Мультиви – отрытый проект, который держится на энтузиастах. Вы, абсолютно бесплатно, получаете последнюю прошивку, программу для конфигурирования …Ну, бесплатность все же не индульгенция от критики. Хотя эффективней было бы переделать как надо и заслать авторам — на то он и опенсорс.
Хотя эффективней было бы переделать как надо и заслать авторам — на то он и опенсорс.Есть альтернативная программка. Немножко менее страшная.
А используют, потому что сами на своих труъ-языках подобного не имеют.
Имеют, есть множество «встраиваемых» БД. Просто инженеры выбирают инструменты исходя из потребностей, а не из фанатической преданности тем или иным технологиям. SQLite — действительно (ИМХО) удачный проект. Почему бы не использовать это, готовое решение, если оно действительно подходит под определенную задачу. А вот если инженер выбирает БД исключительно из принципа «ели я пишу на python, значит и БД должна быть написана на python» — это уже фанатизм.
тонны софта на си, которые сейчас в любом телевизоре/телефоне?Скорее граммы, а не тонны. Тонны это всевозможный in house софт, который вы даже не упомянули. Его на С, кстати, толком никогда и не писали.
P.S. каждый год пишут примерно 5 миллионов строк нового кода на Коболе. это язык который давно перестал занимать лидирующие позиции в in house программировании и еще лет 20 назад считался устаревшим. можете сравнить это со своим проектом, размером которого вы регулярно хвастаетесь.
Одно дело — переписывать кусочки, причем каждый переписывает свой, и совсем другое — перетаскивать весь проект на другой язык. Второе — реально, только если все этим целенаправленно займутся. Но для этого требуется очень, очень веская причина, которой нет. Так что иного выбора, кроме как тащиться за выбором Линуса уже нет.
Я тебя не понимаю.
Да, причины достаточно веской, чтобы оправдать переписывание огромного количества кода нет. Но я вообще знаю только одну причину достаточной вескости для такого мероприятия — когда на старом инструменте дальше развивать уже невозможно. К линуксу это не относится, по крайней мере пока.
Да, причины достаточно веской, чтобы оправдать переписывание огромного количества кода нет. Но я вообще знаю только одну причину достаточной вескости для такого мероприятия — когда на старом инструменте дальше развивать уже невозможно. К линуксу это не относится, по крайней мере пока.
коих пока обнаружено очень немного, так скажемВы пока тоже не продемонстрировали способности оценивать эти знания.
всегда радуют люди, которым в ядре показать нечего,Всегда радуют люди, которые знания в определенных областях меряют количеством запощеных патчей в ядро.
но которые уже знают, что оно несложное :)Да, я уже обратил внимание, что навык внимательного чтения написанного у вас в зачаточном состоянии :) Умудриться увидеть «несложность» в словах о переоценке сложности это так по-lifelover-ровски :)
Господа, извините, но вам еще не надоело письками меряться?
Bzzz, никто не сомневается, что вы хорошо пишете на си, разбираетесь в линуховом ядре и быстро пишете код для STM32 с использованием SPL. Вопрос скорей такой: каким образом все это относится к теме данного топика? И другой вопрос: почему если вы делаете именно так то и все остальные должны делать именно так? Ваше мнение единственно верное?
Bzzz, никто не сомневается, что вы хорошо пишете на си, разбираетесь в линуховом ядре и быстро пишете код для STM32 с использованием SPL. Вопрос скорей такой: каким образом все это относится к теме данного топика? И другой вопрос: почему если вы делаете именно так то и все остальные должны делать именно так? Ваше мнение единственно верное?
ну прочитай комменты еще раз, забыл со вчера, видимо :)
я вроде тебе уже писал… делиться, наверное, имеет смысл тем, что полезно. а не опытом обжигания пальцев и подобным. то что ты написал, полезным не является, imho.
в целом я понимаю ценность подхода «сделать все самому чтобы понять», но это делают только для себя. а вот STL сделана для всех. сделал лучше — можно вынести на публику, конечно.
но то что я вижу, не стоит ;)
я вроде тебе уже писал… делиться, наверное, имеет смысл тем, что полезно. а не опытом обжигания пальцев и подобным. то что ты написал, полезным не является, imho.
в целом я понимаю ценность подхода «сделать все самому чтобы понять», но это делают только для себя. а вот STL сделана для всех. сделал лучше — можно вынести на публику, конечно.
но то что я вижу, не стоит ;)
Если для Вас лично это не имеет ценности, не значит, что оно не нужно никому.
Ну и напишите свою статью, что как и где надо делать, а мы уж оценим, на сколько там ценная информация.
P.S.
Кстати именно потому что статья не является обучающей я выкладывал ее в личный блог. В коллективный ее перекинул уже Ди. Что опять же говорит о том, что он посчитал данную информацию интересной.
Прекращайте уже пустой спор. Все равно каждый останется при своих…
Ну и напишите свою статью, что как и где надо делать, а мы уж оценим, на сколько там ценная информация.
P.S.
Кстати именно потому что статья не является обучающей я выкладывал ее в личный блог. В коллективный ее перекинул уже Ди. Что опять же говорит о том, что он посчитал данную информацию интересной.
Прекращайте уже пустой спор. Все равно каждый останется при своих…
Набрал. Первые пять ссылок:
en.wikipedia.org/wiki/Bionics
en.wikipedia.org/wiki/Bionic_(Christina_Aguilera_album)
www.bionicgloves.com/
dictionary.reference.com/browse/bionic
www.x-bionic.com/
Которая?
en.wikipedia.org/wiki/Bionics
en.wikipedia.org/wiki/Bionic_(Christina_Aguilera_album)
www.bionicgloves.com/
dictionary.reference.com/browse/bionic
www.x-bionic.com/
Которая?
ru.wikipedia.org/wiki/Bionic_(%D0%B1%D0%B8%D0%B1%D0%BB%D0%B8%D0%BE%D1%82%D0%B5%D0%BA%D0%B0)
Потому, что это библиотека поддержки языка С. На чем-то ином ее и не напишешь (ну, быть может, на ассемблере еще, но это непортируемо, а ведроид запускается минимум на трех архитектурах). Тем более на яве, которая работает как раз поверх этой библиотеки — получается проблема курицы и яйца.
Хотя, я неоднократно видел случаи реализации кусочков libc на Delphi. Но не полностью и только для того, чтобы слинковать сишные объектники с программой на Delphi, а не для замены libc для сишных прог.
Хотя, я неоднократно видел случаи реализации кусочков libc на Delphi. Но не полностью и только для того, чтобы слинковать сишные объектники с программой на Delphi, а не для замены libc для сишных прог.
Это библиотека поддержки языка. Даже если С без нее может обойтись — она играет для него такую же роль, как RTL для Delphi. Никто же не удивляется, что Delphi RTL написана на Delphi. Так же и тут, для libc C — самый логичный выбор.
не вижу почему оно не может получиться на яве.Хотя бы потому, что ява исполняется на VM, которая сама написана на чем-то компилируемом в нативный код. И скорее всего — это именно C, соответвенно VM самой нужен bionic, чтобы работать.
не важно на чем написана VM. не важно на чем написан bionic. нужно чтобы одна могла вызывать функции другого (связывание) и чтобы в VM можно было вызывать функции ядра (что легко делается без libc.).
и да, для программировани на си libc не обязательна. и эти люди, типа, обсуждают программирование под stm32 :)
и да, для программировани на си libc не обязательна. и эти люди, типа, обсуждают программирование под stm32 :)
у меня фактов этих целый вагончик… ядра, компиляторы, утилиты, на андроеде масса системных библиотек и ядро — все си.Это все традиционные области применения, расширения тут никакого и близко нет. Более того, компиляторы других языков программирования отличных от С зачастую пишутся на них же, так что написав «компиляторы» вы слегка передернули.
системы хранения данных — си, обычно.Давно уже нет. Причем с ростом объема и сложности решаемых задач все меньше и меньше.
факты будут?Легко.
я сейчас сходу назову несколько распределенных систем хранения данных, которые написаны на си.И я легко назову несколько распределенных систем хранения данных, где С даже близко не лежал.
я писал про «системное по», которое да, традиционно пишется на си (не все, конечно) и пока что нет признаков, что это изменится.Я еще раз напомню: доля системного софта неуклонно снижается. Но даже в традиционных областях применения С плюсы наступают ему на пятки.
«критиковал» — это не очень показатель, скажем. какой-нибудь профессор таненбаум критиковал монолитные ядра. только где этот профессор и где монололитные ядра.
если fortran выжил, значит он достаточно хорош для своих задач. и это прекрасно. что есть проверенные временем и кучей людей инструменты. для программирования.
если fortran выжил, значит он достаточно хорош для своих задач. и это прекрасно. что есть проверенные временем и кучей людей инструменты. для программирования.
В первую очередь не столько хорош, сколько имеет ни с чем не сравнимую библиотеку наработок в области математики. Поэтому затеяв что-то математическое придется задуматься — делать все самому, или воспользоваться готовым, но писать на фортране. Когда готовое перевешивает — появляется еще одна новая программа на фортране. Схожим образом живут и другие старые языки.
Впрочем, у таких языков как С достаточно сильны отголоски популярности и некоторые пишут на них не потому, что С больше всего подходит, а просто потому, что он нравится.
Впрочем, у таких языков как С достаточно сильны отголоски популярности и некоторые пишут на них не потому, что С больше всего подходит, а просто потому, что он нравится.
«критиковал» — это не очень показатель, скажем.Ну, как минимум, критиковал он заслуженно (и в f95 многое из того поправили, а в С все это было исправлено изначально). Насчет «резко» — тут да, Дейкстра тот еще тролль.
только где этот профессор и где монололитные ядра.Что не мешает поскрипывать зубами, сталкиваясь с проблемами монолитных ядер. Ну и чисто монолитных ядер вроде уже нет — их заменили гибридные. Чисто микроядер, окромя таненбаумовского миникса, впрочем, тоже нет.
«Этот профессор» на сколько я знаю, уважаем тем же Линусом. Если вы уважаете Торвальдса, то откуда такое неуважение к Таненбауму? И что тогда заставляет вас ненавидеть С++ только из-за того, что его ненавидит Торвальдс?
Монолитные ядра в Винде — каторая зачастую оказывается в бсоде, к линуксе, которые постоянно в панике. А микроядра, в пользу которых высказывался Таненбаум в QNX.
Монолитные ядра в Винде — каторая зачастую оказывается в бсоде, к линуксе, которые постоянно в панике. А микроядра, в пользу которых высказывался Таненбаум в QNX.
с тобой технические детали обсуждать смысла нет.Угу. И не факт, что вы в состоянии это делать.
я тебе несколько раз задал несложный вообщем-то вопрос, ты все разы слился.Не путайте «слился» с «не ведусь на „слабО“. Как я уже писал, вы пока никак не продемонстрировали, что в состоянии оценивать чьи-либо знания.
однако не думаю, что тебе это интересно.В вашем исполнении — скорее всего нет.
Вы дадите гарантию, что ваша система будет работать надежно, при использовании стороннего драйвера мигания светодиодом? Почему винда так докапывается до подписи драйверов (ну то что денег срубить, то понятно)?
Монолитное ядро популярно, да. за счет своей производительности. Микро ядро популярно в промышленности, за счет своей надежности. Вам гарантируют, что ваш атомный реактор не навернётся, из-за ошибки в драйвере звонка входной двери, последний упадет сам, сохранив целостность ФС и памяти других программ/драйверов. В монолитном ядре встречаются случаи приведения в негодность ФС диска, из-за ошибки доступа в некачественном драйвере.
Сделать надежно монолитное ядро можно, только делать надёжно обязаны все. В микро ядре же добиваются отказоустойчивости, при некоторой допустимой ненадежности компонент.
Монолитное ядро популярно, да. за счет своей производительности. Микро ядро популярно в промышленности, за счет своей надежности. Вам гарантируют, что ваш атомный реактор не навернётся, из-за ошибки в драйвере звонка входной двери, последний упадет сам, сохранив целостность ФС и памяти других программ/драйверов. В монолитном ядре встречаются случаи приведения в негодность ФС диска, из-за ошибки доступа в некачественном драйвере.
Сделать надежно монолитное ядро можно, только делать надёжно обязаны все. В микро ядре же добиваются отказоустойчивости, при некоторой допустимой ненадежности компонент.
это все расхожие сказки. одного ядра для этого недостаточно. чтобы редактор не навернулся, нужно чтобы он сам был написан соответствующим образом: умел заново открыть все нужные дескрипторы, записать и проч. таких програм *почти* нет.
и, к слову, во время разработки я регулярно попадаю в какое-нибудь GFP… но данные при этом теряю не так часто ;)
из-за некачественного драйвера файловая система на микроядре точно так же может потерять/испортить данные ;)
и, к слову, во время разработки я регулярно попадаю в какое-нибудь GFP… но данные при этом теряю не так часто ;)
из-за некачественного драйвера файловая система на микроядре точно так же может потерять/испортить данные ;)
Комментарии (828)
RSS свернуть / развернуть