Примеры инициализации периферии 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

Комментарии (828)

RSS свернуть / развернуть
Спасибо.
Положу «на чердак». При случае опробую предложеный код.
0
  • avatar
  • Noi
  • 19 февраля 2013, 17:38
код 100% рабочий, т.к. выковырян из текущего проекта, в котором на DMA висят 2 SPI и АЦП, + 1 из каналов используется для перекачки данных памяти из буфера в буфер. Все это работает одновременно.
Управляется выставлением флагов в контрольной переменной. Флаги соответственно придумывайте сами под свои задачи.
0
Большое спасибо! Очень полезная статья. Прекрасна идея такого сборника.
Буду рад видеть продолжение.
0
А кто-нибудь юзал компаторы в STM32f0, как настроить прерывания?
0
из мелких кортексов у меня только тот что на дискавери установлен, да и та лежит в ящике и не используется… так что по компаратору не подскажу. Остальные камни все 103c8t6.
0
А мне f0 и наверное f3 показались как-бы более продуманными, чем f1. Хотя я только начал разбираться с микроконтроллерами, но, например SPI в f0 не только 8 или 16, а от 4 до 16, и есть битик NSSP — если его установить то контроллер после каждой передачи будет дергать nss, у АЦП есть режимы auto-off и появился бит ADRDY теперь не так «включите и потупите, маленько, пока не стабилизируется» а «включите и подождите пока ADRDY». Как-то так. Но вот компатор, примитивная периферия, а туплю с ним люто.
0
А мне f0 и наверное f3 показались как-бы более продуманными, чем f1.
Ну это неудивительно, F1 первые, и потому сыроваты. Уже начиная с F2 периферию подфиксили. F0 и F3 еще позже появились.
0
Ну это неудивительно, F1 первые, и потому сыроваты. Уже начиная с F2 периферию подфиксили. F0 и F3 еще позже появились.

Порядок появления семейств STM32:
1/ F2
2/ F1
3/ F4
4/ F0
5/ F3
0
Вообще-то нет, F1 были первыми, F2/F4 появились позже (и одновременно), затем F0 и только затем F3.
0
Да, точно:
Jun 2007 F1
Apr 2010 L1
Nov 2010 F2
Sep 2011 F4
Feb 2012 F0
Jun 2012 F3
0
То, что твой порядок неверен видно уже из того, что у F2 и F4 периферия идентичная, а у F1 отличается. Ну и вообще, насколько я знаю, периферия схожа у всех семейств, кроме F1, и вероятно, именно из-за того, что на F1 она обкатывалась.
0
И компараторы интересно!
И энергосберегающие режимы интересно. Вместо задержек с пустым циклом интересно вызывать Sleep или Stop-режим и с выходом по RTC прерыванию.
0
А ещё к инверсному входу можно ЦАП подключить.
0
энергосберегающие режимы я тоже пока не рассматривал. В текущем проекте они без надобности. Как дойдут руки — так может опишу.
0
Могу добавить инициализацию таймера на генерацию 2х ШИМов. Если интересно
+1
Зачем утаивать информацию? Конечно интересно))
0
Только разобраться в этом без datasheet не раельно. Только если брать как часть из библии.
0
  • avatar
  • x893
  • 19 февраля 2013, 23:23
Только разобраться в этом без 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++];
+3
В конкретном случае у либы есть один большой недостаток: в обязательном порядке нужно инициализировать все поля структуры, иначе можно наступить на очень неприятные грабли с плавающими ошибками. Так что хотя я и обеими руками за читабельность, но приводить SPL в качестве примера я бы не стал. Ну и, на мой вкус, она, все-таки, слишком многословна. Даже в приведенном вами примере слово USART встречается слишком часто, хотя в подавляющем большинстве случаев это бесполезный шум ухудшающий читабельность.
+2
приводить 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;
0
И количество слов 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 с вариантом описанным в топике, то есть весьма компактно.
0
Слишком сложная, неестественная конструкция. Если нужна абстракция в этом месте я бы предпочел передавать строку 9600N8 и т.п. или как в SPL если важно количество тактов.

Хотя я так думаю про большинство конструкций на C++ :)
0
Слишком сложная, неестественная конструкция.
Она проще той, что написана на SPL. Насчет естественности это, как бы, дело вкуса.
0
Нужно всего лишь немного привычки. Во многих случаях такая структура весьма удобна. К тому же, она проста в реализации и вполне понятна.
А строку парсить неэффективно (если в рантайме, а в компилтайме если и возможно, то не так уж просто). Это хорошо для программ командной строки, а не МК.
0
Кстати, насчет строки. С ней действительно будет не очень хорошо, а вот такой вариант вполне можно сделать:


USART usart(USART1, USART::Config_57600N8RXTX);
    usart.flowControl(USART::None)
         .enable();

То есть для типовых режимов предусмотреть константы, а то, что ими не покрывается — доконфигурировать явно. Ну а если режим не стандартный, то конфигурировать так, как описано выше, задавая все параметры.
+1
> в обязательном порядке нужно инициализировать все поля структуры, иначе можно наступить на очень неприятные грабли с плавающими ошибками.

Для инициализации полей значениями по умолчанию есть функция USART_StructInit().
+2
Хотя, на мой взгляд, лучше инициализировать все поля самому, чем потом лазить в эту функцию смотреть значения.
+1
В данном случае нет никакого плюса либы, так как за значением полей структур точно так же надо лазить в какой-то файл и искать. Что в либе искать, что в файле от CMSIS, одинаково. А магические числа все в обычном двоичном формате и означают номер канала для АЦП и делитель для USART. Больше магических чисел нет, только поля регистров, которые так же понятны. (Кстати, когда я пишу с либой — использую даташит при заполнении полей структур ничуть не меньше, чем при написании без либы :D )

P.S. На самом деле данная тема не для выяснения плюсов и минусов метода или либо-срача. Лично для меня (я как-то уже писал) вопрос об использовании/не использовании либы непринципиален и его решение зависит от фазы луны и желания левой пятки правой ноги. Сегодня я пишу без либ, завтра с STMPeriphLib, послезавтра с самодельной либой и т.д.
+1
В данном случае нет никакого плюса либы, так как за значением полей структур точно так же надо лазить в какой-то файл и искать.
В нормальных редакторах/IDE они сами вываливаются.

Ничего искать не надо. А вот биты регистров — действительно искать.

P.S. На самом деле данная тема не для выяснения плюсов и минусов метода или либо-срача.
Ухожу, ухожу, ухожу… :)
Лично для меня (я как-то уже писал) вопрос об использовании/не использовании либы непринципиален
Для меня — то-же. См. мой ответ evsi: «я обращал внимание, что инициализация с использованием SPL выходит яснее, чем пример приведенный Автором.»
+2
кейл раньше этого не умел. Сейчас проще.
0
кейл раньше этого не умел. Сейчас проще.
Вообще-то — это SlickEdit. Он такие вещи умел делать от рождения, т.е. всегда.
Кейлом не пользуюсь очень давно, в силу некоторых причин. Каких — не скажу, а то тут будет полный ПЦ.
0
Он такие вещи умел делать от рождения, т.е. всегда.
Ты уверен? Он появился еще в древнедосовые времена, тогда автокомплита вроде еще не было.
0
Ты уверен? Он появился еще в древнедосовые времена, тогда автокомплита вроде еще не было.

Когда SE появился — наверное не было. Тогда я занимался цифрой на 564 серии и необходимости в нем не было. :) Когда я им начал пользоваться он уже стал Visual SE. И поэтому мне кажется, что так было всегда. :)
0
Эх. Надо его все же слить да опробовать. Был бы он еще фри — давно бы слил)
0
Был бы он еще фри — давно бы слил)
когда и кого это останавливало? ;)
0
Ну, всяких линуксоидов. Мне лично крек искать лениво.
0
Пригодится, спасибо.
В избранное.
0
  • avatar
  • ploop
  • 20 февраля 2013, 09:33
UPD.
добавил таймер с 2мя каналами ШИМ и ремап SPI1 с отключением JTAG от ног МК.
0
ад из израиль
никак не пойму, почему быдлокодинг катится в сраное гавно?
почему все так сложно? хотя бы по сравнению с авр
+1
Периферия у стм-ок гораздо более навороченная и функциональная, отсюда и сложность конфигурации.
+1
т.н. «fluent синтаксис» мне нравится больше

