Что, господа суровые С++ программисты, поспорим быстродействием с отстойной Джавой? ;)

 
1 7 8 9 10 11 29
RU Nikita #18.07.2008 17:32  @anonymous_lor#18.07.2008 08:25
+
-
edit
 

Nikita

аксакал

anonymous_lor> я пришел на linux со своей программой, откомпилировал gcc и запустил, не изменил при этом ни символа в самой программе ... я не перенес её ?

Неправильная постановка задачи. Даю правильную.

Вы пришли со своей ASN.1 библиотекой к очередному заказчику, и он Вам выдал 6-битный кастомный встраиваемый криптопроцессор и соответствующий C/C++ кросскомпилер для него. Ну и как Вы думаете, перенеслась ? :cool:

anonymous_lor> зачем ? ...

А неважно. Факт в том, что Java автоматически всё это гарантирует. А C/C++ - нет.

И на каком-нибудь дохлом мобильном телефоне, пока Вы будете париться с его 16-ти разрядным (а может даже и с 8-ми :D ) процем, я на J2ME буду спокойно работать без заморочек :cool:

anonymous_lor> вот вот ... "высшие порядки" это где-то там, в небе ...

Это они для C++ в небе, бо там большинству даже выше банальных прощёлканных вызовов delete и ошибок копирования объектов трудно подняться. А в наших - Java/.NET - краях неочевидные ошибки распределения памяти начинаются почти сразу. То через делегат в event handler'е утечёт, то какой-нибудь локальный compiled Regex зевнёшь, то Женя Осовецкий и Ко подложат мину в каком-нибудь элементарном конструкторе XML-сериализатора...
Учитесь читать.  
+
-
edit
 

Kernel3

аксакал

Nikita> Не кажется. Ваш уровень восхищения thread'ами лично я преодолел года этак два назад, когда вплотную познакомился с настоящими проблемами параллелизма.
А что, по-вашему, есть настоящие проблемы параллелизма? Это не подколка, просто интересно стало :)
Broken Windows® cures my ills and makes me feel alright... ©  
RU Nikita #18.07.2008 17:48  @anonymous_lor#18.07.2008 08:33
+
-
edit
 

Nikita

аксакал

anonymous_lor> не стану, потому что такая программа никому не будет нужна

Ну разумеется, потому что Вы напишите её только к концу жизни Вселенной :D

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

Моя профессия - разработка ПО, и я свою профессию очень люблю. Поэтому другие способы меня не интересуют :)

anonymous_lor> надо продавать какой-нить товар ... а программированием миллиардером не станешь ...

Ерунда. Сделаете действительно крутой софт - к Вам все сразу прибегут. И всё будет сделано за Вас :D

anonymous_lor> мы про человеко-лет или про мегабайто-код ?

Мы про "простой текстовый редактор". Который на самом деле настолько непрост, что никто пока даже и близко не подобрался к нему.

anonymous_lor> я нигде не говорил что писть эффективные небольшие программы легко ...

Дело не в лёгкости, дело во времени. Писать-то их легко как раз, но долго.
Учитесь читать.  
RU Nikita #18.07.2008 17:50  @anonymous_lor#18.07.2008 08:39
+
-
edit
 

Nikita

аксакал

anonymous_lor> вот кстати чтобы за примерами далеко не ходить ... недавно просто устанавливал торрент-клиент...

Отличный пример!!! Java-клиент полностью портабельный и работает везде где эта самая Java есть, а вот uTorrent - Windows-only.
Учитесь читать.  

sxam

старожил

..
Nikita> Все мэйнстримовые реализации поддержки параллелизма убоги и, соответственно, неудобны. Только C# и выделяется, за счёт yield return. Но эта фича закрывает лишь раздел связанный с асинхронным I/O, базовые проблемы - так же как и у остальных.

Nikita, не понял, как yield return помогает с "асинхронным I/O"?
 
US Сергей-4030 #18.07.2008 18:11  @Nikita#18.07.2008 17:03
+
-
edit
 

Сергей-4030

исключающий третье
★☆
админ. бан
Сергей-4030>> А вам не кажется, что вы меня оскорбляете?
Nikita> Не кажется. Ваш уровень восхищения thread'ами лично я преодолел года этак два назад, когда вплотную познакомился с настоящими проблемами параллелизма.

