Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

[D_KEY]

Цитата korvin @ 26.04.11, 19:41

Цитата D_KEY @ 26.04.11, 19:36

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

ну тогда не нужно бросаться такими общими фразами =)

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

[Мяут-Настоящий]

Цитата korvin @ 26.04.11, 19:43

то-то санкам пришлось продаться... =)))) ну ладно, это просто подколка =) OpenSolaris, я смотрю, бурно развивается? =)))

За санок не скажу, но вот такие паники вымораживает читать:
panic[cpu2]/thread=300107e33c0: CMM: Cluster lost operational quorum.

    cl_runtime:__1cZsc_syslog_msg_log_no_args6Fpviipkc0_nZsc_syslog_msg_status_enum__+30
    %l0-3: 00000000709906d0 000000000000004c 000003000f083ee6 000000000000004c
    %l4-7: 000000005ebe0acc 000003000f0833d9 0000000000000001 000000007035b000
    000002a1010d35f0 cl_runtime:__1cCosNsc_syslog_msgDlog6MiipkcE_nZsc_syslog_msg_status_enum__+1c
    %l0-3: 0000000000000009 000000007035e026 0000000000000001 0000000000000000
    %l4-7: 0000000000000000 0000000070990000 0000000000070800 0000000000000002
    cl_haci:__1cOautomaton_implbAstate_machine_qcheck_state6M_nVcmm_automaton_event_t__+4a4
    %l0-3: 000000007093e000 0000000070990000 000000000007093e 0000000000070800
    %l4-7: 0000000070990000 0000000000070990 0000000000070800 00000300107c1c20
    000002a1010d3930 cl_haci:__1cIcmm_implStransitions_thread6M_v_+f4 (300107c0008, 1, 1,
    %l0-3: 00000300107c0078 00000300107dd5a4 000000000001d59c 000000000001d400
    %l4-7: 000000000000002c 0000000000000004 000000000001d354 00000300107c0498
    000002a1010d39e0 cl_orb:cllwpwrapper+c4 (2a1010d3b70, 7aa0b374, 2, 2, 2, 0)
    %l0-3: 0000000000001800 0000000000000007 fffffffffffffffd 000000000000003a
    %l4-7: 0000000070941000 0000000000070941 0000000000070800 0000000001934400
    000002a1010d3ac0 unix:thread_start+4 (2a1010d3b70, 18, 0, 0, 0, 0)

Цитата korvin @ 26.04.11, 19:43

OpenSolaris, я смотрю, бурно развивается? =)))

OpenSolaris мертв. Ему на смену проприетарный Solaris 11 Express пришел. Но судя по тому, что я вижу по патчам, движуха идет

Добавлено 26.04.11, 19:49

Цитата korvin @ 26.04.11, 19:43

так, что его почти не юзает для написания ОС => как минимум в одной нише он не лучше // КО
а попытки его таки заюзать ничем особо хорошим не обернулись =)

L4Ka::Pistachio (микроядро) - на C++ написано

[korvin]

Цитата D_KEY @ 26.04.11, 19:29

Собственно это и продолжается до сих пор, поскольку D, Go и другие попытки занять туже нишу пока малопригодны для практического использования.

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

[D_KEY]

Цитата korvin @ 26.04.11, 19:40

Цитата D_KEY @ 26.04.11, 19:25

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

box -- ссылочный тип, ссылочные типы тем и отличаются, что для изменеия какого-то их поля нужно вызывать accessor, они не изменяются сами по присваиванию, т.к. переменные тут не при чем, только значения и их типы при чем

Да, но твой box - явно параметризованный тип, точно так же, как и плюсовый *(ну или его "умные" аналоги). Т.е. твой пример можно переписать в С++ на указателях.
Ты не продемонстрировал работу неявно-ссылочных типов, о которой тут и шла речь последнее время.

[korvin]

Цитата Мяут-Настоящий @ 26.04.11, 19:48

L4Ka::Pistachio (микроядро) - на C++ написано

где оно юзается?

[Мяут-Настоящий]

Цитата korvin @ 26.04.11, 19:51

где оно юзается?

Лежит в основе OKL4 например: http://www.ok-labs.com/products/okl4-microvisor

[korvin]

Цитата D_KEY @ 26.04.11, 19:25

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

так пойдет:

(struct data  (data))
 
(struct link  data ())
(struct value data ())
 
(define (set data new-data)
  (set-data-data! data new-data))
 