GPIOB->CRH &= (~(GPIO_CRH_CNF10_0));
а это как-то уж за гранью зла
0
Совершенно согласен. Но это С++, а многие его, почему-то, сильно пугаются, хотя при разумном применении от него только преимущества.
0
хотя при разумном применении от него только преимущества.
«Разумном» — ключевое слово. Способных применять С++ разумно программеров не так уж много.
0
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 и алиасами, но тут уже я пас :)
А потом они рассказывают, что видите ли всё так сложно и глючно из-за «функционала».
0
А т.н. «fluent синтаксис» — путь к
В руках таких как вы — однозначно. Потому что то, что вы процитировали, не имеет никакого отношения к тому, что написал я.
+1
Потому что то, что вы процитировали, не имеет никакого отношения к тому, что написал я.
Имеет самое прямое отношение. Потому что это замена двух элементарных операций на какое-то очередное говно.
0
Имеет самое прямое отношение.
Нет.
Потому что это замена двух элементарных операций на какое-то очередное говно.
Говно, это то, что отстаиваете вы. Подозреваю отстаиваете потому, что вам никогда не доводилось заглядывать в собственный код спустя какое-то время или его сопровождать.
+1
Говно, это то, что отстаиваете вы.
Говно — это твои явы и оопы. Мне нравится техника за то, что в ней всё честно. Сколько не разводи политики, никаких добавочных коэффициентов в законе Ома не появится. Программирование для компа скатили в быдлокодинг, где всё занимает гигабайты, требует гигагерцы и качает обновление через интернет. В электронике пока ещё Си и Ассемблер. Если я смогу кого-нибудь убедить, что элементарная бинарная логика проще и надёжней, чем городить классы, может отдалиться тот день, когда вы своё сраное болото в каждый выключатель притащите.
0
Если я смогу кого-нибудь убедить, что элементарная бинарная логика проще и надёжней
Вы сможете в этом убедить только те, кто, как и вы, ничего не понимает в программировании и кому ни разу не доводилось сопровождать собственный код или переносить его на другой МК.
+2
или переносить его на другой МК
На компе так и не научились ничего переносить. Даже под вашим линухом под каждым дистрибутивом (которых развелось, как грязи) свои пакеты, которые больше ни к кому не подходят. А каждая программа на сраной яве тащит за собой кучу нативных бинарников, начиная от SQLite, заканчивая всякими нейронными сетями, потому что своего нифига нету кроме раздутых менеджеров и прочих паттернов (зато всё ресурсов жрёт как стадо слонов). Которые тоже нужно тащить трёх видов, несмотря на то, что к железу эти библиотеки не имеют никакого отношения. Как вы собрались переносить что-то для МК — секрет. Учитывая, что в разных МК (кроме какойнить игрушечной ардуйни) совершенно разный набор периферии, с разными возможностями.
Шли бы в какую-нибудь политику или литературу, нет, надо именно технику изгаживать
0
На компе так и не научились ничего переносить.
Вы — да.
свои пакеты, которые больше ни к кому не подходят.
Пакеты разные, но софтина одна. К тому же «ни к кому не подходят», мягко говоря, не правда.
Как вы собрались переносить что-то для МК — секрет.
Для вас — да.
Шли бы в какую-нибудь политику или литературу
Я вам в попутчики не гожусь.
надо именно технику изгаживать
Не изгаживать, а развивать. А то с такими как вы телега осталась бы основным видом транспорта.
0
А то с такими как вы телега осталась бы основным видом транспорта.
С такими, как вы давно уже скатились бы в каменный век. Превратили бы всё в кучу бесполезного под своей громоздкостью мусора.
0
С такими, как вы давно уже скатились бы в каменный век.
Реальность свидетельствует об обратном.
0
Когда вы со своими оопами и явами окончательно доберётесь до ядер операционных систем (где все ещё Си), авионики (где всё ещё Си), и в каждый выключатель понапихаете своего говна, реальность станет адом.
0
реальность станет адом.
Для вас — да. Это нормальный процесс естественного отбора для тех, кто не хочет учиться и развиваться.
0
Если «развиваться» — это создавать всё более тормозное, дерьмовое и глючное, то я не хочу «развиваться», т.к. я человек а не свинья.
0
это создавать всё более тормозное, дерьмовое и глючное
Именно к этому вы призываете, пропагандируя, «правильные», по вашему мнению, подходы.
+1
Холивары — это всегда вкусно. Но тут я вынужден поддержать lifeover-а, совершенно не надо городить больше кода когда можно сделать меньше. С другой стороны можно написать быдло-код в котором будет течь память и на простой си. В таком случае возникает потребность в инструментах более лучшего класса, где такие проблемы решены. ( С -> C# / Java ). Но код написанный на чистом си, или даже асме будет в любом случае лучше чем код на C# или Java который действительно ужасен, если копнуть глубже
0
Но код написанный на чистом си, или даже асме будет в любом случае лучше чем код на C# или Java
Абстрактного «в любом лучше» не существует. Есть «лучше в таких-то условиях».
+2
насчет асма — размер, скорость. Насчет си — размер, скорость, переносимость. Хотя все зависит от задачи. С# как и жаба тянет за собой килотоны говна, а потом мне приходится идти и ломать свою жабу что бы купить еще памяти, потому что какому-то хй не хватает ума написать это на простом Си.
0
С# как и жаба тянет за собой килотоны говна
Особенно C#. Жабе стоит отдать должное, там небольшая JRE, которая мгновенно ставится и не мешается.

А вот дотнет… Это просто дикий ад. Нужно ставить все версии фреймворков. Инсталляторы разбросаны по сайту M$, что так просто не соберёшь (особенно, если учесть всякие сервис-паки, в которых надо ещё разобраться). Инсталляторы фреймворков тормозные, что-то докачивают (даже если считаются оффлайновыми), гадят временными папками на все(!) локальные диски и не удаляют их. Что-там evsi говорил, я не там ищу причины дерьмовости современного софта?
0
Что-то я ни разу не испытывал затруднений с установкой совта, просящего дотнет. И установка самого дотнета тоже не вызывала проблем. Все патчи ставятся виндой автоматически.
А вот JRE это был трындец. В свое время я на корню рубил все проги, просящие яву.
+1
Хрен с ней, с установкой (хотя у меня и с ней не возникало проблем). Зато .net приложения после накатывания фреймворков (а в новых виндах этого даже и не требуется) неотличимы от нативных. В том числе и по скорости. Да и аппетиты до памяти вполне сравнимы с нативными.
Вот на WM2003 это напрягало — два фреймворка по пять метров ставились на рамдиск, а ОЗУ было 64МБ на все. На МК пока что фреймворк — дикий оверхед. Но на ПК все пучком.
0
В том числе и по скорости. В том числе и по скорости.
В синтетических тестах.
0
Да и аппетиты до памяти вполне сравнимы с нативными.
А это — тем более. По памяти с Си сравниться очень трудно. Тут принято её экономить. Хотя бы сравнить, сколько занимает мультистрока по сравнению с контейнером строк в какомнить оопе.
Ну и на С++ придётся память ОЧЕНЬ транжирить, чтобы сделать также хреново, как на интерпретируемых. Заводить под строки буферы максимальной длины и не подрезать после того, как изменений уже не будет, и прочее.
-1
Тут принято её экономить.
Что вовсе не значит, что это удается сделать. Причина в традиционных менеджерах памяти для С и в особенностях того, как в С идет работа с памятью. Скажем, фрагментация памяти может (и приводит) к ее значительному перерасходу. К слову, «выделить и обрезать» — один из способов увеличить фрагментацию памяти.
+2
Причина в традиционных менеджерах памяти для С и в особенностях того, как в С идет работа с памятью.
Хм, а они где-то ещё используются, традиционные менеджеры? В MSVC, который я в основном применяю, используется встроенный менеджер винды, например.
0
Хм, а они где-то ещё используются, традиционные менеджеры? В MSVC, который я в основном применяю, используется встроенный менеджер винды, например.
Он не менее традиционен и от фрагментации не спасает. Принципиально решить вопрос с фрагментацией можно только с помощью GC, а это плохо сочетается с организацией работы с памятью в С.
0
Принципиально решить вопрос с фрагментацией можно только с помощью GC
С фрагментацией можно хорошо бороться с помощью специальных алгоритмов. Что касается GC, лучшее — враг хорошего. Точнее, «лучшее».
0
В MSVC, который я в основном применяю, используется встроенный менеджер винды, например.
Встроенный в винду — далеко не лучшая штука. Borland C++ ставит свой менеджер поверх виндового и в WinRAR'е (программа, между прочим, использующая интенсивные вычисления!) далеко обходит по производительности MSVC, хотя оптимизатор кода в BCC на уровне Delphi (т.е. на порядок отстает от MSVC).
+1
В синтетических тестах.
Тормозящую жабу встречал. Говорят, правда, что тормозит не сама жаба, а swing (один из ее гуи-тулкитов, вроде устаревший).
Тормозящего дотнета не встречал. Бывает, что поскрипываю зубами, видя, сколько оно выжрало ОЗУ (но максимум добрых слов обычно достается нативным программам — браузерам (без исключения), фокситу, скайпу, стиму, ноду, эксплореру — впрочем, в последнем 90% жрут довески, и часть из них как раз дотнетовская. и сильно радует, что дотнет-довески при сбоях не рушат эксплорер, да и сами сохраняют 90% работоспособности даже после тяжелых ошибок вроде out of memory или AV в подключенной нативной библиотеке).
+1
Говорят, правда, что тормозит не сама жаба, а swing (один из ее гуи-тулкитов, вроде устаревший).
Да, так они и говорят: «просто gc невовремя запустился», «просто всё остальное слишком быстро работает» и тому подобное по вкусу.
да и сами сохраняют 90% работоспособности даже после тяжелых ошибок
Хорошие нативные программки тоже прекрасно обрабатывают ошибки. Если их пишут не привыкшие к дотнетам и дельфи, где ошибки просто игнорятся.
0
Хорошие нативные программки тоже прекрасно обрабатывают ошибки
Это большая, очень большая редкость. И встречается чаще на языках, где есть нормальные средства их обработки. Таких, как дельфи.
0
И встречается чаще на языках, где есть нормальные средства их обработки. Таких, как дельфи.
Ерунда. Важно, обрабатывает программист ошибки или забивает. А то, что ты утверждаешь — рекламная маркетинговая чушь. AV — признак плохого кода, а не плохого языка.
0
Ага. А плохой код — следствие недостатков языка в примерно той же мере, что и недостатков программиста.
+1
Хорошие нативные программки тоже прекрасно обрабатывают ошибки. Если их пишут не привыкшие к дотнетам и дельфи, где ошибки просто игнорятся.
Кстати, учитывая отсутствие SEH в С — при вылетании AV в недрах GDI+ из-за попытки загрузить кривой JPEG она благополучно грохнется (либо придется весь SEH ручками делать, что не столь уж просто). QTTabBar на дотнете только перестает картинки показывать (и то, иногда чинится сам собой, без перезапуска).
0
но максимум добрых слов обычно достается нативным программам — браузерам (без исключения), фокситу, скайпу, стиму, ноду, эксплореру
ЭЙ! не гони на фоксит ридер! только что открыл три десятка (35 если быть точным) пдфников общим объемом под триста (272) метров. скушал (читать: показал) и не подавился. при этом памяти съел 223метра. и открывал это все меньше минуты.
0
Фоксит жрет до полугига. Не опера, но при дефиците памяти (у меня типично 4.2GB system commit при наличии 2.75GB физической памяти) это заметно.
Нод и дискипер жрут скромнее, по три сотни на рыло. Скайп — от полугига после запуска до полутора через недельку, стим тоже от полугига до гига. Лидируют опера и эксплорер — 1-2ГБ.
0
А, еще забыл помянуть добрым словом P2P качалки, некоторые из которых, к тому же, судя по всему текут. ApexDC спокойно жрет до гигабайта.
0
ой, про Р2Р не надо. у меня вот мюторрент висит и не подает признаков жизни. правда, те самые фотки млечного пути тянутся… ;) чего ему поплохело — хз. единственное что можно подозревать — на разделе для закачек всего пара гиг свободного места осталось.
а про хххDC я давно уже забыл. и не жалею.
кстати о «хороших маленьких програмках» в известно чьей классификации ;). меня этот самый мюторрент реально напрягает — чуть что, виснет и где-то лочится. помогает только полный ребут. то-ли дело transmission…
0
У меня он имеет свойство не отзываться и не тянуть. Сбой вроде как-то связан с косяками тех костылей, что там накручены вокруг кэширования дискового IO и с обилием завершенных, но не удаленных торрентов.
Но менять мюторрент на что-то другое не хочется. Обычно оно или выглядит как макос — красиво, работает, но до тонких настроек не доберешься, или представляет из себя недописанный клон мюторрента.
0
и с обилием завершенных, но не удаленных торрентов.
так в том и трабла, что последнее время больше пары-тройки торрентов у меня не бывает. а этот путь вообще один был. ну да ладно, опять подниму проксю, и вернусь к transmission.
Но менять мюторрент на что-то другое не хочется. Обычно оно или выглядит как макос — красиво, работает, но до тонких настроек не доберешься, или представляет из себя недописанный клон мюторрента.
я давно торренты на проксю скинул. единственно, недавно сервер лег. пока перебиваюсь локальным мюторрентом.
0
Фоксит жрет до полугига.
хм. ни разу такого не наблюдал. странно.
0
Стоит заметить, из всего перечисленного на дотнете только пара расширений к эксплореру (из пары десятков установленных). Остальные дотнетовские программы при отборе по «кто тут всю память выжрал?!» скромненько остаются в списке «так, это мелочь, это тоже». Хотя одну я недавно выкинул из автозагрузки, решив что незачем тратить 50МБ памяти (на самом деле меньше, из этих 50МБ 90% — shared memory, т.е. длл-ки и иже с ними) и иконку в трее на то, что я в последний раз использовал пару лет назад.
0
будь честен с собой, ведь это тебе не хватает ума написать что-то на простом С, поэтому приходиться раскошеливаться на память для компа.
0
ага. )) каждый должен себе написать альтиум и солид на асме и чистой сишечке. )))
+2
Ура, kolibri каждой домохозяйке!
0
может реактось?
и пусть после такой «винды» эти домохозяйки с радостью принимают линухи. :)))
0
ОЙ! что сейчас начнется… я правда не хотел спровоцировать еще одну ветку. ;)
+1
Не понимаю, что такого смешного в желании иметь быстрые и компактные программки, вместо раздутых мешков говна.
0
Вопрос как всегда в деньгах. Кто заплатит та разработку быстрых, компактных программ?
+1
Вопрос как всегда в деньгах. Кто заплатит та разработку быстрых, компактных программ?
Самые лучшие программы — чаще всего написаны just for fun. Коммерческое говно в первую очередь должно производить впечатление на потребыдло, поэтому оно такое раздутое. А для опенсорса (в меньшей мере, просто бесплатного) и тем более энтузиастов это не нужно.
0
Самые лучшие программы — чаще всего написаны just for fun.
Например, винда, которой вы пользуетесь. Или VB.
0
Например, винда, которой вы пользуетесь. Или VB.
А они лучшие?
0
А они лучшие?
А вы разве не самым лучшим пользуетесь?
+2
А вы разве не самым лучшим пользуетесь?
Пользуюсь хорошими программками, разумеется, по возможности. Но не для всего есть очень хорошие программки, приходится довольствоваться тем, что есть. Иногда приходится отказываться от хорошего — линуховое ядро классное, но организация ФС, GUI, софт меня совершенно не устраивают.
0
софт меня совершенно не устраивают.
А ведь там практически исключительно
Самые лучшие программы — чаще всего написаны just for fun
А для опенсорса (в меньшей мере, просто бесплатного) и тем более энтузиастов это не нужно.
Которые тебе нравятся.
+2
Которые тебе нравятся.
Стяпляпанные на скорую поделки на всяких Qt тоже не нужны. Лучшие программы написаны JFF не значит, что каждая любительская поделка — стоящая.
0
Лучшие программы написаны JFF не значит,
Зато значит, что большинство из них есть в линуксе или пришли из линукса. За исключением чисто виндовой freeware проприетарщины.
+1
Зато значит, что большинство из них есть в линуксе или пришли из линукса.
Совершенно не так. Большинство хороших программок под винду и написано. Портированных из линукса очень мало.
0
*полистал установленные хорошие программки* Не, они или коммерческие, или из линукса. За редкими исключениями.
0
Ничего. Я тоже такие хочу. Но я еще и понимаю, что дают «раздутые мешки говна» и почему они такие «раздутые».
0
Но я еще и понимаю, что дают «раздутые мешки говна»
И я понимаю. Рекурсия, на раздутых мешках пишут ещё более раздутые. Потому что стек и то, что он переполняется не слышали. Надеюсь, он скоро закончится и вся эта машина раздувания рухнет.
0
И я понимаю. Рекурсия, на раздутых мешках пишут ещё более раздутые.
Ответ неправильный.
Потому что стек и то, что он переполняется не слышали.
Стек не нужен. Я серьезно.
И да, сколько видел stack overflow — это какая-нибудь сишечка утонула в рекурсии. В последний раз, например, в ней тонул RichEdit.
0
Стек не нужен. Я серьезно.
Угу, нужен ООП-процессор. Чтоб вам всем и пользоваться тем, что сделано по вашим новомодным методам >_<
0
ООП процессор тоже не нужен — это неоптимально. Оптимальней оказывается RISC-процессор традиционного типа, спроектированный с учетом потребностей реализации ООП.
0
О, благодарю. Ни как не мог вспомнить как же эта ось называется. Надо поглядеть, на что она способна спустя почти 10 лет. Тогда она заинтересовала очень.
0
И что? Много изменилось? В те времена оно походило на нечто пригодное только для «пописать под это софт на асме». ЕМНИП там не было даже толкового GUI API и возможности использовать динамически связываемые библиотеки, из-за чего везде гуй был ручками и на редкость примитивен (по поведению, видом он косил под всякие скины из ХР, лонгхорна и прочего гламура).
0
я не говорю только си, а самое главное я не говорю не использовать других инструментов. Пример Bison/Yacc как компилятор-компиляторов (http://ru.wikipedia.org/wiki/Yacc). Я далеко не против perl, php и всего остального, но зачем? когда можно сделать то же меньшими средствами. С другой стороны, код на перле

#!/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
(with 77 registered patches, see perl -V for more detail)
Код на php:
#!/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)
Где мои ошибки в этих примерах?
+1
Где мои ошибки в этих примерах?
Ошибка в том, что сравнивать размер ничего не делающей программы бессмысленно.
+2
Как это? здесь есть задача вывести hello world на экран. Чем больше кода тем больше ошибок, тем больше утечек тем больше патчей и стараний закрыть костыли костылями. И даже если «ничего не делающая программа» умудряется сожрать 2.5мб памяти, это плохо.
0
Как это? здесь есть задача вывести hello world на экран.

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

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

Это как сравнить легковой автомобиль, грузовик и автобус по расходу топлива. Какой смысл сравнивать разные инструменты на неспецифических для них задачах?
+2
Совершенно согласен, инструменты разные. Задача одна. Здесь я скорее хотел показать правильность выбора инструмента для задачи «hello world». И правильно, не имеет смысл использовать скриптовый (данные) языки для решения этой задачи, но не имеет смысла и использования и для более сложных задач, которые одинаково просто могут решатся на сях и других языках. Пример использование сложных сторонних библиотек прикрученных к жабе или сишарпу. Пример Emgucv на C# и простой OpenCV для C. Другой вопрос если человек не будет знать С(С++), но будет знать жабу. Тогда он возьмет естественно жабу, т.е далеко не оптимальный инструмент, и из-за его выбора буду страдать исключительно я (как конечный пользователь продукта)
0
но не имеет смысла и использования и для более сложных задач, которые одинаково просто могут решатся на сях и других языках.
Ключевые слова «одинаково просто». Желательно так же их не только произносить, но и применять на практике. Потому как прикладных задач, которые «одинаково просто» делаются на С во многих направлениях уже просто не осталось. Причем, зачастую задач достаточно низкоуровневых, практически системных. Того, что раньше традиционно действительно делалось на С.
+2
Имхо, все библиотеки будь-то венды будь-то лини имеют стандартные вызовы, которые легко вызываются из си. Другой вопрос что и там могут быть ошибки, но это другой вопрос. Намедни имело дело с 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
0
Имхо, все библиотеки будь-то венды будь-то лини имеют стандартные вызовы, которые легко вызываются из си.
И что?
Если я все то же сделаю в пыхе я буду иметь в 10 раз большую утечку, и в 10 раз меньшую производительность.
Может быть. А может быть и нет. Зависит от того, как это реализовано в php. В жабе вся эта часть на самой же жабе и написана и там утечек нет. К слову, в данном случае лимитирующий фактор внешний ввод-вывод, так что производительность врядли будет отличаться в 10 раз. Если кормить реальными урлами из инета, то вообще врядли будет отличаться.
+1
Господа, ну как может пыха быть быстрее и менее глючной си, на которой она кстати написана

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==
==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)
Ошибки в openssl
что valgrind думает про пыху:
==12117==
==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кб?
0
Господа, ну как может пыха быть быстрее и менее глючной си, на которой она кстати написана
О «быстрее» никто не говорил. Речь шла о «если и медленее, то на практике это не заметно».
Кстати, «глючен» не С (разве что с компиляторами такая беда иногда приключается), а код, который на нем написан.
Имеет ли разница 2.8 метра или 288кб?
Зависит от того, что именно вы собираетесь делать.
+1
Curl C Elapsed time: 256 millisecs
Curl PHP Elapsed time: 274 millisecs
О да, огромная разница. А если увеличить размер странички и лить ее с далекого-далекого сервера в интернетах?
Имеет ли разница 2.8 метра или 288кб?
Если вычесть статические потребности (0 для С, 2.5МБ для PHP) — потребление память оказывается одинаковым. Чем больше собственное потребление памяти программой, тем менее существенна будет разница. Например, 1.000ГБ против 1.002ГБ.
+2
потом будет 1.100гб, потом 2гб, но какая ж разница. прогресс то двигается вперде. Нет лучше делать сразу, и пусть это будет 1.000 постоянно.
0
Точно. Как мой друг сказал,
напоминает про Резерфорда и его ученика, в журнале заметка была. Ученик очень гордился, что он много работает, Резерфорд его спрашивает: Что и в выходные? ДА! что и по ночам — да! Когда же вы думаете в таком случае?.. Так вот, когда же развиватели остановятся, чтобы подумать.
Не остановятся пока сами не утонут в своём болоте.
0
Нет лучше делать сразу, и пусть это будет 1.000 постоянно.
Не обольщайтесь, не будет.
+1
Потом будет 1.100гб против 1.102ГБ, потом 2.000ГБ против 2.002ГБ. Как видишь, разница только падает.
0
P.S. Даже если ты подразумеваешь под этим мемори лики — наивно полагать, что программа на С не течет. Очень, очень наивно. Особенно учитывая, что в PHP течет именно написанный на С интерпретатор.
0
Из-за чего? из-за неумения пользоваться. Вообще, в данном случае, виноват в некоторой форме opensource-way, где если кому то не хватает какой-то функции он сам идет ее допиливать.
0
Утечки — вина программиста, а не языка. К тому же, при равных скиллах программист на С оставит больше утечек, чем на более высокоуровневом языке. Особенно жабе или дотнете.
0
К тому же, при равных скиллах программист на С оставит больше утечек, чем на более высокоуровневом языке. Особенно жабе или дотнете.
Хватит повторять рекламные фразы. Их и в зомбоящике хватает.
0
Это не реклама, это мой опыт. Сколько видел текущих — все нативка. C, C++, Delphi.
0
У меня ничего не падает. Наверно тоже выбирает Asm/C/C++ хейтеров и выдаёт AV каждые 5 минут.
0
наивно полагать, что программа на С не течет
Угу, а как текут всякие явы… Билл Гейтс сказал, что 640 кБ хватит всем. Теперь уже так натекло, что 100 ГБ — не всегда хватает.
0
Угу, а как текут всякие явы…
Как раз в яве устроить утечку весьма непросто. Можно, конечно, но не просто.
0
Билл Гейтс сказал, что 640 кБ хватит всем.
Я не фанат Билла Гейтс’а, но, справедливости ради, он такого не говорил.
0
Я не фанат Билла Гейтс’а, но, справедливости ради, он такого не говорил.
Гм, а ты уверен? Как можно с очевидностью говорить о том, что дошло до тебя через 10 рук?
Что точно можно сказать — например, то, что браузер жрёт много памяти и медленно работает. Это факт. То, что я вижу своими глазами. А то, что кто-то написал или сказал — просто мнение.
0
например, то, что браузер жрёт много памяти и медленно работает. Это факт.
Факт в том, что я тебе еще вчера предлагал поменять жирный и тормозной файрфокс, кототый жрет память, и написан на смеси С++ и JavaScript на легкий и аложрущий links, который на С. А то только языком молоть.
+2
Факт в том, что я тебе еще вчера предлагал поменять
Захочу — поменяю. Не захочу — оставлю. Это не отменяет того, что FF, несмотря на достоинства, написан левой индусской пяткой и жрёт памяти как стадо слонов.
0
Нет, FF жрет память на то, чтобы обеспечить отсутствующую в links функциональность. Если она тебе не нужна — возьми линкс. Если нужна — прекрати ныть, что за эту фуонкциональность приходится платить.
Впрочем, сравнение с оперой таки заставляет задуматься, действительно ли FF нужна эта память. Опера все же поэкономичней, при более-менее сравнимой функциональности.
+1
Нет, FF жрет память на то, чтобы обеспечить отсутствующую в links функциональность.
Нет, он жрёт на 200МБ больше, чем нужно для функциональности.
-1
И тормозит тоже этак раз в 5-20 сильнее
0
Не нравится — возьми другой. И да, не зная, как он устроен (и даже не зная, как это реализуется в целом) сделать точную оценку, сколько он тратит лишней памяти ты не можешь.
+1
Нет, он жрёт на 200МБ больше, чем нужно для функциональности.
мыши плакали, кололись, но продолжали жрать кактус :)
+2
Круто. Откуда познания в том, сколько надо? На чем основаны? на чвете верхней части комнаты?
0
на закругленных уголках и полупрозрачностях. очевидно ведь! )))
+2
Стоит заметить, что CSS3 — это не только закругленные уголки, но и пять строчек текста там, где раньше использовалась целая картинка.
0
<lifelover_mode ON>
ты чтоО_о!!! это ересь! картинкой — настоящий инженерный подход. а все эти ваши расширения — от лени и нежелания/неумения думать и делать легко, просто и элегантно.
<lifelover_mode OFF>
+1
<lifelover_mode ON>
Да продолжайте пользоваться своими раздутыми мешками говна, которые с каждым годом становятся всё жырнее.
Меня заебали ваши смехуечки.
0
да и вы ими продолжаете пользоваться. только я понимаю почему ресурсов требуется больше. а вы исходите желчью на ровном месте.
+1
да и вы ими продолжаете пользоваться.
Не пользуюсь по возможности.
только я понимаю почему ресурсов требуется больше.
«Ресурсов больше» — это ничего не сказать. Это пиздец просто. Быдлокодеры совсем с жиру взбесились. Что же, ты сам заслуживаешь этого «прогресса», если спокойно это хаваешь.
-1
Не пользуюсь по возможности.
ога. по прежнему плюеетесь и пользуетесь лисой. несмотря на.
«Ресурсов больше» — это ничего не сказать. Это пиздец просто. Быдлокодеры совсем с жиру взбесились
опять про лису напомнить? и про привычный инет, в который вы каждый день ходите. а от линкса отказались. (догадываюсь по каким причинам)
если спокойно это хаваешь.
меня это более чем устраивает. я предпочитаю личный комфорт ресурсам, а не экономию ради экономии.
+1
Захочу — поменяю. Не захочу — оставлю.
Дело конечно твое. Просто человек, который ненавидит «все эти ООП и жирные жрущие програмы», но при этом ими же и пользуется не очень хорошо выглядит в глазах окружающих. Очень похоже, что он немного непоследователен.
+2
Как можно с очевидностью говорить о том, что дошло до тебя через 10 рук?
Вы про 640кБ очевидно процитировали в этом топике уже сколько раз? Сами лично с ним общались?
0
Теперь уже так натекло, что 100 ГБ — не всегда хватает.
Утечки с потреблением на задачи не путаем.
0
Утечки с потреблением на задачи не путаем.
Разумеется. Ничего не спутано.
0
100Гб — потрачено на задачи, а не утекло. Возможно, оно потрачено неоптимально, но именно потрачено. Можно налить полный бассейн воды, а можно вымыться под душем, но утечками будет только то, что утекло в землю через дырявые трубы.
0
Потому как прикладных задач, которые «одинаково просто» делаются на С во многих направлениях уже просто не осталось
Не осталось тех, кто хорошо напишет на Си эти вещи. Впрочем, те, кто не способен освоить указатели, работу с памятью, битовые потоки и операции, ничего хорошего не напишут ни на чём. Кто способен — всякое говно вроде яв не будет использовать.
0
Не осталось тех, кто хорошо напишет на Си эти вещи.
Их есть и много. Только никому не нужна программа, которая устареет задолго до релиза.
Кто способен — всякое говно вроде яв не будет использовать.
Ничем не обоснованный вывод.
+1
Их есть и много.
Мало тех, кто готов и хочет писать программки, которые просто будут делать свое дело. Мало тех, кто способен использовать указатели. Для большинства, одиночный указатель — проблема и ограниченные шаблоны использования, двойной — вынос мозга (мозжечка, скорее), тройной — даже не слышал. Битовые потоки операции — ещё сложнее. А ведь это простые вещи вроде молотка и гвоздей. Если мастер не умеет их использовать, то он никакой не мастер и никакие инструменты не помогут.
Только никому не нужна программа, которая устареет задолго до релиза.
Хорошей программе вообще нечего устаревать. А всякая платная однодневная ерунда — не нужна.
0
Для большинства, одиночный указатель — проблема и ограниченные шаблоны использования, двойной — вынос мозга (мозжечка, скорее), тройной — даже не слышал.
Ничего сложного в них нет. Хорошего, в 99% случаев, тоже. Последний процент приходится на те случаи, где необходима оптимизация любой ценой.
+1
Хорошего, в 99% случаев, тоже.
Это простые вещи вроде молотка и гвоздей. Хорошего в них нет только для тех, кто не может гвоздь забить, не двинув по пальцу, но таким и не быть мастером.
0
Гвоздями самолет не собирают.
+1
Гвоздями самолет не собирают.
И к чему этот коммент? Ну, заклёпочками. Суть та же.
0
И к чему этот коммент? Ну, заклёпочками. Суть та же.
Суть в том, что заклепочками ты самолет не собереш. И что совреенные инструменты давно перешагнули сложность молотка.
+2
Суть в том, что заклепочками ты самолет не собереш.
Без заклёпочек — тоже. А не умея даже заклёпочку забить и не стукнуть по пальцу — тем более.
И что совреенные инструменты давно перешагнули сложность молотка.
Да, какую-нить IDE, занимающую 10GB и запускающуюся пол часа трудно сравнить по практичности и простоте с молотком.
0
Да, какую-нить IDE, занимающую 10GB и запускающуюся пол часа
пруф в студию!!! хочу посмотреть хоть на одного такого монстра.
+2
Без заклёпочек — тоже.
выкуси !
0
Я умею забить гвоздь. Но я не буду собрать самолет гвоздями.
Да, какую-нить IDE, занимающую 10GB и запускающуюся пол часа трудно сравнить по практичности и простоте с молотком.
Равно как и десятитонный паровой молот. Или автоматический станок, сваривающий или склепывающий детали самолета. Молоток в глубоком пролете.
+1
Равно как и десятитонный паровой молот. Или автоматический станок, сваривающий или склепывающий детали самолета.
Современный софт — не молот и не станок, а просто очень много оверхеда и 1% полезной работы.
-1
Сними коричневые очки.
+2
Сними коричневые очки.
Хм, если это и очки, то очень избирательные. Хорошие программки остаются сами собой.
0
Критерий «хорошие» субъективен. А коричневые очки ничуть не лучше розовых.
+1
Критерий «хорошие» субъективен.
Да, естественно. Лично мне нравится быстрое, маленькое, толковое и продуманное.
0
Лично мне нравится толковое, продуманное, быстрое и маленькое.
Вот только отличия в понятии «толковое и продуманное», а также другой порядок приоритетов результаты сильно изменяют.
+1
Заклепочки — это уже не гвозди. И ставятся они далеко не молотком.
0
Мало тех, кто готов и хочет писать программки, которые просто будут делать свое дело.
Их немало. Я как раз только таких на работу и беру.
Хорошей программе вообще нечего устаревать.
Вы не поверите, но большинство программ пишутся не для того, что бы вы могли любоваться красотой исполнения, а для решения вполне реальных повседневных задач у вполне конкретных людей. А эти задачи имеют свойство изменяться, появляться и исчезать. И программа, которая не решает эти изменившиеся или новые задачи этим конкретным людям не нужна, с их точки зрения программа устарела.
+4
О да. Сколько ж задач я снял с TODO-листа просто потому, что они успели стать неактуальными за время решения…
0
Здесь я скорее хотел показать правильность выбора инструмента для задачи «hello world».
Кстати, выбор-то неправильный. На sh получилось бы короче и проще. И сопровождать легче.
+2
Здесь я скорее хотел показать правильность выбора инструмента для задачи «hello world».