Я не понимаю, что такое "восхищение" и что такое "настоящие" проблемы. "Настоящие" - это ваши, а остальные - ненастоящие? В "Настоящих" надо обязательно залезать в java.util.concurrent?

Nikita> С/C++ - низкоуровневые не-managed языки, они и должны оперировать низкоуровневыми примитивами. Тут как раз всё нормально.

Вам кажется так, как минимум комитету кажется иначе.

Nikita> Ещё раз напоминаю: большинство платформ обеспечивают поддержку многопоточности для C++ как со стороны компиляторов, так и со стороны библиотек, и во вполне нормальной форме, не особо хуже Java.

Что значит "поддержка со стороны компиляторов" в данном случае?

Сергей-4030>> Как бы мала ни была разница, а суровая реальность такова, что сейчас сложные проекты на C++ не делаются вовсе.
Nikita> Вы заблуждаетесь. Я могу назвать достаточное количество сложных проектов на C++ из всевозможных областей, включая военную.

Исключения есть. Немногочисленные.

Nikita> Я вообще-то к чему клоню: Вы вместо флейма, лучше бы предложили свой код, где действительно видны все/большинство преимуществ Java :cool:

На таком материале все/большинство преимущества Java не нужны. Тем более, что в данном случае я озаботился вопросами оптимизации на уровне, совершенно ненужном для большинства приложений. И вредном для читаемости/поддерживаемости кода.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Kernel3> ИМХО, слишком сильное заявление. Статистика какая-нибудь по этому поводу доступна (Гугл не предлагать :F )?

Tiobe тоже не катит? :)
 
+
-
edit
 

Balancer

администратор
★★★★☆
Nikita> Я вообще-то к чему клоню: Вы вместо флейма, лучше бы предложили свой код, где действительно видны все/большинство преимуществ Java :cool:

Преимущества Java не в коде. А в системе.
 
+
-
edit
 

V.Stepan

аксакал
★☆
anonymous_lor>> зачем ? ...
Nikita> А неважно. Факт в том, что Java автоматически всё это гарантирует. А C/C++ - нет.
Не хочу влазить в спор "плюсы vs ява" (не любитель ни одной, ни другой платформы :) ), просто замечу старую, избитую истину: "дай дураку стеклянный фуй, так или разобьёт, или потеряет". Столкнулся, например, с многолетним Java-проектом (начинали его ещё на 1.1.4 и до сих пор, кстати, не закончен - ой, действительно многолетний :D ), в котором изначально выбор Java объяснялся кучей удобств вообще, и кросс-платформенностью в частности.... На текущий момент Java-клиенты могут работать только под виндой.

Balancer>Преимущества Java не в коде. А в системе.
ИМХО, преимущество в первую очередь в голове (сорри за банальность).
Положа руку на серде - ну неужели ни разу не встречал:
1) отличные Java-проекты?
2) убогие Java-проекты?
3) отличные C/C++-проекты?
4) убогие C/C++-проекты?
"Класс – это исключение случайностей"  
+
-
edit
 

Kernel3

аксакал

Kernel3>> ИМХО, слишком сильное заявление. Статистика какая-нибудь по этому поводу доступна (Гугл не предлагать :F )?
Balancer> Tiobe тоже не катит? :)
Конечно, нет :P Там про сложность (что бы это не значило) проектов ни слова :)
Broken Windows® cures my ills and makes me feel alright... ©  
+
-
edit
 

Nikita

аксакал

Kernel3> А что, по-вашему, есть настоящие проблемы параллелизма? Это не подколка, просто интересно стало :)

Пожалуйста.

Многоядерный процессор, положим э-э-э... 64 ядра, для начала. Архитектура, разумеется, tile'овая. Каждое ядро очень простая штука: ALU, FPU, немного локальной памяти, роутер/свитч, ничего лишнего. Tile'ы соединены между собой. Простейший вариант - сетка 8х8. Но, разумеется, возможны и более сложные топологии: трёхмерные и т.д. Благодаря роутерам/свитчам, каждое ядро может устанавливать соединения типа точка-точка и обмениваться данными с любым другим.

Как загрузить такую штуку на полную катушку и при этом эффективно ? Допустим для задачи блочного умножения матриц ? Когда количество логических потоков в алгоритме плавает в зависимости от шага ? А ежели у нас параллельно на этой штуке запущен пяток виртуальных машин ? Да ещё и виртуализация приоритизированная ? То бишь с постоянно меняющимся количеством ядер на ВМ в зависимости от условий ? И нужно на ходу перестраивать расклад алгоритма ? Как Вы будете всё это добро на thread'ах программить ???