(define (get data)
  (match data
    ((link  x) data))
    ((value x) (value (copy-bytes x))))
 
(define (apply-1 f . args)
  (apply f (map get args)))

? надеюсь понятно? где в поле data структуры data записывается двоичное значение. т.е. я к тому, что не зависимо от переменной, если тип предоставляет семантику значения (хотя по факту может быть хоть указателем и выделяться в куче), то он автоматически копируется. как пример уже приводили string в делфи -- реализация ссылочная с cow, но ведет себя как значение.

Добавлено 26.04.11, 20:05

Цитата Мяут-Настоящий @ 26.04.11, 19:53

Лежит в основе OKL4 например: http://www.ok-labs.com/products/okl4-microvisor

мне кажется, ребята поспешили, если я правильно понял, что они предлагают. но где описаны профиты от выбора С++? вот еще один вопрос: почему многие ЯП, компилируемые не напрямую, а через трансляцию в С, юзают именно С, а не С++?

Добавлено 26.04.11, 20:08

Цитата korvin @ 26.04.11, 20:01

надеюсь понятно?

да, чтобы не было претензий по "ссылочной семантике": структуры-контейнеры удаляются при тайпчеке (собственно их назначение -- объединение значения и его типа в один объект, так проще. это может быть не структра как у меня, а что угодно, хоть cons-cell, хоть алгебраический тип данных

Сообщение отредактировано: korvin - 26.04.11, 20:19

[Мяут-Настоящий]

Цитата korvin @ 26.04.11, 20:01

мне кажется, ребята поспешили, если я правильно понял, что они предлагают. но где описаны профиты от выбора С++? вот еще один вопрос: почему многие ЯП, компилируемые не напрямую, а через трансляцию в С, юзают именно С, а не С++?

Простой гугл ведет сюда:

There is the common misbelieve that C has performance advantages over
C++.  However, that is mostly due to a misunderstanding by the
programmers of mechanism in C++ which are sometimes heavyweight and not
available in C.  C++ has many advantages over C, such as semi-strict
type checking, operator overloads, virtual functions, stricter
encapsulation (in objects), code re-use, and name spaces.
Now one may say that in particular virtual functions are a bad thing due
to the additional level of indirection, but that is short sighted.
Consider the virtual file system in most Unix derivates, or device
drivers in general.  What everybody uses is a list of function pointers
stored in a structure which are called for the different fs or driver
functions.  That is not different to virtual functions in C++.  The
generated code in C++ is even more efficient because you don't have
these unnecessary checks for NULL-function pointers on every call since
the compiler enforces correct function pointers at compile time.  (Linux
even introduced constructors and destructors in certain places.)  That
said it is of course still possible to write inherently inefficient code
using C++, but that is true for almost all programming
language--including C.
 
When we designed L4Ka::Pistachio the main focus was on performance and
we would not have chosen C++ if that would give us any performance
disadvantage.  Usually, structural problems are of greater concern here,
and that is true for almost all projects.  Consider MACH--even though it
was written in C, performance was terrible.
 
It would be great to see a shift away from C towards better programming
languages in general considering all these unnecessary bugs in OSs we
see every day.  And I'm not talking about C++ here...

http://lists.gnu.org/archive/html/l4-hurd/2003-11/msg00022.html

[D_KEY]

Цитата korvin @ 26.04.11, 20:01

так пойдет

А что принципиально изменилось? Все явно описано. Я и на С++ могу так же.

[korvin]

Цитата

operator overloads, virtual functions

несколько сомнительные преимущества

Цитата

Consider MACH--even though it
was written in C, performance was terrible.

странно, не заметил тормозов в макоси, не смотря на то, что юзаю в виртуалке =/

Цитата D_KEY @ 26.04.11, 20:21

Цитата korvin @ 26.04.11, 20:01

так пойдет

А что принципиально изменилось? Все явно описано. Я и на С++ могу так же.

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

Добавлено 26.04.11, 20:30
хорошо, давай так: компилятор проверяет тип, связанный с (переменной, если она незабиндена)/(значнеия, если забиндена)()но в общем-то это одно поле, ибо тип переменной имеет смылс только, если она объявлена без инициализации) если это
ссылка -- вставляет адресс размещения
значение -- вставляет код копирования.

Сообщение отредактировано: korvin - 26.04.11, 20:32

[D_KEY]