Это просто синтетический тест, который мало о чем говорит, и результаты (в данном случае) были заранее известны. Выбор оптимального инструмента – это очень сложная задача, нужно учитывать очень много факторов, а не просто сравнение по одному из критериев. Более того, в разных условиях, для одной и той же задачи, могут быть разные оптимальные инструменты.

В данном случае, если Вы уж находились в консоли, то оптимальным результатом для вывода на экран «hello world» могло бы быть

int@home:~$ echo "Hello World!"
+2
Как сказать у нас то и критериев не много все от чего мы можем отталкиваться это конфиг системы пользователя, + удобность работы, но это скорее дизайн. Я не беру во внимание критерии «удобности» программисту. Если вы пишете программу и за это зарабатываете деньги, будьте любезны писать качественно
кстати в данном случае
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)
0
Как сказать у нас то и критериев не много все от чего мы можем отталкиваться это конфиг системы пользователя, + удобность работы, но это скорее дизайн

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

Если вы пишете программу и за это зарабатываете деньги, будьте любезны писать качественно

Золотые слова (с). Только в разработке ПО никто, увы, не отменял закон «перехода количества в качество». Быстро, Качественно, Дёшево – выбирайте две опции из трех, чудес не бывает.

кстати в данном случае

Опять же все зависит от критериев оценки. Ели Вам нужно «одноразово» вывеси определенное сообщение в консоль – сомневаюсь, что вы будете писать программу на С.
+2
И правильно, не имеет смысл использовать скриптовый (данные) языки для решения этой задачи
А вот это еще большой вопрос, если рассматривать не только вопрос производительности, но и другие критерии.
+2
не только вопрос производительности, но и другие критерии
Типичная политикофразочка. Производительность — это очень важно. Неэкономными к ресурсам программами я обычно брезгаю пользоваться.
-1
Из принятие во внимание только одного критерия ничего хорошего не выходит. Это наглядно показывают гонка мегагерц, гонка мегапикселей и гонка миллисекунд отклика. Первая принесла тормозные 4-гигагерцовые печки netburst/prescott (шутка ли, C2D производительнее и экономичнее при втрое меньшей тактовой), вторая — шумные многомегапиксельные матрицы с песчинку размером (под говенным объективом, зачастую, который обеспечивал минимальный элемент изображения в сотню пикселей размером), третья — искусство измерения миллисекунд и 18-битные матрицы вместо 24-битных.
0
Разбазаривание и транжирство — плохо. Почему я должен делать исключения для софта?
0
Почему я должен делать исключения для софта?
Ты не должен, но делаеш. Почему?
+1
То, что один называет разбазариванием, другой называет вкладом в будущее.
0
Куда FF вкладывает мою память? Не надо пороть чушь, ей больно.
0
Понятия не имею. Скорее всего в быструю работу и поддержку технологий. Возьми линкс, он ее никуда не вкладывает. Или оперу, она медленнее, но экономичней.
0
Знаете, в конкретно данный момент ваш «правильный выбор» С для написания HelloWorld не является правильным для меня. Более того, он совершенно невозможен.
В конкретно данный момент для меня правильной является
print "Hello, World!" -- Yes, this is Lua
Только потому что Lua у меня есть, а вот компилятора С нет.
И даже C# вариант будет выигрывать у чистого С, потому как программа на C# будет выполнять поставленную перед ней задачу (компилятор нативный в .NET), а вот С программа так и останется лежать в исходниках.
+2
Только потому что Lua у меня есть, а вот компилятора С нет.
Тоже мне причина. Притянул за уши. А у меня C есть, а Lua — нету.
-1
То есть не причина? Давайте посмотрим, так ли притянуто за уши?

Что бы написать на Lua, я: открыл интерпретатор, вбил строку, получил результат. Пускай я потратил минуту времени и 1 метр памяти.

Что бы сделать то же самое на Си, я должен был бы: открыть браузер, найти компилятор, скачать его, установить его, написать код, скомпилировать, запустить. Сколько времени ушло на исполнение такой программы? Сколько оперативки оно заняло?
+1
И даже C# вариант будет выигрывать у чистого С, потому как программа на C# будет выполнять поставленную перед ней задачу (компилятор нативный в .NET), а вот С программа так и останется лежать в исходниках.
вы про что?
+1
Самое начало комментария говорит про что я:
Знаете, в конкретно данный момент ваш «правильный выбор» С для написания HelloWorld не является правильным для меня.
0
Про то, что «правильный выбор» в 90% случаев есть результат взвешенной оценки. А набор критериев и веса при них у каждого свои.
+1
Производительность и требования к ресурсам никогда небыли сильной стороной у интерполируемых языков.
Но и слабой стороной производительность многих «интерпретируемых» языков давно уже не является. В кавычках, поскольку в той же жабе и дотнете не так просто определить, интерпретируемый он или компилируемый. Когда появились первые реализации JIT еще как-то было понятно — вот байткод, а вот его скомпилированная версия. С появлением HotSpot-а все перемешалось в кучу, одна и та же часть кода может интерпретироваться, а спустя какое-то время превратиться в нативный бинарник скомпилированный на ходу под конкретный процессор.
+3
Да, согласен, с внедрением динамической компиляции уже тяжело сказать где «интерпретация» а где «наивный код».
0
А то еще и NGEN вспомнить можно, когда при установке .net программа превращается в нативный бинарник, оптимизированный под конкретный процессор. За счет этого оно легко может оказаться производительнее нативной программы на С, которую приходилось компилировать под некий средний процессор.
0
Но и слабой стороной производительность многих «интерпретируемых» языков давно уже не является.
Не является потому что раньше им приходилось завоёвывать право на жизнь. Тогда и придирались сильнее. Теперь, когда мозги зомбированы этой хренью, достаточно отговорок «вы ничего не понимаете, не несите ересь».
-1
Ересь несешь ты. Достаточно провести эксперимент и все встает на свои места. Можно кричать про «синтетические тесты», но жизненные тесты показывают куда более печальную ситуацию — разницы в производительности между истинными интерпретаторами, JIT и нативным кодом нет вообще.
+1
Да, можно и нативное написать так, что будет тормоглючить.
0
Причина не в этом, а в том, что с точки зрения производительности абсолютно пофигу, на каком языке написана программа, если 99% времени она проводит в WaitForMultipleObjects.
0
Как это?
Вот так вот. Не подозревал, что подобное уточнение для вас в нове.
Чем больше кода тем больше ошибок, тем больше утечек тем больше патчей и стараний закрыть костыли костылями.
Количество бинарного кода и количество исходного кода — две разные вещи. Перечисленные вами проблемы это проблемы, преимущественно, исходников, а не бинарников.
И даже если «ничего не делающая программа» умудряется сожрать 2.5мб памяти, это плохо.
Это никак. И ничего не говорит о самой программе и/или количестве проблем в ней. Писанная на асме программа на несколько сотен байт все равно взаимодействует с операционкой, со всеми теми мегабайтами кода (вариант ембеддед пока оставим в стороне). Вас это, почему-то, не смущает.
+1
т.е интерпретатор был написан не из исходников? т.е если напишу скажем так (что явно неправильно):

void f(void)
{
char *a = malloc(3);
strcpy(a,"1234");
}