*Описана реальная железка. Из того чтобы доступно в быту: Cell практически такой и есть. Более того, подобные девайсы станут мэйнстримом в ближайшие лет 5-7, бо Intel копает именно сюда (см. Intel Tera-scale Computing Research Program)
Учитесь читать.  
US Сергей-4030 #18.07.2008 22:33  @Nikita#18.07.2008 22:24
+
-
edit
 

Сергей-4030

исключающий третье
★☆
админ. бан
Nikita> Многоядерный процессор, положим э-э-э... 64 ядра, для начала. Архитектура, разумеется, tile'овая. Каждое ядро очень простая штука: ALU, FPU, немного локальной памяти, роутер/свитч, ничего лишнего. Tile'ы соединены между собой. Простейший вариант - сетка 8х8. Но, разумеется, возможны и более сложные топологии: трёхмерные и т.д. Благодаря роутерам/свитчам, каждое ядро может устанавливать соединения типа точка-точка и обмениваться данными с любым другим.

Вы описываете "железные" проблемы. Все это интересно, но не в данном контексте.
 
US Сергей-4030 #18.07.2008 22:36  @Nikita#18.07.2008 22:24
+
-
edit
 

Сергей-4030

исключающий третье
★☆
админ. бан
Nikita> А ежели у нас параллельно на этой штуке запущен пяток виртуальных машин ? Да ещё и виртуализация приоритизированная ? То бишь с постоянно меняющимся количеством ядер на ВМ в зависимости от условий ? И нужно на ходу перестраивать расклад алгоритма ? Как Вы будете всё это добро на thread'ах программить ???

Да вот так, не моргнув глазом. Не будт достаточно оптимально - значит надо попробовать добавить вычислительной мощности, ибо она дешевле. Если не поможет - тогда оптимизировать. В любом случае, это есть частная проблема.
 
NO Balancer #18.07.2008 22:47  @V.Stepan#18.07.2008 20:31
+
-
edit
 

Balancer

администратор
★★★★☆
V.Stepan> Положа руку на серде - ну неужели ни разу не встречал:

На самом деле всё проще. Я давно для оценки уровня языка не смотрю на качество проектов на нём. Корреляция тут убедительная отсутствует.
 

Nikita

аксакал

sxam> Nikita, не понял, как yield return помогает с "асинхронным I/O"?

Ух ты, один человек уловил смысл сказанного!!! :cool: Спасибо!

Механизм поддержки написания итераторов в C# относится к разряду "синтаксического сахара". То бишь мы ваяем какой-то очень простой код, а за кадром происходит жуткий разврат: прямо в MSIL генерится куча каких-то классов, методов, всяческого оборачивающего кода и т.д.

В нашем случае процесс выглядит примерно так: генерится код для сохранения/восстановления контекста нашего метода - локальные переменные, данные для поддержки наших using/try/catch/finally; генерится машина состояний, для отслеживания на каком yield return'е мы сейчас находимся; генерится Dispose() для поддержки using/try/catch/finally (кстати, распространённая грабля; когда итератор берут не foreach/using, а "руками", и забывают что он IDisposable)

Что получается в итоге ? Каждый промежуток между yield'ами работает как отдельный метод, состояние перед выходом запоминается. Мы можем последовательно вызывать MoveNext() из разных потоков, и будет получаться, что каждый кусочек между yield return'ами работает в разных(!) потоках, но код в итераторе остаётся (на вид) обычным методом, и при этом сохраняет(!) поддержку всех лучших моментов C# - using/try/catch/finally!!!

А ведь именно это нам и нужно для нормального использования асинхронного I/O!!! Чтобы код выглядел также как и всегда, поддерживал using/try/catch/finally, но в реале дёргался кусками из разных потоков thread-пула обрабатывающих callback'и соответствующих асинхронных вызовов I/O.

В итоге мы получаем следующее (пример Рихтера):