По моему мнению, единственная настоящая проблема в С - это отсутствие "деструкторов" или "менеджеров контектста", в результате чего работа с любыми ресурсами превращается в малоприятное занятие.
Собственно, Мяут уже об этом говорил. Еще бы не мешало немного дженериков.

Добавлено 26.04.11, 20:35

Цитата korvin @ 26.04.11, 20:26

хорошо, давай так: компилятор проверяет тип, связанный с переменной, если это
ссылка -- вставляет адресс размещения
значение -- вставляет код копирования.

Что я слышу? Неужели: "переменные"?

А если серьезно, я все не могу понять, зачем ты мне объясняешь принципы реализации таких неявно-ссылочных типов?
Ведь я спрашивал, зачем в системе типов нужно такое разделение, как не для переменных(о которых ты все время говорил, что они тут не при чем)?

Добавлено 26.04.11, 20:40
korvin, еще раз. Единественное, на чем сказывается такое различие - это переменные.
В случае составных типов будет несколько сложнее, да.

[amk]

Цитата korvin @ 26.04.11, 19:43

у питона вроде неплохо с юзанием С-кода (сколько там модулей написано на С?).

Если про основную ветвь интерпретатора, то все, которые не на самом питоне. Да и сам питон на С написан.

Цитата korvin @ 26.04.11, 19:50

Цитата (D_KEY @ Сегодня, 02:29)
Собственно это и продолжается до сих пор, поскольку D, Go и другие попытки занять туже нишу пока малопригодны для практического использования.

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

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

items = [ i for i in range(10) if pred(i) ]
# или
def sinc(x): return 1 if x == 0 else sin(x)/x

а ведь первое практически повторяет описание множества в математике { x | x in 0..9 & pred(x) }
Здесь in обозначает значек принадлежности.
А второе мало отличается от математического же