То мой выходной бинарник не будет иметь этой проблемы? Компилируется на ура, работает — нет.
Как вы думаете конечный пользователь предпочтет что бы программу в одно и тоже время можно было запустить >9000 раз или всего 1 при 4мб озу и скрипте на php.
0
т.е интерпретатор был написан не из исходников?
То есть операционная система и libc были написаны не из исходников? К слову, «интерпретатор» тут не очень подходящий термин. Почему — я написал выше.
0
что-то не вник в предложение. Из исходников и в них вся та же проблема. Чем больше кода — тем больше ошибок. Но признаю иметь Jvm который таже написан на сях(с++) который также вызовет все тоже из либц + еще дополнительно куча говна значительно хуже чем просто иметь либц
0
что-то не вник в предложение. Из исходников и в них вся та же проблема. Чем больше кода — тем больше ошибок.
Точно. По мере усложнения задачи размер кода на С будет расти быстрее. Что, как бы, намекает.
Но признаю иметь Jvm который таже написан на сях(с++) который также вызовет все тоже из либц + еще дополнительно куча говна значительно хуже чем просто иметь либц
Да, я в курсе, что вы предпочитаете свое говно вместо проверенного.
+2
Но размер кода все равно будет меньше суммы (ваш код+универсальной vm/интерпретатора)
0
Но размер кода все равно будет меньше суммы (ваш код+универсальной vm/интерпретатора)
Только при условии, что размер кода на жабе растет с такой же скоростью как и код на С для получения одинаковой функциональности. А это не так.
+2
Только при условии, что размер кода на жабе растет с такой же скоростью как и код на С для получения одинаковой функциональности. А это не так.
Опять синтетические тесты? Или там взывали готовое (не посчитав, разумеется, размер либы), а тут сделали вручную?
0
Опять синтетические тесты?
Угу. Синтетический тест под названием «реальная жизнь».
Или там взывали готовое (не посчитав, разумеется, размер либы),
Жабовский rtl весьма функционален искаропки.
+1
Жабовский rtl весьма функционален искаропки.
А зачем? В libc вот всё самое необходимое. На все случаи жизни всё равно не напихаешь, так что «очень функционален» — как раз подходит для синтетических тестов…
0
А зачем? В libc вот всё самое необходимое. На все случаи жизни всё равно не напихаешь,
В итоге программа использует кучу сторонних библиотек.
так что «очень функционален» — как раз подходит для синтетических тестов…
Нет, для вполне реального софта. Был у меня, кстати, несколько лет назад подобный проект. Из стороннего только ant, да и тот только для сборки, а не часть программы.
+2
В итоге программа использует кучу сторонних библиотек.
Ну и что. Каждая деталька должна выполнять только свою функцию. RTL — свою, библиотека для работы с графикой — свою. Жаба тоже частенько тянет за собой сторонние библиотеки (причём в виде нативных бинарников на Си).
0
Ну и что.
Во-первых, разница в объеме исходного кода libc+сторонние библиотеки+собственный код vs libc+jvm+собственный код сокращается еще быстрее. Во-вторых, качество RTL и того, что она тащит с собой уже проверено. Качество сторонних либ для С не всегда одинаково.
+1
Во-вторых, качество RTL и того, что она тащит с собой уже проверено.
Но в RTL нельзя запихнуть всё на все случаи жизни. Да и не нужно — RTL должна быть самой собой.
Качество сторонних либ для С не всегда одинаково.
Как и для жабы.
0
Как и для жабы.
Мой ответ вам не понравится, но, тем не менее, не только же вы его прочитаете. Так вот: сколько С-шных библиотек пишутся с тестами? для жабы этот процент весьма высок, из широко используемого — большинство. И покрытие тестами тоже весьма высоко, как правило авторы стремятся к 100% покрытию. Это значит, что все условные переходы и каждая строчка кода проверяется тестом. Это, безусловно, не гарантирует полное отсутствие ошибок, но количество ошибок в пересчете на строчку кода значительно ниже. Есть и другие существенные моменты. Скажем, если используется несколько С-шных либ и в каждой используется свой менеджер памяти, то скрестить их безболезненно в одной программе зачастую весьма нетривиальная задача, чреватая появлением ошибок или утечек. В жабе эта проблема отсутствует в принципе. Да и утечку устроить не так просто.
+1
Так вот: сколько С-шных библиотек пишутся с тестами?
Насколько я знаю, из широко используемого — почти всё. Вот, так, например.
Скажем, если используется несколько С-шных либ и в каждой используется свой менеджер памяти, то скрестить их безболезненно в одной программе зачастую весьма нетривиальная задача, чреватая появлением ошибок или утечек.
Да, есть такое. Впрочем, обычно причина в авторах библиотек, которые зачем-то решили извратиться. А не в самом Си.
Да и утечку устроить не так просто.
Да и без утечек памяти не напасёшься.
0
Насколько я знаю, из широко используемого — почти всё. Вот, так, например.
Первый на вскидку взятый zlib нормальных тестов не имеет.
Впрочем, обычно причина в авторах библиотек, которые зачем-то решили извратиться.
Прежде чем критиковать решение авторов библиотеки, видимо, стоит, все-таки, задуматься над причинами.
А не в самом Си.
Ну да. Проблема в сложившейся традиционной инфраструктуре, в частности типичным решениям в аллокаторе.
Да и без утечек памяти не напасёшься.
Думаю, JVM целенаправленно выбирает java haters и съедает на их компьютерах всю память.
+1
Первый на вскидку взятый zlib нормальных тестов не имеет.
Угу. Сам на баг напоролся когда-то, пришлось городить «workarround». Впрочем, и явалибы не такие уж безупречные.
Прежде чем критиковать решение авторов библиотеки, видимо, стоит, все-таки, задуматься над причинами.
Причины представляю. Впрочем, это всё равно не повод городить. В крайнем случае, можно в отладочной версии нагородить что нужно, а в релизной применять стандартное.
Думаю, JVM целенаправленно выбирает java haters и съедает на их компьютерах всю память.
И убунта, похоже, также поступает.
0
И убунта, похоже, также поступает.
Похоже на то. У меня, например, сейчас всего 220 метров занято (из 8 гиг).
0
В крайнем случае, можно в отладочной версии нагородить что нужно, а в релизной применять стандартное.
Нужно оно, как раз, в релизе. Дефолтный менеджер не отличается ни скоростью, ни оптимальностью. Приходится выбирать — стандартное говно или несовместимая конфетка.
0
Думаю, JVM целенаправленно выбирает java haters и съедает на их компьютерах всю память.
этапять! )))
+2
Но размер кода все равно будет меньше суммы (ваш код+универсальной vm/интерпретатора)
Кстати, вы, почему-то, постоянно выводите за рамки качество и проверенность кода сводя все к арифметической сумме размеров. Что, вобщем-то, некорректно, поскольку код написанный вами проверяли, в лучшем случае, только вы. libc и jvm работают уже много лет у миллионов пользователей.
+2
Но размер кода все равно будет меньше суммы (ваш код+универсальной vm/интерпретатора)
Во первых, с точностью до наоборот. Во вторых, код VM обкатывается на куда большем количестве машин и в целом менее глючен, чем аналогичное количество своего.
0
Во первых, с точностью до наоборот.
С чего это?
0
С того, что при более высоких, но фиксированных статических расходах снижает динамические. Примерно та же причина, по которой винда дешевле тополя, хотя стоимость НИОКР винды пожалуй повыше будет, или, как минимум, сравнима (и уж точно не 10 порядков, как разница в цене произведенной единицы).
+1
если бы он не был глючен мы бы имели stable релиз, а не попытки запилить костыли костылями." Google: Уязвимость Java -> Результатов: примерно 15 400 000"
Я не говорю что мой код будет лучше, я говорю что я могу его исправить. А не как с openssl исправления которого ждут уже лет 5-ть
0
" Google: Уязвимость Java -> Результатов: примерно 15 400 000"
С каких пор количество багов в конкретном продукте стали мерять гугловой статистикой?
+1
признаю, плохой пример
0
Но признаю иметь Jvm который таже написан на сях(с++) который также вызовет все тоже из либц + еще дополнительно куча говна значительно хуже чем просто иметь либц
А теперь заменяем JVM на CC, libc на ассемблер, а С на машинный код и говном полит уже С.
+1
да, только асм не настолько переносим. В этом его проблема
0
да, только асм не настолько переносим. В этом его проблема
Разве только в этом? Оптимально писать на асме под современные процы с учетом всех нюансов задача весьма не тривиальная. А если этого не делать, писание на асме теряет смысл.
+2
В 90% случаев причина отказа от ассемблера вовсе не переносимость. До сих пор мало кто из прикладников вспоминает об этом.
И да, в аргументе переносимости си так же уступает жабе, как ассемблер самому си.
0
Как вы думаете конечный пользователь предпочтет что бы программу в одно и тоже время можно было запустить >9000 раз или всего 1 при 4мб озу и скрипте на php.
Сильно зависит от программы. 99% не требуется запускать более одного раза.
+2
вы уже решаете за пользователя сколько раз ему запустить приложение?
0
вы уже решаете за пользователя сколько раз ему запустить приложение?
Я, например, не решаю. Но и не заставляю.
0
Я и есть пользователь.
+1
Да при том, что Hello World (ну, в данном случае это «экран чорным залить») на OpenGL будет намного проще и экономичнее к ресурсам, чем оно же на Unreal Engine 3. А вот Gears of War на чистом OpenGL уже будет в разы больше и сложнее, чем на UE3, а учитывая, что у авторов UE3 немалый опыт в написании быстрых и мощных движков — еще и намного глючнее, тормознее и прожорливей.
Надо различать статические издержки и динамические.
+1
Ошибка в том, что сравнивать размер ничего не делающей программы бессмысленно.
Почему же? Получишь значения статического оверхеда.
0
Ну и что дальше? Какой от него прок?
+2
От оверхеда никакого проку. Он лишь мешает.
0
От оверхеда никакого проку. Он лишь мешает.
От знания его размера какой прок?
+2
Оценить экономность этих инструментов, разумеется.
0
Оценить экономность этих инструментов, разумеется.
Думаете получится?
+1
зачем?
вот эклипс. кушает 250метров. какая мне разница сколько из них ест сама жаба — 10метров или 10кил?
+1
какая мне разница сколько из них ест сама жаба — 10метров или 10кил?
Жаба — это вообще жесть. Как отхватит себе здоровенный кусок. Жаба она и есть жаба, даже если это софт. Причём предлагается догадаться сколько ей понадобится. Типичное издевательство «угадай сколько я хочу, а не то упаду, а дашь больше — всё равно спасибо не скажу». Вот и приходится своп раздувать до неприличных размеров.
0
хм. у меня памяти достаточно. гиг-другой стабильно свободны. (физической)
вот сейчас 1,2 свободно. при альтиуме, солиде, эклипсе (и прочего по мелочи типа фоксит ридера с доками) и лисе с двумя десятками вкладок, в одной из которых киношка вертится.
0
не жмитесь. 4гига ддр2 сейчас стоят полтинник. правда и на х64 ось придется перелезть. но оно того стоит.
0
не жмитесь. 4гига ддр2 сейчас стоят полтинник.
Жабе и этого мало зачастую. А своп включать не хочется, потому что винда так медленней работает и больше подтупливает. Конечно можно сказать «выбрось винду», но причина проблемы не в винде, а в диком потреблении памяти жабой.
0
но причина проблемы не в винде
Она таки в винде. Я, напомню, регулярно гоняю много толстых программ на жабе. Из 8 гиг у меня крайне редко бывает использовано больше 5.
0
регулярно гоняю много толстых программ на жабе
подскажи парочку. интересно, как они в винде поведут себя.
0
Сорри, это софт, который я пишу. Да и врядли тебе он понадобится :)
0
понял :)
0
Жабе и этого мало зачастую.
покажите десктопную жабопрогу способую проглотить 4-8гиг и не подавиться.
(пережим фоток млечного пути и подобные операции не рассматриваем)
А своп включать не хочется, потому что винда так медленней работает и больше подтупливает.
у вас что то не то в консерватории.
а в диком потреблении памяти жабой.
спорно. очень. давайте пройдемся по функционально насыщенным IDE.
эклипс 250метров. (стартует 10сек)
слик сотню.
авростудия6 200метров (стартует полторы минуты)
авростудия4 полтинник.
кокос 130 (тот же эклипс строго говоря)
кодеблок полтинник
кейл полтинник
кактус11 110метров (без проекта)
надоело запускать.
вполне нормальные цифры.
+1
От оверхеда никакого проку. Он лишь мешает.
Он делает свою задачу. Знать его нужно лишь для того, чтобы найти ту точку, начиная с которой даваемый оверхедом выигрыш превышает сам оверхед.
0
Желаю удачи вам в сопровождении среды разработки, написанной на асм. И на си тоже.
Упоминая и расхваливая плюсы, не забывайте и про минусы, которые порой перекрывают все озвученные плюсы.
+1
Желаю удачи вам в сопровождении среды разработки, написанной на асм.
Смотря что считать средой разработки. Если хрень, которая занимает 10ГБ и запускается пол часа, предназначенная для написания такого же говна, то такого на асме не пишут. На асме пишут маленькие, хорошие, полезные программки.
0
ну ты сразу примеры приводи. Хоть одну среду разработки на асме, которая, хотя бы, подсветку синтаксиса может.
+2
ну ты сразу примеры приводи. Хоть одну среду разработки на асме, которая, хотя бы, подсветку синтаксиса может.
А что в асме подсвечивать, впрочем, fasm — прекрасная среда разработки на ассемблере (на нём же и написанная), которая подсвечивает.
0
Помоиему на wasm.ru (могу ошибаться) был редактор для асма с подсветкой. Там WinAPI изучали. Неплохой в итоге редактор получился. маленьки и шустрый.
Другое дело что то был просто редактор, а не среда.
0
На асме пишут маленькие, хорошие, полезные программки.

Вы пропустили «почти ничего не делающие» в перечислении.
+2
Вы пропустили «почти ничего не делающие» в перечислении.
«Ничего не делающие» в твоём представлении на деле означает «делающие кучу всякой херни, а основную задачу делающие паршиво». А «делающие» —
Делали бы новомодные «программисты» тот же Therac-25, он бы играл музыку, показывал фильмы и интернеты, а своё дело делал ещё хуже, чем оригинал. Начал бы качать обновления посреди сеанса и завис.
0
Ой, s/Ничего не делающие/Делающие/
0
«Ничего не делающие» в твоём представлении
Вы моего представления не знаете, так что не приписывайте мне выдуманную вами чушь.
0
Делали бы новомодные «программисты» тот же Therac-25, он бы играл музыку, показывал фильмы и интернеты, а своё дело делал ещё хуже, чем оригинал. Начал бы качать обновления посреди сеанса и завис.
На асме он благополучно делал именно это даже без качания обновлений.
0
Вы пропустили «почти ничего не делающие» в перечислении.
Нет, я встречал и делающие. Но обычно функционал сильно уступал аналогам на ЯВУ, а вот падать с AV они просто обожали при любой проблеме.
0
Программка из richedit и меню с пунктами «new/open/save/exit/about» средой разработки не является. А более функциональное на асме пишет полтора маньяка.
+2
насчет асма — размер, скорость.
По размерам исходного кода и скорости написания асм как бы не в лидерах. Кстати, по поводу скорости исполнения там тоже не все так просто и однозначно.
Насчет си — размер, скорость
Размер кода работы, например, с базой данных и, опять-таки, скорость написания такого кода тоже будет оставлять желать лучшего.
Хотя все зависит от задачи.
Именно. «Размер и скорость» это тоже не абсолютные характеристики без указания на то, размер и скорость чего имеются в виду.
С# как и жаба тянет за собой килотоны говна
Сейчас каждая система тянет за собой «килотонны говна». На досуге попробуйте сделать du -sh /lib. Замечу, эти все килотонны написаны на С, что, как бы, намекает, что применение асма или С не гарантирует «размер и скорость».
+2
Кстати, по поводу скорости исполнения там тоже не все так просто и однозначно.
Об этом есть неплохой текст: "Не тормозит". Да, не надо смотреть на домен. Этот кусочек текста как раз таки по делу.
Сейчас каждая система тянет за собой «килотонны говна».
Даже эта?

Или эта?

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

Что-то я не заметил говна. Всё при себе, и всё только по делу.
«Размер и скорость» это тоже не абсолютные характеристики без указания на то, размер и скорость чего имеются в виду.
Да, разумеется. Если качество важнее, размер и скорость — понятно чего. Если же на качество плевать, то эти слова приобретают другой смысл, который ты назвал.
0
Слушай, мы же не школьники. Пройдись-ка анализатором зависимостей на предмет что твои «легкие» программы требуют для запуска.
0
Слушай, мы же не школьники. Пройдись-ка анализатором зависимостей на предмет что твои «легкие» программы требуют для запуска.
Всё стандартное ничего лишнего.