code text
  1. private static IEnumerator<Int32> HtmlToFile(AsyncEnumerator ae,
  2.    String url, String file) {
  3.  
  4.    // Issue asynchronous web request operation
  5.    WebRequest webRequest = WebRequest.Create(url);
  6.    webRequest.BeginGetResponse(ae.End(), null);
  7.    yield return 1;
  8.  
  9.    WebResponse webResponse;
  10.    try {
  11.       webResponse = webRequest.EndGetResponse(ae.DequeueAsyncResult());
  12.    }
  13.    catch (WebException e) {
  14.       Console.WriteLine("Failed to contact server: {0}", e.Message);
  15.       yield break;
  16.    }
  17.  
  18.    using (webResponse) {
  19.       Stream webResponseStream = webResponse.GetResponseStream();
  20.  
  21.       // Read the stream data and write it to a file in 1KB chunks
  22.       Byte[] data = new Byte[1024];
  23.       using (FileStream fs = new FileStream(file, FileMode.Create,
  24.          FileAccess.Write, FileShare.None, data.Length,
  25.          FileOptions.Asynchronous)) {
  26.  
  27.          // See support.microsoft.com/kb/156932
  28.          fs.SetLength(webResponse.ContentLength);
  29.  
  30.          while (true) {
  31.             // Issue asynchronous web response stream read operation
  32.             webResponseStream.BeginRead(data, 0, data.Length,
  33.                ae.End(), null);
  34.             yield return 1;
  35.  
  36.             // Get result of web response stream read operation
  37.             Int32 bytesRead = webResponseStream.EndRead(
  38.                ae.DequeueAsyncResult());
  39.             if (bytesRead == 0) break; // Stream end: close file & exit
  40.  
  41.             // Issue asynchronous file write operation
  42.             fs.BeginWrite(data, 0, bytesRead, ae.End(), null);
  43.             yield return 1;
  44.  
  45.             // Get result of file write operation
  46.             fs.EndWrite(ae.DequeueAsyncResult());
  47.          }
  48.       }
  49.    }
  50. }


А вызывать вот так:

code text
  1. AsyncEnumerator ae = new AsyncEnumerator();
  2. ae.Execute(HtmlToFile(
  3.   ae,
  4.   "http://www.Wintellect.com/",
  5.   "LocalFile.html"));


Каждый yield return вызывает ожидание завершения соответствующих I/O операций запущенных в очередном "кусочке". Возвращает yield return количество запущенных операций, в нашем случае мы по одной на "кусочек" порождаем. Далее AsyncEnumerator опять дёргает MoveNext()...

Вызов можно и упростить даже, но это уже мелочи.

Надеюсь что-то понятно :D Рихтер пишет лучше меня, поэтому почитайте http://msdn.microsoft.com/en-us/magazine/cc546608.aspx
Учитесь читать.  
RU Nikita #18.07.2008 23:34  @Сергей-4030#18.07.2008 18:11
+
-
edit
 

Nikita

аксакал

Сергей-4030> В "Настоящих" надо обязательно залезать в java.util.concurrent?

Э-э-э... А как Вы без java.util.concurrent вообще живёте-то ??? Минимально приличная поддержка многопоточности в приложении мгновенно вызывает потребности как минимум в элементарных interlocked операциях и оптимизированных lock'ах (хотя бы примитивных read-write). Это must have вещи, которые до появления java.util.concurrent приходилось руками писать.

Сергей-4030> Вам кажется так, как минимум комитету кажется иначе.

Вы не поняли. Я про то и толкую: C/C++ потоки нужны. Вопрос только в том, как (и вообще можно ли) сделать их модель универсальной ?

Сергей-4030> Что значит "поддержка со стороны компиляторов" в данном случае?

"Ну Вы, блин, даёте" (с) Генерал

То и значит. Многопоточный код должен генериться несколько по-иному. Далеко не все оптимизации пригодные для однопоточного приложения годятся для многопоточного случая. Некоторые семантические конструкции также должны генериться по-другому. Связано это с изменением модели памяти, бо у нас теперь появляются другие потоки, которые (ежели ничего не предпринимать) могут видеть все промежуточные изменения данных, например.

Ну а для случая OpenMP, компилятор так и вообще целые пачки специальных #pragma обрабатывает, и весьма навороченно.

Сергей-4030> Исключения есть. Немногочисленные.

Это не исключения. Это вполне существенная часть рынка. Для начала посмотрите на продукцию Microsoft, например. Сколько там натива C++'ного, а сколько .NET'а ?

Сергей-4030> На таком материале все/большинство преимущества Java не нужны.

Не уверен, не уверен...
Учитесь читать.  
RU Nikita #18.07.2008 23:40  @Сергей-4030#18.07.2008 22:33
+
-
edit
 