sinc(x) = { 1,        если x = 0
            sin(x)/x, если x /= 0

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

#define WORD(w) (w)&255,(w)>>8
 
unsigned char program[] = {
  OUTSTR, 'Р','а','д','и','у','с',':',' ',0, INPINT,
  INT,WORD(31416), MULT,
  INT,WORD(10000), DIV,
  OUTSTR, 'О','к','р','у','ж','н','о','с','т','ь',' ',0,
  OUTINT,
  STOP
}
 
void interpret(unsigned char *ip)
{
  while (*ip != STOP)
    op[*ip++](*ip);
}
 
int main()
{
  interpret(program);
  return 0;
}

и

void program()
{
  op_outstr("Радиус: "); op_impint();
  op_int(31416); op_mult();
  op_int(10000); op_div();
  op_outstr("Окружность ");
  op_outint();
}

Первый - пример интерпретации байт-кода (конкретно, косвенного шитого кода)
Второй - почти чистый пример подпрограммного шитого кода. Фактически - тоже интерпретация.

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

Сообщение отредактировано: amk - 26.04.11, 20:55

[korvin]

Цитата D_KEY @ 26.04.11, 20:31

Что я слышу? Неужели: "переменные"?

не ужели ты услышал "ссылочные переменные" и "переменные-значения"?

Добавлено 26.04.11, 20:52

Цитата D_KEY @ 26.04.11, 20:31

А если серьезно, я все не могу понять, зачем ты мне объясняешь принципы реализации таких неявно-ссылочных типов?
Ведь я спрашивал, зачем в системе типов нужно такое разделение, как не для переменных(о которых ты все время говорил, что они тут не при чем)?

затем, что тайпчекер должен проверять корректность типизации, а не переменными заниматься, переменные -- всего лишь символы, которые могут стираться еще до тайпчека

Добавлено 26.04.11, 20:53

Цитата D_KEY @ 26.04.11, 20:31

korvin, еще раз. Единественное, на чем сказывается такое различие - это переменные.
В случае составных типов будет несколько сложнее, да.

нет, не будет. переменные не должны знать о типах. их единственное знание -- область видимости.

Добавлено 26.04.11, 20:55

Цитата amk @ 26.04.11, 20:47

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

извини, но ты с какой луны свалился? оттранслированный в С код -- это код на С, который компилируется в машкод. исходного текста полсе трансляции НЕТ

Добавлено 26.04.11, 20:56

Цитата amk @ 26.04.11, 20:47

Например, сравни пару фрагментов

#define WORD(w) (w)&255,(w)>>8
 
unsigned char program[] = {
  OUTSTR, 'Р','а','д','и','у','с',':',' ',0, INPINT,
  INT,WORD(31416), MULT,
  INT,WORD(10000), DIV,
  OUTSTR, 'О','к','р','у','ж','н','о','с','т','ь',' ',0,
  OUTINT,
  STOP
}
 
void interpret(unsigned char *ip)
{
  while (*ip != STOP)
    op[*ip++](*ip);
}
 
int main()
{
  interpret(program);
  return 0;
}

и

void program()
{
  op_outstr("Радиус: "); op_impint();
  op_int(31416); op_mult();
  op_int(10000); op_div();
  op_outstr("Окружность ");
  op_outint();
}

это ты хрень какую-то показываешь, а не трансляцию в Си

Добавлено 26.04.11, 21:12

Цитата amk @ 26.04.11, 20:47

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

получается нативный код CL

CL-USER 1 > (defun foo (x) (+ x 1))
FOO
 
CL-USER 2 > (disassemble 'foo)
21AAAFEA:
       0:      89E6             move  esi, esp
       2:      81CEFCFF0F00     or    esi, FFFFC
       8:      3966D0           cmp   [esi-30], esp
      11:      7318             jnb   L1
      13:      80FD01           cmpb  ch, 1
      16:      7513             jne   L1
      18:      55               push  ebp
      19:      89E5             move  ebp, esp
      21:      A803             testb al, 3
      23:      7511             jne   L2
      25:      89C7             move  edi, eax
      27:      83C704           add   edi, 4
      30:      700A             jo    L2
      32:      FD               std  
      33:      89F8             move  eax, edi
      35:      C9               leave
      36:      C3               ret  
L1:   37:      E8DE3467FE       call  2011E4F2         ; #<Function RUNTIME:BAD-ARGS-OR-STACK 2011E4F2>
L2:   42:      FF7500           push  [ebp]
      45:      83ED04           sub   ebp, 4
      48:      8B7508           move  esi, [ebp+8]
      51:      897504           move  [ebp+4], esi
      54:      894508           move  [ebp+8], eax
      57:      B804000000       move  eax, 4
      62:      C9               leave
      63:      E9DC1D67FE       jmp   2011CE0A         ; #<Function SYSTEM::*%+$ANY-STUB 2011CE0A>
      68:      90               nop  
      69:      90               nop  
NIL
 
CL-USER 3 >

или для Racket

#lang racket
 
 
(struct data (x))
 
(define (main)
  (print (data 1)))
 
(main)

результат трансляции в Си: http://paste.pro/1536506

[amk]

Цитата korvin @ 26.04.11, 20:49

исходного текста полсе трансляции НЕТ

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

Цитата korvin @ 26.04.11, 20:49

это ты хрень какую-то показываешь, а не трансляцию в Си

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

Это не трансляция в С. Это пример интерпретации в компилируемом языке. Кстати достаточно обычная вещь - так реализованы значительное число компиляторов.

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

[D_KEY]

Цитата korvin @ 26.04.11, 20:49

Цитата D_KEY @ 26.04.11, 20:31

Что я слышу? Неужели: "переменные"?

не ужели ты услышал "ссылочные переменные" и "переменные-значения"?

Цитата

Цитата D_KEY @ 26.04.11, 20:31

А если серьезно, я все не могу понять, зачем ты мне объясняешь принципы реализации таких неявно-ссылочных типов?
Ведь я спрашивал, зачем в системе типов нужно такое разделение, как не для переменных(о которых ты все время говорил, что они тут не при чем)?

затем, что тайпчекер должен проверять корректность типизации, а не переменными заниматься, переменные -- всего лишь символы, которые могут стираться еще до тайпчека

С утвержением согласен. Осталось понять, как оно связано с заданным мной вопросом...
Я все-таки не могу понять твоих ответов. Или ты не понимаешь вопросов...

Цитата

переменные не должны знать о типах. их единственное знание -- область видимости.

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

Цитата

type a = new type(...)
type b = a

В случае наличия неявно-ссылочных типов в языке переменная b будет или "ссылаться" на тоже значение типа type(если он нессылочный) или же(на уровне логики) обе переменные будут ссылаться куда-то в одно место, которое уже будет ссылаться на значение типа type(если тип ссылочный). То есть само понятие переменной и механизм работы с ними зависит от типа. С моей же точки зрения, лучше, когда переменные в языке ведут себя независимо от типа. Ты вроде тоже говоришь, что переменная о типе знать не должна... Так ты согласен со мной или нет?

Сообщение отредактировано: D_KEY - 26.04.11, 21:25