Это действительно лёгкие и быстрые, и вполне функциональные.
0
опенгл стандартное для программ?
наличие оле говорит что в дирректории есть не всё, что нужно программе. или я её с чем то путаю?
0
опенгл стандартное для программ?
Стандартный компонент винды.
наличие оле говорит что в дирректории есть не всё, что нужно программе
OLE тоже для взаимодействия со стандартными компонентами.
0
.NET тоже стандартный компонент винды. И программы на дотнете тоже небольшие. :)
+1
.NET тоже стандартный компонент винды
Позже прилепили. Идёт из коробки, но называть его стандартным я бы не стал. Просто ставится вместе с виндой, и если оторвать, ничего винде плохого не сделается.
А OllyDbg (и Wavosaur, думаю) и на Win9x спокойненько запустится.
0
Идёт из коробки, но называть его стандартным я бы не стал. Просто ставится вместе с виндой, и если оторвать, ничего винде плохого не сделается.
Ну.нет идет во всех новых версиях винды. Сама винда его так же использует и без него уже не работает. Поведение то же самое, что и у user32.dll.
+1
Сама винда его так же использует и без него уже не работает.
Ну, от XP мона оторвать. Софтины, требующие этой гадости тоже придётся выбросить. Только вот Paint.NET жалко. А CCC нужен для настройки видюшки. Иначе дотнет давно отправился бы фтопку.
0
Выкинь CCC, поставь Ati Tray Tools.
0
ие тоже идет с системой, но он далеко не компонент. Срач переходит не в ту сторону. Хотя я сам и вендузятник, про мс я ничего не могу сказать.
0
ие тоже идет с системой, но он далеко не компонент.
Еще какой компонент. В винде на него так много повязано, что вытравить целиком нереально. Даже если убрать iexplore.exe (он, кстати, маленький, поскольку там только создание окошка и компонента webbrowser в нем) — сам движок IE никуда не денется.
0
как подсказывает «свойство->версия» да. Хотя не берусь утверждать, далек от программирование 3d

0
Вопорс был в «стандартно для чего?»
Стандартно для программы? — большенству программ эти библиотека совершенно не нужна.
Стандартная библиотека системы? — см. выше про .NET.
+1
Ты опять пропускаешь суть. Даже, если программе требуется дополнительный компонент (например, SmartSniff лучше работает с winpcap (хотя может и без)), всё равно программка вполне хорошенькая.
Также и OpenGL.
А какое-нибудь говно на qt тащит за собой мешок зависимости просто чтобы диаложик отрисовать (да ещё в какомнить глянцевом стиле).
0
про .net согласен.
про opengl нет, это компонент windows
0
посмотрел выше и стал несогласным
0
Это переходничок. Реальный опенгл ставится с дровами видеокарты.
0
Даже эта?
Или эта?
Или может эта?
Что-то я не заметил говна. Всё при себе, и всё только по делу.
Тянет, тянет. Оно лежит в %WINDIR%\System32. Называется kernel32.dll, user32.dll и еще куча аналогичных (это не считая того, что в свою очередь тянут эти DLL-ки). В сумме говна набегает на несколько дотнетов.
0
Тянет, тянет. Оно лежит в %WINDIR%\System32.
Дотнет это тоже тянет. Это стандартные вещи.
0
Во первых, далеко не все. Ему не нужна хрень вроде user32, shell32 и иже с ними — у него есть свои механизмы для этих задач.
Во вторых, дотнет просто теряется на фоне всего этого. Все перечисленные тобой программы тянут за собой винду, которая даже в версии Windows 98 весила около полугигабайта.
И в третьих, .net FX — стандартная вещь. Равно как и JRE.
Есть только одна программка, которая легкая и ничего с собой не тянет. Это memtest86+.
0
Она требует наличия БИОСа…
0
И то верно. Но биос — интегрированная часть железа, если так рассуждать — можно в требования записать еще десяток прошивок в разных контроллерах внутри компа.
0
еще какой-то десяток лет назад, БИОС можно было прошить только с 5.25" дисковода, поскольку прошивающая часть БИОСа ничего другого кроме него и ISA-видеокарты(если хочется увидеть коды ошибок) не признавала.
Сейчас же, та же БИОС может прошить себя хоть с винчестера, хоть с флешки.
А еще сами программы-прошивальщики весьма привередливы к БИОСу, как и многочисленные утилиты конфигурации CMOS-памяти т.к. настройки там хранящиеся целиком зависят от версии БИОСа, и только малая часть этих данных как-то документирована.
Так же я только краем застал времена когда надо было указывать конфигурацию винчестера чтобы БИОС принял его, что было до этого — трудно себе представить. Например ноут TOSHIBA T-1200 или как он там правильно пишется, хоть он и x86 совместимый, но многие программы не шли из-за нестандартного БИОСа. Это сейчас интерфейс БИОСа как-то устаканился, но не факт что даже сейчас все безоблачно и все же где-то имеются конфликты и какая-то программа(под чистым ДОСом) не идет из-за особенностей конкретного БИОСа.
Взять тот же UEFI, пришедший ему на смену…
0
И при чем тут все это?
+1
В этом я не сомневаюсь, и тут снова начинается тоже самое. Те же дот.неты в глубине используют тот же си а потом и вовсе асм. Но в силу того что, интерпретатор/компилятор/либа/еще_какой_кусок_говна имеет в себе ошибку из-за неграмотности (скорее всего), невнимательности, еще какого гемороя. Начинается разрастание этой ошибки по всем инстанциям. Так зачем плодить чужие ошибки, когда можно своих наделать.
Так в своем говне хотя бы копаться удобнее.
0
Но в силу того что, интерпретатор/компилятор/либа/еще_какой_кусок_говна имеет в себе ошибку из-за неграмотности (скорее всего), невнимательности, еще какого гемороя.
Тоже самое можно сказать о сложности, которая резко нарастает с увеличением громоздкости системы. И тоже хорошо аукается в конечном итоге.
Справедливости ради, скорее всего, в самой жабе ошибок весьма немного (хотя может просто хорошо прячут :) ). Но этого нельзя сказать о дополнительных библиотеках.
0
е же дот.неты в глубине используют тот же си а потом и вовсе асм. Но в силу того что, интерпретатор/компилятор/либа/еще_какой_кусок_говна имеет в себе ошибку из-за неграмотности (скорее всего), невнимательности, еще какого гемороя. Начинается разрастание этой ошибки по всем инстанциям.
Ровно такая же проблема существует с операционками и сторонними либами. Предлагаете перестать их использовать и «копаться в своем говне»?
+1
Под дотнетом лежат только общие библиотеки, вроде libc. А они обкатаны лучше, чем любой другой софт, так что ошибок в них на порядки меньше, чем в самописном велосипеде.
Сам дотнет тоже обкатан.
0
Но код написанный на чистом си, или даже асме будет в любом случае лучше
Даже если вспомнить милый агрегат therac-25, запрограммированный на ассемблере, которому сносило крышу просто от того, что опытный юзер успевал вбить все настройки процедуры менее чем за 8 секунд? Как бы там ни было, но на С# я таких шедевров пока не видел.
0
На ассемблере и Си такие случаи нужно выискивать, на C# — придётся выискивать хорошее.
0
На ассемблере нужно выискивать не такие случат. С сишечкой получше, но AV неспроста держит пальму первенства среди выдаваемых сишными прогами ошибок. А вот для дельфи типичны софтовые исключения типа «List index out of bounds» и иже с ними — ты сам это признавал. И в 50% случаев после такой ошибки можно спокойно работать дальше, и во всех них виноваты исключительно авторы программы.
Проги на С# тоже сбоят, но гораздо реже, и таких ошибок как AV не выдает практически никогда. Плюс вместо бессмысленного дампа дотнет выдает полезную отладочную информацию, из которой часто можно выявить причину ошибки даже не будучи программистом. Так что качественного софта на шарпе куда больше.
0
На компе так и не научились ничего переносить.
Игры научились. Оно и неудивительно — продаж на одной платформе уже недостаточно, чтобы окупить дорогущую игру, приходится делать сразу под все, на чем можно продать.
Да и среди опенсорса немало кроссплатформенного.
Учитывая, что в разных МК (кроме какойнить игрушечной ардуйни) совершенно разный набор периферии, с разными возможностями.
И что с того? Если это нормальный проект, а не «помигать диодиком», то периферийно-зависимая часть выносится в HAL размером 5-10% от проекта. Переписывать 10% или 100% — почувствуйте разницу.
0
Уважаемый. Ну продолжайте же в существующий топик. Зачем ещё и этот загаживать? :)
+2
Скажи это evsi. Почему-то ему упоминуть свои извраты в каждом топике не лень.
0
При всем уважении Вы не правы. Тем более, что отвечали на пост 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));
+1
выглядит аккуратней
Почему нельзя тогда просто написать функцию, которая инициализирует нужный кусочек. Зачем городить какие-то огороды из классов. 6 вызовов вместо одного.
0
Я еще раз говорю: вы не ничего не понимаете в том, о чем беретесь спорить. Там может не быть вызовов вообще, хотя внешне это выглядит как вызов.
+1
хотя внешне это выглядит как вызов
Зачем разводить какую-то магию? Выглядит как вызов, а не вызов. Выглядит как сложение, а фактически — вызов. Я считаю, это психическая болезнь — стремление сделать всё как можно более сложным и мутным.
+1
Зачем разводить какую-то магию?
Это не магия вовсе. Хотя, если учиться категорически не хочется, то магия, конечно.
Я считаю, это психическая болезнь — стремление сделать всё как можно более сложным и мутным.
Тогда я не понимаю, почему вы к этому так стремитесь.
+1
Хотя, если учиться категорически не хочется
Учиться вашему говну не хочется совершенно. Но к сожалению, иногда приходится.
-1
Учиться вашему говну не хочется совершенно.
Во-первых, оно не мое. Во-вторых, вы и свое-то не особо охотно изучаете.
Но к сожалению, иногда приходится.
Как-то это не заметно совсем.
0
Вы знаете как винда при прорисовке окна выводит пиксели фрейма? Какой бит куда устанавливает, какие блокировки использует, какой байт в какую область памяти пишет? Разве вам это требуется знать при создании программы?
Вы пишите свою собственную функцию с учетом всех нативных настроек системы (цвета, толщина, стиль...).
Или вы просто не уважаете пользователя, и говорите: «Ты мудак, и не понимаешь, что моя вырвиглазная палитра в приложение единственно доступное решение. А то что ты не можешь прочесть белый текст на ядовитом фоне — не моя проблема. А мое приложение работает зато очень быстро.»
0
Я не знаток C++ потому не могу Вам сказать все конкретные преимущества данного метода, но, из собственной практики, при работе над текущим проектом меня не раз посещали мысли что какой-то определенный кусок кода реализовать в виде классов с методами было бы гораздо удобней и писанины меньше. Но т.к. начал писать на СИ, то переделывать все в плюсы уже неохота. На них надо начинать писать с проектов попроще, чтоб мозг перестроить, т.к. там мыслить надо несколько иначе.
+1
Перечитай это:
На мой взгляд, это достоинство — код получается недвусмысленный, а это самый важное условие простоты. Можно сравнить пример C++ из «Темной сторона C++» (PDF, стр. 23 и далее). Если в C мы видим

baz = foo->bar(3);

то понимаем, что foo — указатель на структуру с полем bar, в котором указатель на функцию. Неясен только тип baz (он же тип значения bar).

А в C++ baz может быть reference, foo — классом с собственным оператором ->, bar — методом. Виртуальным, в большой иерархии классов. Или переопределенным на каком-то этапе. Перегруженным. Перегруженным с аргументами по умолчанию. Или вообще принимающим не int, а bool или enum, так что компилятор сообразит преобразовать типы. И неизвестно еще, что именно возвращает bar — может быть, нужно будет приводить тип к типу baz. И, кстати, может быть оператор = тоже переопределен. Как и оператор (). А может быть, при конверсии будет даже временный объект создан, с конструкторами и деструкторами. Может быть, тут шаблоны включаются — и не один. Кстати, текущее пространство имен неизвестно.

И автор оригинальной презентации находит еще есть какие-то варианты с typeof и алиасами, но тут уже я пас :)
Тебе это действительно надо, чтобы без бутылки нельзя было разобраться? Вот кольцевой буфер, простейшая структурка, обратиться 3-4 строчки. neiver умудрился нагородить классов на несколько экранов, и ещё ошибку сделать. Если тебе кажется, что простой способ не подходит, ищи более простой! Иначе ты не инженер.
0
Перечитай это:
Решили еще раз повторить глупость в расчете на то, что кто-то в нее поверит?
0
Вы же свои глупости повторяете постоянно и в них, к сожалению, начинают верить.
-1
Вы же свои глупости повторяете
То, что я говорю, глупости только с вашей точки зрения. Да и повторяю я только вам, остальные, по большей части, уже давно это поняли и без меня.
и в них, к сожалению, начинают верить.
Ну не все же живут в выдуманном вами мире, а те, кто имеет дело с реальностью давно пришли к тем же выводам, что и я.
0
Ну не все же живут в выдуманном вами мире, а те, кто имеет дело с реальностью давно пришли к тем же выводам, что и я.
Это тебе кажестся. Я уже давно понял, что 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, только более надежная и удобная.

> нормального человека
Значит то, что я видимо ненормальный — очень кстати :)
-1
Это тебе кажестся.
Да нет, вобщем. Вы это убедительно доказали и не раз.

P.S. надергать из интернета фраз на любой вкус можно сколько угодно.
P.P.S. я могу покритиковать С++ (и не раз это делал) куда как убедительнее, чем в приведенной вами цитате (тем более, что аргументация там свидетельствует о плохом знании критикуемого предмета), но другого сравнимого по мощности и распространенности инструмента для низкоуровневого программирования просто нет.
+1
я могу покритиковать С++ (и не раз это делал) куда как убедительнее, чем в приведенной вами цитате
Не думаю. Хотя бы потому, что слова Линуса для меня куда ценнее.
0
Не думаю.
А стоило бы. К тому же, как я уже писал, С++ я критиковал и не раз, в том числе и тут, в сообществе.
Хотя бы потому, что слова Линуса для меня куда ценнее.
Кто бы сомневался. Ведь они соответствуют вашим представлениям. Хотя и расходятся с реальностью. Наезжать на ++ из-за производительности, как это делает он, несусветная чушь, поскольку в самом языке нет ничего, что бы к этому приводило. К слову, ядро линукса таки написано во многих местах в ООП-стиле, разве что закат солнца делается вручную.
0
Кто бы сомневался. Ведь они соответствуют вашим представлениям.
Дело не в словах, а в человеке. Он вообще няшка.
И нотч тоже, хоть и выбрал яву.
в ООП-стиле
В ООП-стиле — это сраться о том, обращаться к локальным полям с «this->» или нет. Брюс Эккель считает, что не надо, поскольку нечего делать работу за компилятор. Другие с тем же вдохновением доказывают, что надо. И это самый простейший пример. Искренне захочешь разобраться и научиться — не сможешь, поскольку вы там сами не можете решить как правильно. А если пойти дальше, куда больше вылезет всего.
Отделить некоторый кусочек и снабдить его интерфейсом — это не ооп стиль, а обычное сишное дело.
0
Дело не в словах, а в человеке.
Ни один человек не может быть прав всегда и во всем.
Искренне захочешь разобраться и научиться — не сможешь,
Вы даже не пытаетесь.
поскольку вы там сами не можете решить как правильно.
«Вы сами» это кто?
Отделить некоторый кусочек и снабдить его интерфейсом — это не ооп стиль, а обычное сишное дело.
От того, что вы его категорически не хотите так называть, он им быть не перестанет.
+2
«Вы сами» это кто?
Например, те, кто каждый год перекраивают интерфейсы, потому что теперь в моде «аннотации» или ещё какая-нить хрень.
0
Например, те, кто каждый год перекраивают интерфейсы, потому что теперь в моде «аннотации» или ещё какая-нить хрень.
Вы продолжаете говорить о том, в чем не разбираетесь.
+1
Вы продолжаете говорить о том, в чем не разбираетесь.
Я практик и говорю о том, что вижу. Если в популярном продукте, который пишут далеко не студенты и не новички перекроили интерфейсы, что принесло всем головной боли, и что в явовской библиотеки половина интерфейсов уже «deprecated», так и говорю. Вижу, что 95% софта, начиная от Паинта, заканчивая Матлабом становятся уродливей, тяжелей и кривей, а полезных функций добавляется два грамма, так и говорю.
А не вычитал несколько определений в книжке, и объясняю всем, кто смотрит чуть на мир чуть шире, что они ничего не понимают.
0
Я практик и говорю о том, что вижу.
Судя по тому, что вы пишете — вы теоретик, причем слабо подготовленный.
что в явовской библиотеки половина интерфейсов уже «deprecated»
Я же говорю — вы теоретик, причем слабо подготовленный. До половины там еще ой как далеко, хотя с момента появления жабы прошло уже почти 20 лет, а за это время и сама жаба, и системы, на которых она работает, изменились и сильно.
+2
Ну, это не только я говорю. А любителям новомодных технологий веры нет, учитывая какое всё хреновое стало.
0
Ну, это не только я говорю.
Да, я понимаю, что вы просто повторяете с чужих слов, совершенно не понимая сути.
А любителям новомодных технологий веры нет, учитывая какое всё хреновое стало.
Ну хреново-то стало только вам и кучке других неспособных учиться.
0
Ну хреново-то стало только вам и кучке других неспособных учиться.
Если отбросить хомячков, которым всё применение компа ограничивается фильмосвалкой (одной кучей, даже без структуры) и запуском пары сайтов в браузере, то это не такая уж и кучка.
-1
Если отбросить хомячков, которым всё применение компа ограничивается фильмосвалкой (одной кучей, даже без структуры) и запуском пары сайтов в браузере, то это не такая уж и кучка.
В вашем фильтре не хватает «способных учиться». С ним получается кучка.
0
В вашем фильтре не хватает «способных учиться».
Я считаю, что учиться — это в первую очередь думать, а не тупо зубрить определения, как в школе заставляют. Такие «умеющие учиться» спокойно хавают всё, что скормят. А потом объясняют тем, кто думать умеют, что они ничего не понимают. Потому не могут даже представить, что кто-то мог прочитать те же определения, подумать, сопоставить с известными фактами и своим опытом и не согласиться.
0
Я считаю, что учиться — это в первую очередь думать
Но сами этого не делаете.
Потому не могут даже представить, что кто-то мог прочитать те же определения, подумать, сопоставить с известными фактами и своим опытом и не согласиться.
Легко. Достаточно не пропускать пункта «думать» и разобраться в предмете критики. Два эти пункта вам никак не даются.
+2
тем, кто думать умеют
Вы путаете «умеют думать» и «умеют выдумывать», в результате своими выдумками заменяете знания и факты, а из них делаете выводы.
+2
Вы путаете «умеют думать» и «умеют выдумывать», в результате своими выдумками заменяете знания и факты, а из них делаете выводы.
По-моему, всё наоборот. В средние века быдло верило в ведьм (и жгло их на кострах). А научные знания считались выдумкой. Ничего с тех времён не изменилось. Желание сделать проще, надёжней, аккуратней — ересь и выдумка. Глючное, кривое и дерьмовое — стандарт.
0
По-моему, всё наоборот.
Кто бы сомневался. Я ж говорю — вы живете в выдуманном вами мире.
В средние века быдло верило в ведьм (и жгло их на кострах). А научные знания считались выдумкой. Ничего с тех времён не изменилось.
С тех пор знания и вера поменялись местами. Вот только вы этого не заметили и продолжаете знания заменять верой.
Желание сделать проще, надёжней, аккуратней — ересь и выдумка.
Вы пока продемонстрировали желание пообливать грязью не вдаваясь в подробности. Желанич сделать проще, надежней и аккуратней не заметно.
0
С тех пор знания и вера поменялись местами.
Ничего не поменялось. Также единичные люди иногда создают хорошие вещи, а остальные — стремятся всё запоганить (продолжая пользоваться этими вещами).
вы живете в выдуманном вами мире
Я не представляю насколько нужно уйти в свой виртуальный мир и потерять связь с реальностью, чтобы считать ваше «развитие» хорошим. Одноразовые розетки, одноразовый софт. Только дерьмовую розетку сколько не лакируй, контакты из фольги всё равно видно. Софт — предполагается, что это что-то сложное и можно рассказывать басни, оправдывая тормоза, глюки, бестолковость и постоянное скачивание обновлений через интернет.
Вы пока продемонстрировали желание пообливать грязью не вдаваясь в подробности.
Угу. У меня вообще нет достаточных слов ненависти, чтобы это описать в подробностях. Браузер запускается пол часа — всех устраивает. Разумный человек бы вышвырнул эту поделку и не стал бы ей пользоваться. Но нет, продолжают верить, что обновление — это улучшение. Ничего не изменилось со средневековья.
0
Также единичные люди иногда создают хорошие вещи, а остальные — стремятся всё запоганить (продолжая пользоваться этими вещами).
Не обольщайтесь, тех, кто, как и вы, стремится все запоганить продолжая этим пользоваться, меньшинство. К счастью.

P.S. надоело. как сделаете что-нибудь сами и разберетесь в предмете обсуждения, можно будет продолжить. если, конечно, к тому времени, вы будете отстаивать свою точку зрения и продолжать предлагать подходы полувековой давности, которые тысячи раз доказали свою нежизнеспособность.
0
Не обольщайтесь, тех, кто, как и вы, стремится все запоганить продолжая этим пользоваться, меньшинство.
Я бесполезными поделками на всяких явах и оопах почти не пользуюсь. Вы сами пользуетесь операционными системами и множеством других вещей, написанных на Си.

как сделаете что-нибудь сами и разберетесь в предмете обсуждения, можно будет продолжить.
Не хочу ничего делать на явах и оопах, и может даже кого-нить отговорить смогу, тогда на одно глючное дерьмо будет меньше.
0
ООП или С++ — новомодная технология? я чё-то не понял.
0
И что? дело не в системах, а в поставленной задаче. Имхо стоит довольствоваться рациональным минимумом инструментов дабы получить простое работающее решение. Если надо обработать строку, можно это сделать и в жабе, бесспорно, но лучше взять инструмент специально разработанный для этого (perl). Если надо написать алгоритм мигания диодом, можно это написать на яве, но зачем, можно воспользоваться си. Другой вопрос что некоторые не хотят пользоваться именно оптимальными инструментами для решения задачи, в силу незнания оных. Так и получается, используем яву для мигания светодиодом.
0
Если надо обработать строку, можно это сделать и в жабе, бесспорно, но лучше взять инструмент специально разработанный для этого (perl).
Будет ли это быстрее вопрос отдельный. Но если задача не ограничивается «обработать строку», то перл вполне может оказаться не самым лучшим инструментом. Впрочем это тоже отдельная тема. Гораздо существеннее два других пункта — знание инструмента на момент выбора и сопровождаемость полученной софтины.
Другой вопрос что некоторые не хотят пользоваться именно оптимальными инструментами для решения задачи, в силу незнания оных.
Оптимальный инструмент выбирается из тех, которые разработчик знает и готов сопровождать. Декларации авторов инструмента о том, для каких целей он создавался играют куда меньшую роль.

P.S. пример с перлом явно неудачный, как на мой вкус. из моих знакомых любителей перла они все в один голос признают, что типичный перловый скрипт — write only.
+3
типичный перловый скрипт — write only
Только для тех, кто знаком с Перлом по примерам из лурки.
-1
Только для тех, кто знаком с Перлом по примерам из лурки.
Вы уж извините, но в этом вопросе я больше полагаюсь на мнение людей, для которых софт писанный на перле составляет изрядную долю их куска хлеба.
0
в этом вопросе я больше полагаюсь на мнение людей, для которых софт писанный на перле составляет изрядную долю их куска хлеба
Например, авторов хороших книжек по перлу? Или качество кода, написанного любым быдлокодером теперь расскажет всё о языке?
0
Твое незнание оптимального инструмента оказывается моей проблемой. Зачем мне лишняя проблема? Так и получается что Гейтс орал что всем на 20 лет хватит 640к. И так бы и вышло писали бы люди грамотно, а не плодили костыли, для закрытия других костылей. Самый главный вопрос, где ваша жаба в авр-ках? Если на ней можно сделать то же что и на сях
0
Твое незнание оптимального инструмента оказывается моей проблемой.
Отвечу вашими же словами:
Имхо стоит довольствоваться рациональным минимумом инструментов дабы получить простое работающее решение.
Перл в рациональный минимум не входит. К тому же насчет «незнания» вы погорячились. На перле я действительно не пишу, но это вовсе не значит, что мой инструментарий ограничен жабой.
Если на ней можно сделать то же что и на сях
Что-то можно, что-то нельзя.
+1
Перл в рациональный минимум не входит.
Ну это как сказать. Бывают случаи, когда выигрывает именно он. Правда, довольно специфичные.
0
Самый главный вопрос, где ваша жаба в авр-ках?
А где ядро linux для авр-ки, оно ведь на С?
+2
Ну так где-то с пол года назад был пост о запуске линукса на атмеге. Там правда была виртуальная машина арма написана, но это же мелочи :)
0
мм? dmitry.gr/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit
Конечно методом налаживания костылей друг на друга. Но в тоже время linux on avr
0
Вот ещё www.harbaum.org/till/nanovm/. Что удивляться, компьютер — он и есть компьютер, даже если это межка или даже какой-нить малюсенький PIC.
0
признаю был не прав
0
признаю был не прав
Не так уж и не прав. Как и линух на AVR, это имеет только теоретическую ценность. На практике ничего принципиально не меняя.
0
И так бы и вышло писали бы люди грамотно, а не плодили костыли, для закрытия других костылей. Самый главный вопрос,...
Почему вы не пишите грамотно? Вам же ни кто не запрещает это делать.
+2
Твое незнание оптимального инструмента оказывается моей проблемой. Зачем мне лишняя проблема?
Неправильный выбор — это не только ява.
Выбор оверкилла обычно приводит к тому, что ты получаешь жручий и раздутый, но работоспособный инструмент.
Выбор недокилла приводит к тому, что ты получаешь компактный, быстрый, но постоянно глючащий инструмент.
Выбирай.
0
но постоянно глючащий инструмент
Так считают те, кто не справился с Си, и убежал, потому что не осилил.
0
Если вы не умеете пользоваться чем-то это не вина пользователя. Мне не хочется раз в сутки рестартить ваше приложение потому что оно отожрало больше чем у меня есть.
0
Мне не хочется раз в сутки рестартить ваше приложение потому что оно отожрало больше чем у меня есть.
А мне не хочется каждые пять минут запускать заново ваше приложение, потому что оно опять выдало access violation и убилось. Хорошо если не убило при этом результаты моей работы с ним.
+1
А мне не хочется каждые пять минут запускать заново ваше приложение, потому что оно опять выдало access violation и убилось.
Не пользуйся дерьмовыми программками. Впрочем, с «современными» ЯВУ скоро иных не останется…
0
Примерно так я и поступаю, когда альтернативы есть. К сожалению, С++ столь же подвержен проблеме AV, а подавляющее большинство софта на нем да на С, так что с альтернативами туго.
0
Собственно, программ, которые жырные, но работают в результате выбора у меня куда больше, чем тех, которые легкие, но не работают.
0
Если надо обработать строку, можно это сделать и в жабе, бесспорно, но лучше взять инструмент специально разработанный для этого (perl).
Сишная строковая библиотека позволяет решать многие задачи по обработке текста куда проще и оптимальней, чем перл. И уж конечно куда оптимальней, чем средства других языков.
Регулярки при желании не трудно добавить, использовав соответствующую библиотечку.
0
Сишная строковая библиотека позволяет решать многие задачи по обработке текста куда проще и оптимальней, чем перл.
Сказочник.
+1
Сказочник.
Угу. Отрицает то, что всем нормальным людям известно, и не подвергается сомнению, потому что любая иная точка зрения — автоматически ересь.

Тем временем, работа с текстом — вообще такая область, где ООП даёт на порядок более раздутые и кривые решения.
0
угу. ваши познания в любимой сишечке мы уже поняли в «целостности и однородности, отсутствии запутанности.». угу.
что еще интересного расскажете?
0
эээ. строковая замена? да, с применением strstr, memcpy, malloc действительно решает проще чем перл с его s/// :)
А ещё в Си очень хорошо реализовано формирование набора строк из строки с разделителем >1 символа. С этим прекрасным циклом и указателями в простоте не сравниться ни какая оопешная array = string.slice(separator)
+1
Много чего. В сишной библиотеке кроме strstr есть много менее известных функций. А если уметь их применять не только по стандартным шаблонам, можно сделать многое. TCHAR помогает сделать полностью переносимо между системами с поддержкой юникода или без. А сама работа со строкой просто как с кусочком памяти позволяет вообще всё. Причём максимально быстро и просто.
0
Причём максимально быстро и просто.
Куски памяти с завершающим нулем. Это максимально быстро? Эффективно? Простот? Нихрена ты в эффективности не смыслиш.
+2
Куски памяти с завершающим нулем. Это максимально быстро? Эффективно? Простот?
Угу. Ну юзайте свои сраные классы. Дураков учить — что мёртвых лечить.
-1
а ничего, что есть еще строки с явно указанной длинной? или сишечка — наше фссьо?
+1
TCHAR помогает сделать полностью переносимо между системами с поддержкой юникода или без.
Сказки, увы. Просто охренеть сколько проблем вылазит из-за какой-то там локали.
0
Так и получается, используем яву для мигания светодиодом.
Обратная ситуация не реже. И ничуть не лучше по последствиям.
0
Обратная ситуация не реже.
Сомневаюсь. Транжирить ресурсы просто потому что «нужно экономить время разработчика», даже, если сделать значительно оптимальней нетрудно — Главное Правило «современной» «разработки».
0
Оптимизировать все и вся и выдавать на гора программу, которая глючит чаще чем работает (да и не умеет при том почти ничего) — главное правило ассемблерных маньяков.
0
Оптимизировать все и вся и выдавать на гора программу, которая глючит чаще чем работает
Например, такую? Ты наверно ошибся, а имел в виду «которая глючит чаще чем работает если бы её писал любитель „современных“ ЯВУ».
-1
Редкое, но приятное исключение.
Ты наверно ошибся, а имел в виду «которая глючит чаще чем работает если бы её писал любитель „современных“ ЯВУ».
Я имел в виду именно то, что сказал.
0
К тому-же в последних ядрах можно писать модули на C++. Прекращайте срач. Все зависит не от языка, а от того, кто на нем пишет. Многим просто не под силу из-за слабоумия или лени освоить ООП, поэтому для них С++ — олицетворение зла.
+2
Многим просто не под силу из-за слабоумия или лени освоить ООП, поэтому для них С++ — олицетворение зла.
Например, для Линуса Торвальдса и Фабриса Беллара?
0
Линуса Торвальдса и Фабриса Беллара
А кто это?
+2
хехе, это люди, до которых тебе далеко очень ;)
0
хехе, это люди, до которых тебе далеко очень ;)
Я прекрасно знаю кто это. Просто нужно было остановить срач в самом начале :) Лучший способ — задать идиотский вопрос.
0
в смысле сразу сказать «я идиот»? :)))))
*нормальный* ООП вполне себе реализуется на обычном Си.
0
Еще один умник нашелся.
+1
чувствуется безбрежный интеллект! раз от языка ничего не зависит, то предлагаю тебе писать все на foxpro или дельфи :))
0
или дельфи :))
С удовольствием. Жаль только, что спектр поддерживаемых имеющимся компилятором платформ невелик.
+1
*нормальный* ООП вполне себе реализуется на обычном Си.
Не путайте «реализуется» с «удобно пользоваться». Не говоря уже о том, что «нормальный ООП» существует далеко не один и далеко не все из этих вариантов удобно использовать когда все кишки торчат наружу.
0
Я буду продолжением срача. Ооп оправдан, если он там нужен, скажем кнопочки, окошки и вообще обьекты описывать без ооп сложно и в общем-то бессмысленно. Но зачем на мигание диодиком вешать ооп?
+1
Ооп оправдан, если он там нужен, скажем кнопочки, окошки и вообще обьекты описывать без ооп сложно и в общем-то бессмысленно.
GTK считает иначе (и считает правильно).
-1
Ты то сам понял что сказал? А что по твоему в Gtk делает GObject
+1
Ты то сам понял что сказал?
А ты сам-то понял что сказал?
-1
А на вторую часть вопроса ответить слабо?
0
Код процедурный? Процедурный. А то, что любую структурку, с которой работают пара функций сейчас принято обзывать ругательным словом «ООП», мне известно.
-1
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
Хватит притягивать за уши то, чего нет. И прятать слона.
+3
Да, печально. Я считал, что там нормальный Си.
0
GUI куда лучше ложится на объектную идеологию, чем на процедурную.
Поэтому даже оконная система Win32 API является объектно-ориентированной, хотя и имеющей совместимый со структурным программированием интерфейс.
0
GTK считает иначе (и считает правильно).
Что-то 90% тех, кто его щупал, плюется ядом на его архитектуру и API.
К тому же, GTK — единственный фреймворк, который я не смог собрать из исходников (под винду, в GCC). Qt, wxWidgets и прочие собирались с полпинка.
+1
Уважаемый Lifelover , а вам не надоело воевать с ветряными мельницами? Вы сами себе придумали уютный мирок (с Сшекчтой и AVRочкой) и просто поливаете говном все, что выходит за рамки Вашей уютной идеологии.

Я не имею ничего против С и AVR – но это всего лишь инструменты. Это хорошие инструменты для своих задач, но это не единственные существующие инструменты. Есть множество других инструментов, которые позволяют решать определенные задачи более продуктивно.

А Вы заладили, как старый дед, «А вот раньше… А вот раньше…». При этом абсолютно без аргументации. От прямых вопросов Вы уходите, а в качестве аргументов приводите сриншоты интерфейсов, картинки с иконками и найденные на просторах Интернета цитаты уважаемых и не очень людей.

Оглянитесь вокруг. Если, по-вашему, ООП так ужасен — то почему данная концепция получила такое широкое распространение? Неужели все настолько глупы, и лишь только Вы «знаете правду»?
+1
А Вы заладили, как старый дед
Ваша ненависть к простоте — это даже не «старый дед», а средневековье.
-1
Не к простоте, а к примитивности. Простоту мы как раз любим.
+2
Незаметно.
0
Ваша ненависть к простоте

У меня нет ненависти к простоте, наоборот, я восхищаюсь простыми и лаконичными решениями. Но не все задачи имеют простое решение. Даже если абстрагироваться от программирования. Вот Вы, например, знаете простое доказательство теоремы Ферма? Ведь формулировка теоремы – проста и лаконична, а доказательство требует совершенно другого мат. аппарата.

Как правильно заметил Vga – Вы путаете простоту и примитивность. Перфокарты – предельно простой способ хранения информации. Только, почему-то, сейчас перфокартами никто не пользуется, несмотря на всю его простоту.
+1
Но не все задачи имеют простое решение.
Значит есть ещё более простое решение.
Перфокарты – предельно простой способ хранения информации.
Примитивный. Магнитные накопители тоже простые. Пока система состоит из простых частей, она простая. Неважно сколько частей.
0
Разве что в общем описании. На деле это совершенно ужасающий агрегат. Там даже вместо головок уже микросхема с электромагнитом, магниторезистором, термодатчиком, МЭМС-актуатором и хрен знает чем еще, а читаемый сигнал так слабо похож на биты, что обрабатывается специальным математическим аппаратом, причем ЕМНИП — вероятностным.
0
Значит есть ещё более простое решение.

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

Вот Вы, где-то в комментариях, поливали говном применение нейросетей. На самом деле данный класс алгоритмов действительно не является самым простым и производительным. Более того, в таких алгоритмах (нейросети, генетический алгоритм) присутствует фактор чистой случайности, чистый «random». И решения получаются суб-оптимальными.

Но, ели вы знаете боле простое решение, поведайте миру – и мировая известность Вам гарантированна.
+1
Вот Вы, где-то в комментариях, поливали говном применение нейросетей.
Не припомню. Я вообще алгоритмы уважаю, в отличие от новомодных «методов» программирования, где основная идея — страх и ненависть перед простотой.
-1
Не припомню.

Не вопрос, могу Вам напомнить Ваши слова:

А каждая программа на сраной яве тащит за собой кучу нативных бинарников, начиная от SQLite, заканчивая всякими нейронными сетями, потому что своего нифига нету кроме раздутых менеджеров

И да, SQLite Вы тоже зря обижаете.
0
Не вопрос, могу Вам напомнить Ваши слова
Ты не так понял, я SQLite наоборот люблю. Более того, ява подобной маленькой библиотечки не имеет (имея всякие раздутые паттерны), поэтому её приходится тащить в виде бинарника за каждой софтиной, которой нужна маленькая БД.
0
Более того, ява подобной маленькой библиотечки не имеет
Имеет. Размер бинарника H2 около полутора метров. При этом функционально это полноценный SQL сервер, в отличие от огрызка SQLite.
0
SQLite — полметра, и не требует сервера. Не всем нравится пихать ARM в выключатели.
0
SQLite — полметра, и не требует сервера
H2 тоже не требует сервера, поскольку является полноценным сервером сам по себе. И, напомню, это полнофункциональный SQL сервер, поддерживающий стандарт языка и прочие вещи, о которых SQLite даже не мечтает.
+1
Не столь маленькая, сколь локальная. В этом плане альтернатив у SQLite особо нет, да и врядли стоит разрабатывать еще один СУБД-движок, когда уже есть готовый.
0
Ты не так понял, я SQLite наоборот люблю

Извиняюсь, если я неправильно Вас понял, просто в Вашем потоке негатива тяжело понять – что Вы любите а что нет. Вот как интерпретировать Вашу фразу «заканчивая всякими нейронными сетями»?

А что Вас смущает в использовании SQLite из других ЯП? SQLite – удачный проект, и он получил широкое распространение. Или Вы считаете, что ели SQLite написан на С, то и использовать его имеют право только те программы, которые написаны на С? Использование ORACLE со средой .NET Вас не смущает?
0
Вот как интерпретировать Вашу фразу «заканчивая всякими нейронными сетями»?
Также.

А что Вас смущает в использовании SQLite из других ЯП?
Удачный, разумеется. А используют, потому что сами на своих труъ-языках подобного не имеют.
0
А используют, потому что сами на своих труъ-языках подобного не имеют.
Нет. Используют потому, что незачем изобретать велосипед. Так же, как никто не пишет себе собственное ядро, а берут готовый линукс. Точно таким же образом берут и другие готовые компоненты, написанные на любых языках, включая яву.
+1
На яве хорошего написано крайне мало, и брать особо нечего.
Типичная явапрога.
0
А также типичная сипрога (минус гламурная раскраска, в остальном все то же самое), дельфипрога (сам такое писал), сиплюсплюспрога (и такое тоже), чтоугодно прога. Типичный your app, от языка программирования не зависит. Только от способностей дизайнера интерфейса (что-то мне подсказывает, что тут им тут и не пахнет).

Ява обычно крутится где-то в энтерпрайзах и серверах, так что 90% софта на ней 99% людей и в глаза не видели. Из оставшихся 10% девять — это софт для J2ME и Android. Оставшийся процент заглядывает на ПК. Среди него есть хорошие вещи — эклипс, например.
+1
Среди него есть хорошие вещи — эклипс, например.
Тормозной ужос. Вот нетбинс — поняшней, хотя наверно не такой навороченный, но это и хорошо. А то со своими сраными рефакторингами городят ужос вроде SPL с километровыми названиями.
0
У меня работает четко. Алсо, нетбинс разве не на яве?
А то со своими сраными рефакторингами городят ужос вроде SPL с километровыми названиями.
SPL сама по рефакторингу плачет. И километровые названия — отчасти издержки С, отчасти странности ST-шных кодеров.
0
Алсо, нетбинс разве не на яве?
Именно на ней.
0
SPL сама по рефакторингу плачет.
Не нужны рефакторинги. Их вообще нельзя давать в руки любителям «красивого» кода. А то потом как раз таки не прочитаешь — не поправишь.
-1
Алсо, нетбинс разве не на яве?
Ясное дело, но на удивление опрятный и быстрый (для явы, разумеется).
0
Я то Вас не устраивает в данной программе? Дизайн? Сочетание цветов?

Это стандартная конфигурилка для MultiWii, она написана сообществом моделистов для моделистов. JAVA позволяет запускать ее на любой платформе. Если она Вам не нравится – напишите свою, протокол обмена открыт…
+1
Мне и мультиви не нравится. Вот это — квадрокоптер. А мультивии — ардуйня с моторчиками, которая кое как держится в воздухе, если ветерок не дунет.

Я то Вас не устраивает в данной программе? Дизайн? Сочетание цветов?
То, она ещё хуже, чем текстовый конфиг.
0
Вот это — квадрокоптер.
Ты, конечно, выбрал коптер для сравнения. Только один вопрос — какой цены и мощности там железо? И стоит ли сравнивать это с любительским проектом, которые ориентируется на получение сносных характеристик на предельно дешевом железе?
+1
Только один вопрос — какой цены и мощности там железо?
Там в первую очередь серьёзный, профессиональный софт. А не какой-то заумный фильтр на все случаи жизни и простенькая обратная связь.
0
Серьезный, профессиональный софт — во многом еще более заумный фильтр. К тому же, хрен он что сделает без соответствующей системы датчиков, да и скорее всего требует немалую производительность. Даже его авторы не построят аналогичное на железе мультиви. Хотя скорее всего смогут реализовать лучше, чем сейчас есть.
Алсо как раз в мультиви AFAIK все довольно простенько. Что посложнее не позволяют примененные датчики, производительность процессора и познания авторов.
0
Мне и мультиви не нравится

Ок, не нравится – не покупаете, на стройте свой коптер на основе MultiWii. В чем проблема?

Вы опять уходите от прямых вопросов. И, зачем-то приводите скриншоты каких-то программ. Глупо оценить программы исходя из вершено вида.

То, она ещё хуже, чем текстовый конфиг.

Дык, опять же, никто Вас не заставляет пользоваться данной программой, можно конфигурацию записывать прямо в EEPROМ, набрав данные в HEX редакторе…

Мультиви – отрытый проект, который держится на энтузиастах. Вы, абсолютно бесплатно, получаете последнюю прошивку, программу для конфигурирования … И, вместо того, чтобы сказать спасибо разработчикам данной платформы — Вы опять поливаете все говном…
+1
Вы, абсолютно бесплатно, получаете последнюю прошивку, программу для конфигурирования
Качество соответствует.
0
Глупо оценить программы исходя из вершено вида.
Эту, как раз, можно. Она вся из интерфейса и состоит.
Мультиви – отрытый проект, который держится на энтузиастах. Вы, абсолютно бесплатно, получаете последнюю прошивку, программу для конфигурирования …
Ну, бесплатность все же не индульгенция от критики. Хотя эффективней было бы переделать как надо и заслать авторам — на то он и опенсорс.
0
Хотя эффективней было бы переделать как надо и заслать авторам — на то он и опенсорс.
Есть альтернативная программка. Немножко менее страшная.
0
Может переключитесь на ардуйню? Она больше по тематике сообщества. И её вы, очевидно, так же ненавидите. И средства для неё так же тормозные.
0
А используют, потому что сами на своих труъ-языках подобного не имеют.

Имеют, есть множество «встраиваемых» БД. Просто инженеры выбирают инструменты исходя из потребностей, а не из фанатической преданности тем или иным технологиям. SQLite — действительно (ИМХО) удачный проект. Почему бы не использовать это, готовое решение, если оно действительно подходит под определенную задачу. А вот если инженер выбирает БД исключительно из принципа «ели я пишу на python, значит и БД должна быть написана на python» — это уже фанатизм.
+1
Тем не менее, выбирают и SQLite и fann и множество других библиотечек, написанных именно на Си. Понты-понтами, но в каком-то подсознании рациональное стремление к простоте осталось.
-1
вот только си до сих пор используют :)
0
Но область его применения постоянно сужается.
0
это все сказки. как писали на нем большую часть системного ПО, так и продолжают. вот буквально недавно ондроед вылез и как давай сужать область применения си…
0
это все сказки
Да, в вашем исполнении.
как писали на нем большую часть системного ПО, так и продолжают
Вот только системное ПО занимает все меньшую и меньшую долю в общем объеме софта. Да и там медленно но верно ему наступает на пятки С++.
+1
это смотря что считать софтом… говноподелки на apple store, которые никто даже бесплатно не берет? :) или тонны софта на си, которые сейчас в любом телевизоре/телефоне?
0
или тонны софта на си, которые сейчас в любом телевизоре/телефоне?
legacy код — не такой уж показатель. Лучше посмотреть на настоящее. Линуса и Фабриса я приводил много раз. Есть и другие примеры — Wireshark, например. На Си очень много хороших программок и мало плохих. На яве — наоборот.
0
где же оно legacy? ядро живее всех живых, всякие плееры тоже дальше пишутся. gnu tools, gcc проч развиваются.
0
ядро живее всех живых
Потому что оно уже на Си, и так просто это не изменишь. Куда интереснее то, что сейчас создаётся на Си с нуля.
0
потому что си там более чем достаточно.
0
потому что си там более чем достаточно
Я-то согласен, к сожалению, не все так думают. Но если человек пишет программу с нуля на Си, он выбрал Си добровольно, и такие случаи радуют.
0
тонны софта на си, которые сейчас в любом телевизоре/телефоне?
Скорее граммы, а не тонны. Тонны это всевозможный in house софт, который вы даже не упомянули. Его на С, кстати, толком никогда и не писали.

P.S. каждый год пишут примерно 5 миллионов строк нового кода на Коболе. это язык который давно перестал занимать лидирующие позиции в in house программировании и еще лет 20 назад считался устаревшим. можете сравнить это со своим проектом, размером которого вы регулярно хвастаетесь.
0
я хвастаюсь тем, что сам делаю и могу проверить. а не ссылаюсь на кобол… где, кстати, написано про 5млн строк?
0
я хвастаюсь тем, что сам делаю и могу проверить.
Я просто не вижу смысла ссылаться на жабу, которая последние лет 10 давно и прочно заняла нишу, которую раньше занимал кобол.
где, кстати, написано про 5млн строк?
Вот тут, например.
0
Ты еще скажи, что не сужает. Учитывая, что он только использует уже готовое на С, а свое добавляет вообще на жабе.
Ну и сам линукс на сях написан в первую очередь из-за идеологии Торвальдса.
0
ага-ага, и все остальные покорно тащятся за ним, вместо того чтобы переписать на богоугодном с++ :) все тысячи разработчиков. и не только линуксы :)
масса новых проектов начинается на си.
я в своем проекте на почти млн строк не вижу зачем могут пригодиться мерзости c++.
0
Во первых, С++ не так уж богоугоден. Во вторых, переписать на нем около 13 мегастрок кода? Это малореальная задача.
0
в ядре каждый год переписывают огромное кол-во кода, если ты не в курсе. если бы в ооп были такие большие преимущества — давно переписали бы.
0
Ну религиозные страхи никто не отменял.
0
менять инструмент — для того чтобы поменять инструмент? для начала следовало бы рассказать о том какие бенефиты из этого следуют. сколько раз обсуждали уже на lkml — никаких.
0
Одно дело — переписывать кусочки, причем каждый переписывает свой, и совсем другое — перетаскивать весь проект на другой язык. Второе — реально, только если все этим целенаправленно займутся. Но для этого требуется очень, очень веская причина, которой нет. Так что иного выбора, кроме как тащиться за выбором Линуса уже нет.
0
отлично! то есть причины нет, но это не причина! LOL
0
Я тебя не понимаю.
Да, причины достаточно веской, чтобы оправдать переписывание огромного количества кода нет. Но я вообще знаю только одну причину достаточной вескости для такого мероприятия — когда на старом инструменте дальше развивать уже невозможно. К линуксу это не относится, по крайней мере пока.
0
это называется «инструмента более чем достаточно». причем сложность проекта (и с точки зрения задач и организации) недостижима для 99.9% проектов… и ничего, живет и процветает.
0
Вы сильно переоцениваете сложность ядер операционок.
0
это вы их сильно неооцениваете… одна поддержка SMP способна мозг вынести надолго.
не стоит линукс равнять с каким-нибудь freertos.
0
это вы их сильно неооцениваете… одна поддержка SMP способна мозг вынести надолго.
Вам — возможно. Я просто в этом деле ковырялся достаточно, что бы мне эти части не выносили мозг совершенно.
0
достойно… расскажи как нынче локинг в dcache работает? покажешь свой код в ядре? :)
+2
покажешь свой код в ядре? :)
«Разбирался» вовсе не значит, что я должен был что-то патчить в линуксовом ядре.
0
ну расскажи зачем нужно rcu в dcache :)
0
ну расскажи зачем нужно rcu в dcache :)
Вернуть на место ваш вынесенный мозг? Нет уж, сами разбирайтесь.
0
почему-то я так и думал, что по существу ты не ответишь ;) не переживай, c dcache и rcu я более-менее знаком.
0
почему-то я так и думал, что по существу ты не ответишь ;)
Почему-то я так и думал, что на замечание об переоценке сложности операционки начнутся попытки проверять мои знания в этом вопросе :)
не переживай, c dcache и rcu я более-менее знаком.
Да мне и не с чего переживать за ваши знания.
0
коих пока обнаружено очень немного, так скажем. всегда радуют люди, которым в ядре показать нечего, но которые уже знают, что оно несложное :)
0
коих пока обнаружено очень немного, так скажем
Вы пока тоже не продемонстрировали способности оценивать эти знания.
всегда радуют люди, которым в ядре показать нечего,
Всегда радуют люди, которые знания в определенных областях меряют количеством запощеных патчей в ядро.
но которые уже знают, что оно несложное :)
Да, я уже обратил внимание, что навык внимательного чтения написанного у вас в зачаточном состоянии :) Умудриться увидеть «несложность» в словах о переоценке сложности это так по-lifelover-ровски :)
0
так для чего нужен rcu в dcache?

и да, наличие патчей в ядре обязывает к некоторому реальному знанию (не исчерпывающему, но все же).
0
Господа, извините, но вам еще не надоело письками меряться?
Bzzz, никто не сомневается, что вы хорошо пишете на си, разбираетесь в линуховом ядре и быстро пишете код для STM32 с использованием SPL. Вопрос скорей такой: каким образом все это относится к теме данного топика? И другой вопрос: почему если вы делаете именно так то и все остальные должны делать именно так? Ваше мнение единственно верное?
+2
ну прочитай комменты еще раз, забыл со вчера, видимо :)

я вроде тебе уже писал… делиться, наверное, имеет смысл тем, что полезно. а не опытом обжигания пальцев и подобным. то что ты написал, полезным не является, imho.
в целом я понимаю ценность подхода «сделать все самому чтобы понять», но это делают только для себя. а вот STL сделана для всех. сделал лучше — можно вынести на публику, конечно.
но то что я вижу, не стоит ;)
0
Если для Вас лично это не имеет ценности, не значит, что оно не нужно никому.
Ну и напишите свою статью, что как и где надо делать, а мы уж оценим, на сколько там ценная информация.
P.S.
Кстати именно потому что статья не является обучающей я выкладывал ее в личный блог. В коллективный ее перекинул уже Ди. Что опять же говорит о том, что он посчитал данную информацию интересной.

Прекращайте уже пустой спор. Все равно каждый останется при своих…
+2
а вот STL сделана для всех.
Она задумана для всех. Но исполнение оставляет желать сильно лучшего.
+1
так для чего нужен rcu в dcache?
Вы действительно полагаете, что уже продемонстрировали способность оценивать чужие знания?
и да, наличие патчей в ядре обязывает к некоторому реальному знанию (не исчерпывающему, но все же).
Но их отсутствие точно так же ни о чем не говорит.
0
И применяет принципы ООП для управления.
Впрочем, в пользу С++ выступать не буду. Я его ненавижу так же, как и С.
0
там из всех принципов ООП — таблицы методов… которые на си делаются легко, просто и быстро. в отличие от.
0
В С++ они делаются не сложнее. Впрочем, С++ мог ударить с другой стороны. Он действительно намного сложнее и непонятнее в неумелых руках, так что криворукие контрибуторы могли бы навалить неразгребаемого говна.
0
все тупые кроме я? :) в с++ они сложнее как минимум потому что это не просто вызов функции… при том, что нужно просто вызвать функцию :)
0
при том, что нужно просто вызвать функцию :)
Косвенный вызов функции — он и есть косвенный вызов функции, даже если слегка замаскирован под прямой. Если ты о чем-то другом — выражайся понятнее и детальнее.
И да, не в этом сложность С++.
+1
да уж куда понятнее. хватает, вообщем, си на такие вот проекты.
и код дизаассемблированный (что в поддержке случается) можно глядеть и понимать.
и нет у людей дурацких манер заворачивать всякую фигню из под ногтей в кучу оберток-классов.
0
в с++ они сложнее как минимум потому что это не просто вызов функции…
Не затруднит подробнее описать, что ж там такого не простого в этом вызове в плюсах?
0
про bionic слышал?
0
Только про Bionic Commando. И что-то мне подсказывает, что гуглить бессмысленно.
0
не рассчитывал на такой дурацкий слив… казалось бы, всего-то набрать «bionic»…
-1
Набрал. Первые пять ссылок:
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/
Которая?
0
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)
0
Вот с этого и следовало начинать, а не предлагать гуглить песчинку в куче одноименных песчинок.
Ну, bionic — это замена libc. На чем его вообще писать, кроме как на С? Пример вырожденный. Все равно, что привести Delphi RTL в качестве примера того, что на Delphi пишутся библиотеки.
+1
ну так они написали кучу кода на своей яве, чего бы и *это* сделать как-то иначе…
0
Потому, что это библиотека поддержки языка С. На чем-то ином ее и не напишешь (ну, быть может, на ассемблере еще, но это непортируемо, а ведроид запускается минимум на трех архитектурах). Тем более на яве, которая работает как раз поверх этой библиотеки — получается проблема курицы и яйца.
Хотя, я неоднократно видел случаи реализации кусочков libc на Delphi. Но не полностью и только для того, чтобы слинковать сишные объектники с программой на Delphi, а не для замены libc для сишных прог.
0
эээ? с чего бы это? какая разница на чем писать библиотеку? если язык позволяет сделать связывание и вызывать функции ядра, то на нем можно написать libc.
0
Ну хотя бы с того, что по меньшей мере странно писать кусок С не на С. И учитывая, что далвик наверняка завязан на бионик — на яве оно не получится в принципе.
+1
кусок си? libc — это вовсе не кусок си. это просто одна из стандартных библиотек.
не вижу почему оно не может получиться на яве.
0
Это библиотека поддержки языка. Даже если С без нее может обойтись — она играет для него такую же роль, как RTL для Delphi. Никто же не удивляется, что Delphi RTL написана на Delphi. Так же и тут, для libc C — самый логичный выбор.
не вижу почему оно не может получиться на яве.
Хотя бы потому, что ява исполняется на VM, которая сама написана на чем-то компилируемом в нативный код. И скорее всего — это именно C, соответвенно VM самой нужен bionic, чтобы работать.
0
не важно на чем написана VM. не важно на чем написан bionic. нужно чтобы одна могла вызывать функции другого (связывание) и чтобы в VM можно было вызывать функции ядра (что легко делается без libc.).

и да, для программировани на си libc не обязательна. и эти люди, типа, обсуждают программирование под stm32 :)
0
ОК, про бионик домыслы. Впрочем, по прежнему считаю что выбрать для этой задачи что-либо кроме С — большая странность.
и да, для программировани на си libc не обязательна. и эти люди, типа, обсуждают программирование под stm32 :)
Я где-то утверждал обратное?
0
Вы утверждаете что невозможно написать программу на C, без использования libc? Вы хорошо подумали?
0
ты не туда ответил… я каждый день пишу без libc.
0
Качественных программ тоже всё меньше.
0
Как и программирование в машинных кодах.
0
сказки…
0
Да, в вашем исполнении.
+1
факты будут? у меня фактов этих целый вагончик… ядра, компиляторы, утилиты, на андроеде масса системных библиотек и ядро — все си. системы хранения данных — си, обычно.
0
у меня фактов этих целый вагончик… ядра, компиляторы, утилиты, на андроеде масса системных библиотек и ядро — все си.
Это все традиционные области применения, расширения тут никакого и близко нет. Более того, компиляторы других языков программирования отличных от С зачастую пишутся на них же, так что написав «компиляторы» вы слегка передернули.
системы хранения данных — си, обычно.
Давно уже нет. Причем с ростом объема и сложности решаемых задач все меньше и меньше.
0
факты будут? я сейчас сходу назову несколько распределенных систем хранения данных, которые написаны на си.
это при том, что ни про какое «расширение» я не писал. я писал про «системное по», которое да, традиционно пишется на си (не все, конечно) и пока что нет признаков, что это изменится.
0
факты будут?
Легко.
я сейчас сходу назову несколько распределенных систем хранения данных, которые написаны на си.
И я легко назову несколько распределенных систем хранения данных, где С даже близко не лежал.
я писал про «системное по», которое да, традиционно пишется на си (не все, конечно) и пока что нет признаков, что это изменится.
Я еще раз напомню: доля системного софта неуклонно снижается. Но даже в традиционных областях применения С плюсы наступают ему на пятки.
+1
ну давай… gpfs, oracle, ceph, lustre.

за счет чего снижается? быдлокодом на яве закидали? смешно. пусть хоть сколько эта доля снижается, люди-то все равно продолжают си пользовать. зачастую даже когда они думают, что пишут на c++ :)
0
gpfs, oracle, ceph, lustre.
За остальные не скажу, а оракл тут не в тему.
Да, список (подозреваю не полный) можно изучить тут.
0
еще как в тему…

а что из этого списка добилось хотя бы сравнимой с mysql/postgress популярности?
0
еще как в тему…
Кластер на пару-тройку сотен географически распределенных узлов потянет?
а что из этого списка добилось хотя бы сравнимой с mysql/postgress популярности?
С каких это пор mysql/postgresql стали распределенными базами?
0
быдлокодом на яве закидали?
Кстати, факты будут?
0
конечно. зайди на маркет, на apple store. потискай оттуда так называемых «программ».
0
конечно. зайди на маркет, на apple store.
Это капля в море. К тому же на applestore как раз софт писанный на Objective-C, а не на яве.
0
зачастую даже когда они думают, что пишут на c++ :)
Хорошее статейко было об этом))
0
факты будут?
Нет. А у тебя есть факты, что на машинных кодах уже нигде никогда не пишут?
0
а мне это зачем? меня мышинный код не интересует… если кому-то нравится так писать — ради бога.
0
Но ты же назвал сказками то, что и на машинном коде еще пишут. Хотя, возможно, это и не лучший пример устаревшего языка. А вот на том же фортране (в том числе и f77, а не f95), который еще Дейкстра резко критиковал — еще как пишут. Так что в плане «все еще используется» С отнюдь не уникален.
0
«критиковал» — это не очень показатель, скажем. какой-нибудь профессор таненбаум критиковал монолитные ядра. только где этот профессор и где монололитные ядра.

если fortran выжил, значит он достаточно хорош для своих задач. и это прекрасно. что есть проверенные временем и кучей людей инструменты. для программирования.
0
В первую очередь не столько хорош, сколько имеет ни с чем не сравнимую библиотеку наработок в области математики. Поэтому затеяв что-то математическое придется задуматься — делать все самому, или воспользоваться готовым, но писать на фортране. Когда готовое перевешивает — появляется еще одна новая программа на фортране. Схожим образом живут и другие старые языки.
Впрочем, у таких языков как С достаточно сильны отголоски популярности и некоторые пишут на них не потому, что С больше всего подходит, а просто потому, что он нравится.
«критиковал» — это не очень показатель, скажем.
Ну, как минимум, критиковал он заслуженно (и в f95 многое из того поправили, а в С все это было исправлено изначально). Насчет «резко» — тут да, Дейкстра тот еще тролль.
только где этот профессор и где монололитные ядра.
Что не мешает поскрипывать зубами, сталкиваясь с проблемами монолитных ядер. Ну и чисто монолитных ядер вроде уже нет — их заменили гибридные. Чисто микроядер, окромя таненбаумовского миникса, впрочем, тоже нет.
0
«Этот профессор» на сколько я знаю, уважаем тем же Линусом. Если вы уважаете Торвальдса, то откуда такое неуважение к Таненбауму? И что тогда заставляет вас ненавидеть С++ только из-за того, что его ненавидит Торвальдс?
Монолитные ядра в Винде — каторая зачастую оказывается в бсоде, к линуксе, которые постоянно в панике. А микроядра, в пользу которых высказывался Таненбаум в QNX.
+1
дело тут не в уважении. где эта qnx и где linux/windows. просто некоторым невдомек, что достаточную надежность можно обеспечить и без выноса всего в разные адресные пространства. и не терять в производительности.
0
linux/windows и qnx вообще-то из разных миров. которые практически не пересекаются. единственно, после покупки BB, они на планшет ее потянули.
+1
*ВВ — BlackBerry
0
вообще-то qnx на x86 имеется. только с реальностью он плохо пересекается ;) были еще mach, hurd, l4. да толку-то…
0
она под все основные архитектуры есть. и что? она не на десктоп ориентирована. и сравнивать с десктопными осями как минимум некорректно.
0
я вроде выше и написал, что она в какой-то своей, очень узкой, нише как-то влачит существование. но не более того. никому, практически, это микроядро не нужно, накладные расходы слишком высокие.
0
ну, ниша вполне специфичная да. хотя ВВ ее на свои планшеты и телефоны потащили.
0
далеко уехали? ;)
0
пока только выпустили, так что об этом еще рано. да и ВВ никогда особенно массовым продуктом не были.
0
не вижу никаких технических преимуществ. какое-нибудь ios/android прекрасно справляются без микроядра.
0
а вам не кажется, что ваше мнение где-то на уровне кухонной политики? наверное инженерам виднее.
0
очевидно ;) я вообще-то тоже инженегр ;) и в гугол-эппл-нокиа-проч — тоже инженегры ;)
0
очевидно, вы просто не можете быть в курсе всех причин, что они не просто лицензировали ось, а покупали всю контору.
0
зато вы в курсе ;) ни у кого кроме RIM не хватило ума/денег лицензировать правильную qnx ;) ни у кого не хватило ума взять какой-нить l4 и на нем все сделать ;)
0
зато вы в курсе ;)
где я такое сказал? не включайте lifelover-mode и не приписывайте слова.
ни у кого кроме RIM не хватило ума/денег лицензировать правильную qnx
у многих далеко не глупых людей ума хватило. что видно из областей применения.
0
ну так и запишем, у кого qnx у того и ум ;) а у кого нету qnx, у того и ума нет ;)
давай уже, расскажи в чем так сильно потеряли гуглы с эпплами не взявшие qnx.
0
да ну тебя.
+2
да сколько угодно. пока что я вижу, что по-существу ты ничего сказать не можешь. приводишь в пример несуществующие фактически продукты, техническая аргументация никакая. аналогичный аргумент в случае с google/apple/nokia — игнорируешь :)
0
ну так и запишем, у кого qnx у того и ум ;) а у кого нету qnx, у того и ума нет ;)
Вы решили окончательно прикинуться lifelover-ом? :)
+2
нам и одного много ))
+2
угу. впрочем, livelover заклюет последователей за применение некошерного ооп :)
0
мне вообще не нужно никем прикидываться. мнение есть и аргументировать я его могу. без эпических «линукс — это не очень сложно».
0
мне вообще не нужно никем прикидываться. мнение есть и аргументировать я его могу
Охотно верю. Можете проделать это на примере QNX.
без эпических «линукс — это не очень сложно».
Да, это была эпическая глупость в вашем исполнении.
0
ничего, тут все ходы записаны. кто что сказал… с тобой технические детали обсуждать смысла нет. я тебе несколько раз задал несложный вообщем-то вопрос, ты все разы слился. про qnx/микроядра я выше писал. однако не думаю, что тебе это интересно.
+1
с тобой технические детали обсуждать смысла нет.
Угу. И не факт, что вы в состоянии это делать.
я тебе несколько раз задал несложный вообщем-то вопрос, ты все разы слился.
Не путайте «слился» с «не ведусь на „слабО“. Как я уже писал, вы пока никак не продемонстрировали, что в состоянии оценивать чьи-либо знания.
однако не думаю, что тебе это интересно.
В вашем исполнении — скорее всего нет.
0
Оффтоп, хотя какой нахрен оффтоп здесь. Спасибо за наводку — playbook интересная шняга, стоит меньше 200у.е., вот теперь нужно думать это или нексус 7.
0
Вы дадите гарантию, что ваша система будет работать надежно, при использовании стороннего драйвера мигания светодиодом? Почему винда так докапывается до подписи драйверов (ну то что денег срубить, то понятно)?
Монолитное ядро популярно, да. за счет своей производительности. Микро ядро популярно в промышленности, за счет своей надежности. Вам гарантируют, что ваш атомный реактор не навернётся, из-за ошибки в драйвере звонка входной двери, последний упадет сам, сохранив целостность ФС и памяти других программ/драйверов. В монолитном ядре встречаются случаи приведения в негодность ФС диска, из-за ошибки доступа в некачественном драйвере.
Сделать надежно монолитное ядро можно, только делать надёжно обязаны все. В микро ядре же добиваются отказоустойчивости, при некоторой допустимой ненадежности компонент.
0
это все расхожие сказки. одного ядра для этого недостаточно. чтобы редактор не навернулся, нужно чтобы он сам был написан соответствующим образом: умел заново открыть все нужные дескрипторы, записать и проч. таких програм *почти* нет.
и, к слову, во время разработки я регулярно попадаю в какое-нибудь GFP… но данные при этом теряю не так часто ;)
из-за некачественного драйвера файловая система на микроядре точно так же может потерять/испортить данные ;)
0
  • avatar
  • bzzz
  • 22 февраля 2013, 09:46