Здравствуйте, CreatorCray, Вы писали:

A>>А как же сами индусы?
CC>Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

Индусокодеры

Здравствуйте, alexdev, Вы писали:

A>Здравствуйте, CreatorCray, Вы писали:

A>>>А как же сами индусы?
CC>>Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

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

Здравствуйте, CreatorCray, Вы писали:

CC>ICC например совместим с MSVC и GCC (линуховая версия ICC).

Кстати, xlc с 9й версии (а может и раньше) совместим с gcc на уровне ключей.

Здравствуйте, Mr.Cat, Вы писали:

MC>В соседней ветке

Автор: yumi
Дата: 25.01.10

, кстати, обсуждается возможность улучшить C не путем превращения его в C++, а путем улучшения макросов.

С с такими макросами — уже не С будет . Т.е. если туда добавить гигиенические макры и в совокупности с llvm мы лисп порвём на тряпки , по гибкости и скорости. Но есть у меня сомнения что гигиенические макры дадуться бесплатно.

Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?

Здравствуйте, dr.Chaos, Вы писали:
DC>мы лисп порвём на тряпки , по гибкости и скорости.
Или превратимся в лисп.

DC>Но есть у меня сомнения что гигиенические макры дадуться бесплатно.
Я слышал, что строгая типизация вносит сложности в макросы. Т.е., видимо, придется дополнительно черпать идеи из nemerle/haskell/...
Еще для гигиены желательно наличие какого-то механизма пространств имен, чтобы развернутый в разных местах программы макрос ссылался на одни и те же функции/макросы (которые были видны в месте его определения).

DC>Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?
Кстати, а откуда исходит уверенность в том, что go будет супершустрый, как C? Там же, я так понял, планируется применять такие высокоуровневые вещи, как процессы/каналы, интерфейсы с аналогом утиной типизации и т.п. Т.е. мне показалось, это будет что-то типа эрланга, что-ли.

Здравствуйте, Mr.Cat, Вы писали:

MC>Или превратимся в лисп.

Только быстрый и типизированный.

DC>>Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?
MC>Кстати, а откуда исходит уверенность в том, что go будет супершустрый, как C? Там же, я так понял, планируется применять такие высокоуровневые вещи, как процессы/каналы, интерфейсы с аналогом утиной типизации и т.п. Т.е. мне показалось, это будет что-то типа эрланга, что-ли.

В супершустрости Go я не уверен, но мне нравится как в нём решены многие проблемы, пока нравится. А процессы/каналы я и в С использовать могу, это не делает его дальше от железа.

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

Здравствуйте, dr.Chaos, Вы писали:
DC> но мне нравится как в нём решены многие проблемы
Имеются в виду проблемы C? А можно в двух словах? Я просто с этой стороны на Go не смотрел. Вроде как с хедерами разобрались раз и навсегда. Наверняка с контролем за размерами буферов и т.п. получше. А вот как там с обработкой ошибок/освобождением ресурсов? Эксепшены?

DC>А процессы/каналы я и в С использовать могу, это не делает его дальше от железа.
Я так понял во Go процессы "юзерспейсные", а не потоки ОС. Т.е. вроде как в порядке вещей наплодить их много-много (ну я судил по примеру с prime sieve). Плюс вроде там сборка мусора есть. Хотя вон, предшественник (как я понял) go — limbo — использовался как раз для системного программирования в inferno.

Здравствуйте, Mr.Cat, Вы писали:

MC>Имеются в виду проблемы C? А можно в двух словах? Я просто с этой стороны на Go не смотрел. Вроде как с хедерами разобрались раз и навсегда. Наверняка с контролем за размерами буферов и т.п. получше.

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

MC>А вот как там с обработкой ошибок/освобождением ресурсов? Эксепшены?

Там с обработкой ошибок ещё не решили до конца, пока коды возврата. Думаю при желании можно накрутить сверху монаду Maibe .

MC>Я так понял во Go процессы "юзерспейсные", а не потоки ОС. Т.е. вроде как в порядке вещей наплодить их много-много (ну я судил по примеру с prime sieve). Плюс вроде там сборка мусора есть. Хотя вон, предшественник (как я понял) go — limbo — использовался как раз для системного программирования в inferno.

Goroutines мапятся на реальные нити, но как — хз, только рантайм знает . Не думаю что сборка мусора будет большой проблемой.

Здравствуйте, dr.Chaos, Вы писали:
DC>Goroutines мапятся на реальные нити, но как — хз, только рантайм знает . Не думаю что сборка мусора будет большой проблемой.
Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?

Здравствуйте, Mr.Cat, Вы писали:

MC>Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?

Время покажет. Мне нравится простота языка, но между "мне нравится" и "замена С" сам понимаешь пропасть, я, собственно, и не берусь утверждать что Go заменит C (да и не верю в это), просто ИМХО у подхода с небольшим набором фич больше шансов.

Здравствуйте, Mr.Cat, Вы писали:

MC>Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?

Рантайм пусть делат, главное что бы не было необходимости это контролировать.

А то в с++ приходится явно контролировать неявное

Здравствуйте, Vamp, Вы писали:

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

Здравствуйте, bazis1, Вы писали:

B>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...

Здравствуйте, dr.Chaos, Вы писали:

DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.

Мало того, можно довольно легко родить анализатор, который укажет на "некашерные" места...

Здравствуйте, Ikemefula, Вы писали:

I>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.
Дык ты С-шные исходники под много компиляторов видел?

E>Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...
Чем тебе STL-то не угодил? Где в нем опасность?

E>Можно было бы на платформе застандартизировать принцип декорирования имён.
Можно было бы. Манилова помнишь?

E>Можно через виртуальные функции и интерфейсы всё делать на худой конец...
А эти тут причем?

Здравствуйте, Vamp, Вы писали:

V>Чем тебе STL-то не угодил? Где в нем опасность?
Очень легко написать очень неэффективный код. Предполагает очень умного и знающего пограммиста.
Собственно я отвечал на сообщение, где наличие STL упоминадось как недостаток С++.
Можно разработать менее кудрявый фреймворк, который будет не таким легко расширяемым и универсальным, но, зато, и не будет провоцировать написание неэффективного кода по незнанию...

Здравствуйте, Vamp, Вы писали:

V>Можно было бы. Манилова помнишь?
При чём тут Манилов? В чём проблема вообще сделать декорирование настраиваемым в любом компиляторе?
Вот была бы часть API линукса на С++ и все бы как миленькие декарировали бы имена так же, как и gcc...

Другое дело, что взаимодействие с другими языками было бы *сильно затруднено*, ну да и фиг бы с ним, с другой стороны...

E>>Можно через виртуальные функции и интерфейсы всё делать на худой конец...
V>А эти тут причем?

Ну COM под виндой, например, знаешь?

E>При чём тут Манилов?
При том, что тот тоже мечтал о несбыточном.

E>В чём проблема вообще сделать декорирование настраиваемым в любом компиляторе?
Декорирование имен не входит в стандарт. Хорошо это или плохо — я не знаю. Наверное, плохо, но по-другому не выходит, потому что стандарт такими вещами не занимается.

E>Вот была бы часть API линукса на С++ и все бы как миленькие декарировали бы имена так же, как и gcc...
E>Другое дело, что взаимодействие с другими языками было бы *сильно затруднено*, ну да и фиг бы с ним, с другой стороны...
Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?

E>Ну COM под виндой, например, знаешь?
КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.