Nikita

аксакал

Сергей-4030> Вы описываете "железные" проблемы.

Ничего подобного. Это 100% проблемы ПО. Такие железки уже стояли бы у нас на столах, если бы мы умели их нормально программировать. Пока же они занимают только нишу специализированных молотилок: GPU, сетевое оборудование и т.п.
Учитесь читать.  
US Сергей-4030 #18.07.2008 23:45  @Nikita#18.07.2008 23:34
+
-
edit
 

Сергей-4030

исключающий третье
★☆
админ. бан
Сергей-4030>> В "Настоящих" надо обязательно залезать в java.util.concurrent?
Nikita> Э-э-э... А как Вы без java.util.concurrent вообще живёте-то ??? Минимально приличная поддержка многопоточности в приложении мгновенно вызывает потребности как минимум в элементарных interlocked операциях и оптимизированных lock'ах (хотя бы примитивных read-write). Это must have вещи, которые до появления java.util.concurrent приходилось руками писать.

Мгновенно? Практика вас благополучно опровергает. Вполне благополучно во многих и многих приложениях та оптимизация, которая вам кажется абсолютно необходимой попросту не нужна.

Сергей-4030>> Вам кажется так, как минимум комитету кажется иначе.
Nikita> Вы не поняли. Я про то и толкую: C/C++ потоки нужны. Вопрос только в том, как (и вообще можно ли) сделать их модель универсальной ?

А какие основания сомневаться?

Сергей-4030>> Что значит "поддержка со стороны компиляторов" в данном случае?
Nikita> "Ну Вы, блин, даёте" (с) Генерал
Nikita> То и значит. Многопоточный код должен генериться несколько по-иному. Далеко не все оптимизации пригодные для однопоточного приложения годятся для многопоточного случая. Некоторые семантические конструкции также должны генериться по-другому. Связано это с изменением модели памяти, бо у нас теперь появляются другие потоки, которые (ежели ничего не предпринимать) могут видеть все промежуточные изменения данных, например.

Но тем не менее из сишного кода сишному компилятору неизвестно, что это код предназначен для параллельного исполнения.


Сергей-4030>> Исключения есть. Немногочисленные.
Nikita> Это не исключения. Это вполне существенная часть рынка. Для начала посмотрите на продукцию Microsoft, например. Сколько там натива C++'ного, а сколько .NET'а ?

Ага. Майкрософт, конечно, большой. Но в процентах ко всей индустрии ПО - совсем не так уж.

Сергей-4030>> На таком материале все/большинство преимущества Java не нужны.
Nikita> Не уверен, не уверен...

Ну тогда укажите, что вам казалось бы полезным. Принимая во внимание необходимость оптимизации по скорости. Дабы было о чем говорить. java.util.concurrent?
 
+
-
edit
 

Balancer

администратор
★★★★☆
Nikita> Э-э-э... А как Вы без java.util.concurrent вообще живёте-то ??

Ну, мы, например, очень давно отказались от j.u.c в пользу javolution. Очень уж у concurrent.HashTable оверхед на залочках большой :)
 
RU Nikita #19.07.2008 01:10  @Сергей-4030#18.07.2008 23:45
+
-
edit
 

Nikita

аксакал

Сергей-4030> Мгновенно? Практика вас благополучно опровергает.

С точностью до наоборот. Практика добавила java.util.concurent в стандартную библиотеку.

Сергей-4030> Вполне благополучно во многих и многих приложениях та оптимизация, которая вам кажется абсолютно необходимой попросту не нужна.

Значит им и многопоточность не нужна. Всё очень просто.

Сергей-4030> А какие основания сомневаться?

Читайте переписку комитета, публикации его участников... То что уже 2008 год на дворе, а нового стандарта до сих пор нет это ведь не просто так...

Сергей-4030> Но тем не менее из сишного кода сишному компилятору неизвестно, что это код предназначен для параллельного исполнения.

Неправда. В случае OpenMP #pragma как раз именно способ расширения языка. И при этом во многих случаях даже совместимость получается сохранить. Кто не понимает OpenMP, тот получит обычный последовательный код.

Сергей-4030> Ага. Майкрософт, конечно, большой. Но в процентах ко всей индустрии ПО - совсем не так уж.

Он настолько большой, что одно его слово может всю индустрию развернуть. Так что не надо "ля-ля", пожалуйста. Ваше утверждение - ложно.

