Чего Вам не хватает в С ?

Про МПД это шутка? Она ничего не дает по сравнению с МТ, разве что реальна. Другое дало Лямбда Чёрча.

 

J0E
с# пробывал?

 

J0E

ага, незначительный факт

 

wsd
Много чего, многое из того что сейчас требует буста, будет в языке. Вот кое-что - http://gcc.gnu.org/projects/cxx0x.html. Например Rvalue references позволит отличать ссылки на временные объекты и неплохо оптимизировать.

 

Booster
а ты с# пробывал?
чего там только нет) серьёзно.

 

В C# нет возможности выполняться в ядре. А что есть? множественное наследование? вывод типов, алгебраические типы, карринг? Зато синтаксис унаследовал чрезмерность С, запятые

Теперь поясню про бесполезность МПД (кстати, кто это придумал?). Фича лямбда исчисления в том, что чистая функция не хранит состояние между вызовами, поэтому ее результат зависит только от параметров, а не от записей на ленте МТ. МПД в данном контексте ничем не отличается от МТ, что бы доказать корректность фукнции недостаточно проверить ее результат, нужно перебрать еще и все возможные комбинации состояний ячеек памяти, что невозможно.

 

wsd

Lisp всё равно круче.

 

J0E

га?
кусок цитаты из мсдн по слову STL

hash_map
hash_map Class

hash_multimap
hash_multimap Class

hash_multiset
hash_multiset Class

hash_set
hash_set Class

map
map Class

multimap
multimap Class

multiset
multiset Class

set
set Class

може мы слово "объект" по разному понимаем?

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

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

алеф живет на п9. на уровне языка в нем реализованы не только множества, которые, кстати говоря, ни что иное как

(int8, int32, int64)
=====
struct {
int8;
int32;
int64;
};

в нем на уровне языка реализованы и потоки, и процессы, и каналы, и блокировки, и межпоточный/межпроцессный обмен. и итераторы. например (пример на синтаксисе лимбо, потомке алефа, но разница небольшая),

Код (Text):

1. implement T;
2.  
3.  
4. include "sys.m";
5. sys : Sys;
6.  
7. include "draw.m";
8.  
9.  
10. T: module {
11.   init : fn(ctxt: ref Draw->Context, vpar: list of string);
12. };
13.  
14.  
15. init(ctxt: ref Draw->Context, vpar: list of string){
16.   sys = load Sys Sys->PATH;
17.  
18.   chns := array [10] of {* => chan of (int, chan of string)};
19.  
20.   spawn foo(chns[4]);
21.  
22.   (i, (v, rCh)) := <-chns;
23.  
24.   sys->print("i = %d, v = %d\n", i, v);
25.  
26.   if(rCh != nil)
27.     rCh <-= "h w!";
28. }
29.  
30.  
31. foo(ch: chan of (int, chan of string)){
32.   rch := chan of string;
33.  
34.   if(ch != nil){
35.     ch <-= (3, rch);
36.  
37.     sys->print("%s\n", <-rch);
38.   }
39. }

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

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

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

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

вм тут виртуальная машина? алеф делает нативный код. от размера мз-пе хидера + ret (кстати, тут в теме про прямой вызов int2e я файлик прикреплял. он как раз этим кривым портом алефа и сделан. 1кб, правда только месБокс выводит и все). ессно, более длинный код даст больший файл.

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


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

спасибо

 

Приветствую, просветлённые.

Мне не удалось осилить сей текст в полном объеме, но считаю, всё это - предпосылки к священной войне "Язык VS язык". Я предостерегаю вас и надеюсь, что все те, кто считает тот или иной язык не достаточным в чем либо, найдут в себе силы прочесть документацию и постыдиться.

 

sveta
Я вам приведу почти в каждом языке пачку недостатков, дело не в прочтении документации.

 

а по-моему тут уже давно не предпосылки, причйом глупость доходит до споров о истоках терминов, и я слышу скрип зубов ГН при многократных 'пробывать' (или это мои зубы скрипят?) ,)
я бы вот в си подфункции реквестировал, это бы меня временами радовало ")

 

> подфункции

омг o_O

 

подфункции ?
я иногда когда пишу функцию и понимаю что в этом месте неплохо было бы вынести часть кода в вспомогательную функцию начинаю ее писать прямо в месте вызова а потом просто ее копипаст в нужное место удобно тем что когда пишеш по месту находишся как бы в контексте информации не надо смотеть то туда то туда )

 

но не везде так удобно

 

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

 

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

 

google

Вспомнился Назимок и сети сетей...

 

_DEN_
Реально удобно, пожалуй мне этого тоже не хватает в C. Яркий пример:
Подфункция работает с большим количеством локальных переменных основной функции и рекурсивно вызывает себя. Будь то отдельная функция, пришлось бы передавать множество параметров, так не далеко и от переполнения стека. Можно конечно все хранить в глобальных переменных, либо в выделяемой динамически структуре данных и передавать меньшее количество параметров, но это лишний геморрой.

 

google

Большое количество локальных переменных - это уже плохо.

 

Comer_
_DEN_
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html