Post reply

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
√49 Напишите ответ строчными буквами:
«Сто одёжек, все без застёжек» — что это?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: myst
« on: November 14, 2009, 14:57 »

Еще один спор ни о чем?
Предмет спора не имеет значения, важен процесс. ;)
Posted by: sknente
« on: November 14, 2009, 04:44 »

Еще один спор ни о чем? Ням-ням.
Posted by: Triton
« on: November 14, 2009, 01:14 »

Ок, я буду на вашем языке разговаривать с вами.
Это ваша ошибка и проблема, что вы не понимаете (к примеру) всей глубины механизма шаблонов Си++, которые давно вкурило всё прогрессивное человечество. Учите матчасть и гуглите, гуглите.
Наше учение истинно потому что верно.
Posted by: Алексей Гринь
« on: November 14, 2009, 00:42 »

Quote
CF_CATCHED
facepalm.bmp
Posted by: Алексей Гринь
« on: November 14, 2009, 00:34 »

ag@ag-laptop:~/Проекты/cf$ cat main.c
#include "core/cfException.h"
#include "core/cfInvalidCastException.h"
#include "core/cfObject.h"

int main(void)
{
    CF_TRY
    {
        cfObject* o = CF_BOX_BOOL(false);
        int i = CF_UNBOX_INT(o);
        printf("Triton is cool!!111\n");
    }
    CF_CATCH(e)
    {
        printf("There was an invalid statement, but I ignored it! :)\n");

        CF_CATCHED;
    }
    CF_END_TRY;

    return 0;
}
ag@ag-laptop:~/Проекты/cf$ cd ./bin/Debug
ag@ag-laptop:~/Проекты/cf/bin/Debug$ ./cf

There was an invalid statement, but I ignored it! :)
ag@ag-laptop:~/Проекты/cf/bin/Debug$
Posted by: Алексей Гринь
« on: November 14, 2009, 00:15 »

Будь он двухпроходным, вошёл бы в рекурсию, да так бы и написал, что рекурсия.
В моновом Сишарпе, нопремер:
  Struct member `monostest.C.b' of type `monostest.B' causes a cycle in the struct layout(CS0523)

Эти "вещи" реализованы аппаратурой процессора, ядром и принятой моделью исполнения процессов.
Это, уважаемый, фелософея и димагогея. Любое 2 + 2 в итоге «реализованы аппаратурой процессора». Что вы хотите этим доказать?

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

С точки зрения семантики, разницы между

Quote
if(a == 0)
   fatal("Divide by zero!");
result = b / a;
   

и

Quote
try
{
   result = b / a;
}
catch(DivideByZeroException e)
{
   fatal("Divide by zero!");
}

НЕТ.
То, что вы втираете, это синтаксис. Да, средствами синтаксиса не ничего такого не реализовано. Оно и правильно.

"Реализовано на языке", "реализовано в языке" - бла-бла-бла, эти постоянные бессмысленные категоризации никому не упёрлись.

Quote
Атаки переполнения существуют потому, что выбранный язык реализации настолько беспомощен, что не может гарантировать ровным счётом ничего.
Вы, похоже, не поняли, придётся повторить: атаки переполнения существуют как раз из-за нерасторопности делать предпроверки. Неужели так сложно проверить длину буфера?

Тоже нерадивый программист в моём лице виноват?
Да, это ваша ошибка, а не си.
Posted by: myst
« on: November 13, 2009, 19:11 »

In April 2009, Shapiro - driving force behind both BitC and Coyotos.[2] - announced that he had accepted a position at Microsoft to work on the Midori project, and that after August 2009 he would not be working further on BitC[3].

BitC is no longer under active development.
Ну точно стух. :'(
Posted by: myst
« on: November 13, 2009, 19:08 »

Попробуйте переписать тот же багнутый алгоритм на Оберон, а потом его хакнуть - успехов.
Кстати, из Oberon'а можно было бы сделать очень неплохой системный язык... Но гигатонны кода на C...
Posted by: Triton
« on: November 13, 2009, 18:31 »

Кстати fclose(NULL) согласно спецификации также обладает undefined behavior, и, надо сказать, в glibc этот behavior таки действительно undefined. (Во всяком случае, в версии glibc приблизительно трехлетней давности.) Ни проверок, ни игнорирования NULL, ни вызова abort()...
Одна единственная опечатка if (file == NULL) мне стоила почти недели отладки программы, которая работала "почти всегда" и падала в рандомном месте.
Тоже нерадивый программист в моём лице виноват?
Posted by: Triton
« on: November 13, 2009, 18:04 »

Гринь, спокойно, санитары уже выехали.  :D
Фейлите как раз вы, вы даже не понимаете, о чём я говорю.
Ну вы-то можете говорить о чём угодно, только вот делаете вы не по теме. Обсуждались ограничения си. Вы в пример приводите вещи, как раз в 99.9% случаев реализованные на си.
Вы отличайте всё же палец от сами знаете чего. "Реализовано в языке" (как механизм с определённой семантикой) и "реализовано на языке" (как произвольный алгоритм) - это вещи разные совершенно.
Эти "вещи" реализованы аппаратурой процессора, ядром и принятой моделью исполнения процессов. А уж на чём они написаны - дело десятое. Хоть на басике, хоть в машинных кодах.
Когда программа делает *(int*)(NULL) = 123, то она прибивается операционной системой как глючная, а вовсе не потому, что такова семантика данной конструкций. По семантике это undefined behaviour, и с тем же успехом эта команда могла бы форматировать вам диск или менять разрешение на мониторе.

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