Сергей-4030> Ну тогда укажите, что вам казалось бы полезным. Принимая во внимание необходимость оптимизации по скорости. Дабы было о чем говорить. java.util.concurrent?

java.util.concurrent это где-то в конце самом. Я бы начал с дизайна приложения. И с методологии разработки...
Учитесь читать.  

sxam

старожил

sxam>> Nikita, не понял, как yield return помогает с "асинхронным I/O"?
Nikita> ..
Nikita> Надеюсь что-то понятно :D Рихтер пишет лучше меня, поэтому почитайте http://msdn.microsoft.com/en-us/magazine/cc546608.aspx

Спасибо! Завтра поторможу немного, надеюсь пойму.
 
+
-
edit
 

Nikita

аксакал

Balancer> Ну, мы, например, очень давно отказались от j.u.c в пользу javolution.

Как пакет зовётся это уже неважно, важно что он есть и нужен.

Balancer> Очень уж у concurrent.HashTable оверхед на залочках большой :)

Ничего не понял. java.util.concurrent.ConcurrentHashMap на чтение не блокируется. А количество потоков способных без блокировки одновременно работать на запись управляется соответствующим параметром.
Учитесь читать.  
US Сергей-4030 #19.07.2008 03:06  @Nikita#19.07.2008 01:10
+
-
edit
 

Сергей-4030

исключающий третье
★☆
админ. бан
Сергей-4030>> Мгновенно? Практика вас благополучно опровергает.
Nikita> С точностью до наоборот. Практика добавила java.util.concurent в стандартную библиотеку.
Сергей-4030>> Вполне благополучно во многих и многих приложениях та оптимизация, которая вам кажется абсолютно необходимой попросту не нужна.
Nikita> Значит им и многопоточность не нужна. Всё очень просто.

Ну да. Если что-то ходит, как утка и крякает, как утка, но кажется Никите слоном - значит, это слон.

Nikita> Неправда. В случае OpenMP #pragma как раз именно способ расширения языка.

Ах препроцессор, как способ расширения языка...

Nikita> Он настолько большой, что одно его слово может всю индустрию развернуть. Так что не надо "ля-ля", пожалуйста. Ваше утверждение - ложно.

Как бы то ни было, а доходы Майкрософт на фоне доходов всей отрасли - скромны. Соответственно и ее проекты есть только малая часть всех проектов.

Сергей-4030>> Ну тогда укажите, что вам казалось бы полезным. Принимая во внимание необходимость оптимизации по скорости. Дабы было о чем говорить. java.util.concurrent?
Nikita> java.util.concurrent это где-то в конце самом. Я бы начал с дизайна приложения. И с методологии разработки...

Ну, покажите класс, за чем дело стало?
 
+
-
edit
 

Balancer

администратор
★★★★☆
Nikita> Ничего не понял. java.util.concurrent.ConcurrentHashMap на чтение не блокируется.

Во-первых, у нас в проекте параллельных модификаций хэш-таблиц (а также списков) не меньше, чем чтений, во-вторых, и на параллельном чтении ConcurrentHashTable у нас был медленнее, чем FastTable.

А так - параллельная работа с объектами требует особых объектов же, но при это м трудно назывыть ConcurrentHashMap отдельным пакетом, так как он входит в стандартную библиотеку.
 
RU anonymous_lor #19.07.2008 11:45  @Nikita#18.07.2008 17:32
+
-
edit
 

anonymous_lor

новичок

Nikita> Вы пришли со своей ASN.1 библиотекой к очередному заказчику, и он Вам выдал 6-битный кастомный встраиваемый криптопроцессор и соответствующий C/C++ кросскомпилер для него. Ну и как Вы думаете, перенеслась ? :cool:

вот вы это все зачем придумали ? ... я говорил про конкретную задачу которую решали в этой ветке ...

Nikita> А неважно. Факт в том, что Java автоматически всё это гарантирует. А C/C++ - нет.

тоесть просто ради того чтобы было, а не чтоб пользоваться ...

Nikita> И на каком-нибудь дохлом мобильном телефоне, пока Вы будете париться с его 16-ти разрядным (а может даже и с 8-ми :D ) процем, я на J2ME буду спокойно работать без заморочек :cool:

вот опять что-то напридумывали ... непонятно зачем ...
 
1 7 8 9 10 11 29

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru