Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по программированию на C/С++

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322

Открыть новую тему     Написать ответ в эту тему

Crazy_Shrike



Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Вопросы по программированию на C/С++

 
  • Справочники, книги
  • Выбор IDE (среды программирования)
     
    Постарайтесь дать как можно больше информации о возникшей проблеме - это в конце концов в ваших же интересах чтобы вам помогли.

    Решения конкретных задач собираются и обсуждаются в теме Задачи по C/С++ .

    Прежде чем просить помощи в задании...
    Если позарез надо и вы даже готовы заплатить

    Как правильно задавать вопросы, если вы хотите получить ответ.

    Полезные ссылки:
    C++(eng)

  • Всего записей: 241 | Зарегистр. 25-03-2004 | Отправлено: 13:37 06-05-2004 | Исправлено: AZJIO, 19:45 12-05-2014
    veronica b



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer

    Цитата:
    Честно говоря, я впервые слышу о полной эмуляции fork-а в Wind-ах.  

    Я попробую поискать, но помню что использовал в программе. Возьму Рихтера и буду искать.

    Цитата:
    Надёюсь, никого не обидел. Вообще-то я с самого начала предоставлял это всё как своё ИМХО.

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

    Всего записей: 504 | Зарегистр. 04-12-2006 | Отправлено: 09:22 19-01-2007
    Mickey_from_nsk

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer

    Цитата:
    Вот только с переводом накладочка - так перевести можно ещё с пяточек имён функций. Если б кто объяснил, почему fork, а не, например, rebirn или там dptsk, а заодно так ещё и поделился опытом приобретения навыков по расшифровке смысла имён таких функций... Мы можем привыкнуть к мнемоничности, но может быть лучше сэкономить на комментах?  

    Это - одна из немногих функций, которая не мнемонична. Просто fork - вилка, ветвление и т.д. И не надо различных spawnxxx

    Цитата:
    Чтобы связать два процесса, есть более приятные методы, а на предмет неочевидности - просто без комментавиев: по мне, так вполне всё очевидно пишется. Видимо это дело привычки к архитектуре, т.е. субъективно ощущается. И CreateProcess() тоже изумителен, не в пример spawn().  

    Я думаю, никто здесь не навязывает своего виденья крутости архитектуры. Собственно по этому я все еще пишу на эту тему. Серьезно, давненько ничего такого спокойного и толкового не было.
    Чем отличается CreateProcess от fork... Попытаюсь объяснить почему мне нравится fork и не нравится CreateProcess. Наверно потому, что в UNIX CreateProcess можно организовать путем последовательного вызова fork и exec, а в виндах обратное невозможно
    Виндовс ориентирован исключительно на многопоточность, это следует из всей архитектуры его вызовов - порождение нового процесса нужно только для вызова другого файла, раздвоить собственный процесс невозможно.
    Вцелом, я уже давно смирился с многопоточностью, научился ее использовать во благо, а не для создавания новых ошибок и ничего не имею против, но изредка возникают задачи, которые изящнее было бы решить многозадачностью. Ну не всегда надо шарить все пространство переменных и не все переменные можно запихать в стек. Кроме того, вопросы расшаривания (пардон за такой термин, но по русски он звучит еще корявее) дескрипторов как файлов, так и сокетов и др. устройств встают достаточно остро.
    Вобщем, как в MIB "А на самом деле - не спрашивайте почему я в нее выстрелил"
    Что же касается setjump - это вообще странная штука и насколько я помню, даже в юниксе ее использовать не рекомендуют, не говоря про С++

    Цитата:
    Пути не заумные, а разные, для разных ситуаций эффективнее те или иные. А что, не заметно? Странно, мне казалось это очевидным...  

    Слегка спорное замечание. Я, например, считаю 150 строк кода для организации обмена информацией по каналу сильно заумным способом. Хотя, наверно виндовс предлагает в этом случае делать обмен через Messages, но по ряду причин мне нужен был канал и перенаправление стандартного ввода-вывода.
    Кроме того, при переходе на виндовс я был удивлен тем "разнообразием" (хотя наверно без кавычек" функций АПИ, которые требуются чтобы создать тот или иной стрим (поток но не thread) в этой ОС в отличие от UNIX. Про WinSock тоже есть что порассказать...
    Честно говоря, кроме графики я не видел преимущества виндовс по сравнению с юникс. В графике - тоже не видел, поскольку XWindows освоить не успел.
     
    Теперь - по вопросу именования функций. Когда начинал осваивать С, меня всегда больше всего убивало шаманское слово stdio. Я его начал понимать только когда разобрался, что же оно означает. Но сразу после этого оно запомнилось и проблем далее не вызывало. То же самое с другими вызовами. Я понимаю, что dlopen для не совсем знающего о чем речь человека звучит хуже чем LoadLibrary, но (ИМХО) оно точнее, ибо в нем еще есть буковка d, которая говорит о том, что это - динамические библиотеки
    Согласен, что в виндовс названия функций немного точнее (CreateFile оставим для отдельного исследования), но в нем нет единого стандарта именования функций, вот все и изгаляются как могут. Особенно, как тут отмечалось, нравится суффикс Ex, который иногда говорит, что функция без него - устарела, а в других случаях - что в функции с ним больше параметров.
    Кстати про параметры. Как отмечалось выше, в юниксе существует минимализм в передаче параметров. Ну не видел я там АПИшных функций с количеством параметров больше 4 (Может видел, но забыл - напомните мне их). Зато WinAPI в этом радует. Мало того, что половина параметров - структуры, так и по 8-10 параметров для функции - не редкость. При этом половина может быть NULL
     
    К чему это я? А! Да!
    .NET Framework - новое слово в развитии API, которое было сказано в следствие того, что программисты из Microsoft сами задолбались уже писать на WinAPI. Я так думаю. И несмотря на новизну, оно не дотягивает до лаконичности UNIX.
     
    Ну и post scriptum. Сильно надеюсь, что Holy wars не разгорятся с новой силой.

    Всего записей: 636 | Зарегистр. 21-10-2002 | Отправлено: 11:18 19-01-2007
    Qraizer



    Advanced Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    Mickey_from_nsk
    Вполне конструктивно. И в духе ИМХО. Так что вполне признаю перечисленные претензии в адрес WinAPI. Я и не утверждал, что их быть не может. Впрочем, они меня, конечно, не убедили
    setjmp/longjmp везде не рекомендуются к применению. Их назначение - организация нелокальных переходов - сейчас гораздо "правильнее" осуществляется исключениями. Впрочем, их и использовали для того же, для чего сейчас используют исключения.
    Насчёт имён в С и С++ - залоговков, стандартных функций, стандартных переменных - чувствуется их unixовая ориентированность в прошлом. Возьмём С99 - для примера mbstowcs и wcstombs вполне подойдут; возьмём С++ - для демонстрации lexicographical_compare и set_symmetric_difference противоположной крайности. Любопытная тенденция, не правда ли?
    На предмет .NET свои мысли я как-то уже высказывал. Добавлю, что WinAPI - даже Win16 - всегда был объектным по духу. По крайней мере первые параметры GUIных и USERный функций это зачастую не что иное как this, подклассирование - это не что иное как полиморфизм, классы окон, объекты синхронизаций итп это сильно смахивает на имитацию наследования, и пр. В конце-концов MicroSoft-у надоело имитировать объектность с приватным наследованием, и они-таки решили это объектность сделать "по факту". Это опять-таки не официальная точно зрения, а моя, как... м-м-м, аналитика - так можно сказать? - ... в области архитектуры Win API.

    Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 13:16 19-01-2007
    Mickey_from_nsk

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer
    Похоже наш диалог таки сходится к консенсусу

    Цитата:
    Добавлю, что WinAPI - даже Win16 - всегда был объектным по духу. По крайней мере первые параметры GUIных и USERный функций это зачастую не что иное как this, подклассирование - это не что иное как полиморфизм, классы окон, объекты синхронизаций итп это сильно смахивает на имитацию наследования, и пр.

    Согласен с этим. Вообще плохо представляю как можно делать такие сложные системы как оконные интерфейсы вне объектно-ориентированного программирования.
    С другой стороны, работа с файлами в POSIX тоже может быть отнесена к этому В них handle вполне может рассматриваться как this. Так можно много объектов ОС подогнать под это определение.  
    Опятьжа. В любой мало мальски уважающей себя объектной библиотеке не бывает методов с 10 параметрами. Большинство параметров объекта реализуется как свойства (ну или геттеры/сеттеры) и при конструировании выставляются в значения по умолчанию. Видимо Microsoft ушел с этого пути потому что увидел своих более 600 (где-то видел такую цифру) системных вызовов и понял, что если делать еще и аксессоры, все забьют на такую ОС.
    Ну и по именам. Мне сильно становится жалко, что нет единого комитета, который бы давал рекомендации и проверял на соответствие им имен методов в С++. В результате каждая библиотека сильно зависит от фантазии своего разработчика и от скорости топтания клавиш его руками. В StdCLib это было видно, сейчас - нет.
    Ну и в качестве заключения по именам функций. Када разрабатывался UNIX и его stdlib? Правильно в 70-х. Какая была память в машинках тех лет? Правильно - никакая. Экономили каждый байт. Я не удивлюсь, что такие мнемонические имена - следствие экономии.

    Всего записей: 636 | Зарегистр. 21-10-2002 | Отправлено: 16:22 19-01-2007
    maina

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    прошу помочь мне. Срочно нужно решить задачку(напишу пока первую).
     
    Из входного потока вводится последовательность целых пятиразрядных чисел. Количество чисел в последовательности произвольно, но не превышает 100.  
    Сформировать новую последовательность, элементами которой являются числа исходной последовательности, цифры в которых записаны в обратном порядке. Недостающие нули (в за-писи пятиразрядных чисел) должны быть добавлены, лидирующие не значащие нули – удале-ны. Вывести в выходной поток исходную и выделенную последовательности.  
    Например, для последовательности:  
      12713      65         10816     2     17800  
    должны получить:  
    31721 56000 61801 20000 871
     
    Заранее огромное спасибо.

    Всего записей: 13 | Зарегистр. 17-01-2007 | Отправлено: 16:22 19-01-2007
    veronica b



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer

    Цитата:
    Честно говоря, я впервые слышу о полной эмуляции fork-а в Wind-ах.

    Вот нашел

    Цитата:
     
    CreateFiber
     
    The CreateFiber function allocates a fiber object, assigns it a stack, and sets up execution to begin at the specified start address, typically the fiber function. This function does not schedule the fiber.
     
    To specify both a commit and reserve stack size, use the CreateFiberEx function.
     
     
    LPVOID CreateFiber(
      SIZE_T dwStackSize,
      LPFIBER_START_ROUTINE lpStartAddress,
      LPVOID lpParameter
    );
     
    Parameters
    dwStackSize  
    [in] Initial size of the stack, in bytes. If this parameter is zero, the new fiber uses the default stack size for the executable. For more information, see Thread Stack Size.  
    lpStartAddress  
    [in] Pointer to the application-defined function to be executed by the fiber and represents the starting address of the fiber. Execution of the newly created fiber does not begin until another fiber calls the SwitchToFiber function with this address. For more information of the fiber callback function, see FiberProc.  
    lpParameter  
    [in] Pointer to a variable that is passed to the fiber. The fiber can retrieve this data by using the GetFiberData macro.  
    Return Values
    If the function succeeds, the return value is the address of the fiber.
     
    If the function fails, the return value is NULL. To get extended error information, call GetLastError.
     
    Remarks
    The number of fibers a process can create is limited by the available virtual memory. For example, if you create each fiber with 1 megabyte of reserved stack space, you can create at most 2028 fibers. If you reduce the default stack size by using the STACKSIZE statement in the module definition (.def) file or by using CreateFiberEx, you can create more fibers. However, your application will have better performance if you use an alternate strategy for processing requests instead of creating such a large number of fibers.
     
    Before a thread can schedule a fiber using the SwitchToFiber function, it must call the ConvertThreadToFiber function so there is a fiber associated with the thread.
     
    To compile an application that uses this function, define _WIN32_WINNT as 0x0400 or later. For more information, see Using the SDK Headers.
     
    Example Code  
    For an example, see Using Fibers.
     
    Requirements
    Client Requires Windows XP, Windows 2000 Professional, Windows NT Workstation 3.51 SP3 and later, Windows Me, or Windows 98.  
    Server Requires Windows Server 2003, Windows 2000 Server, or Windows NT Server 3.51 SP3 and later.  
    Header Declared in Winbase.h; include Windows.h.
     
    Library Link to Kernel32.lib.
     
    DLL Requires Kernel32.dll.  
     

     
     
     
     
    Добавлено:
    maina
    Программу, которую вы просили, выложена в топике "Задачи по С++"
    Удачи вам при здачи.

    Всего записей: 504 | Зарегистр. 04-12-2006 | Отправлено: 17:55 19-01-2007
    Qraizer



    Advanced Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    Стоп, а причём здесь файберы? То, что они реализованы в WinAPI, я в курсе, но речь шла о fork(). Или я чего-то не понимаю?

    Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 22:22 19-01-2007
    SaDFromSpb



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer
    А что вообще за файберы? Процессы знаю, потоки(они же thread - нити) знаю. А файберы?

    Всего записей: 209 | Зарегистр. 22-06-2004 | Отправлено: 22:36 19-01-2007
    Qraizer



    Advanced Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    Mickey_from_nsk
    Насчёт объектности. Это всё только подтверждает тезис о том, что чтобы программировать объектно, совсем не обязательно иметь язык (компилятор?), поддерживающий модель ООП. ООП - это технология, а как ею пользоваться - хоть на ассемблере - это проблемы программиста. Ну а если в тому же и язык её поддерживает, то совсем замечательно. Для программиста. Компилятор куда как более дисциплинирован в плане соответствия стандартам проектирования, чем человек . По модели ООП вообще многое спроектировано. Даже банальные C-потоки на основе fXXXX() функий - и то ей соответстуют, включая сокрытие реализации.
    Теперь наконец-то (?) мы получим по-настоящему объектный API. Я имею в виду .NET. Мне вот интересно, почему инициатива пришла от MS? Если бы POSIX-сообщество озаботилось этим пораньше, MS не была бы сейчас монополична в этом направлении развития архитектуры взаимодейтсвия ОС и приложений. Впрочем, это можно распространить также и на саму платформу .NET. Тем более, что со времени  презентации Java-ы идея буквально витала в воздухе. Всего-то оставалось расширить идею переносимости и независимости API от платформы с рамок, ограничивающих применение этой технологии в Web, на операционные системы.
    По именам. Это я просто подметил, и мне показалось любопытным совпадение тенденций. Ничего более я в виду не имел.
     
    Добавлено:
    SaDFromSpb
    Ну, может быть они произносятся как "фиберы". В оригинале они fiber

    Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 22:45 19-01-2007
    veronica b



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer

    Цитата:
    Стоп, а причём здесь файберы? То, что они реализованы в WinAPI, я в курсе, но речь шла о fork(). Или я чего-то не понимаю?

    Как я помню, а дело было в 2000 году, помоему у Рихтера было написано примерно так, для облегчения портирования програм с UNIXа на Windows для замены fork() и была создана эта функция. Если вы не верите и для вас это важно, то поробуйте перенести программу с  fork() на Windows используя файберы и потом без них.

    Всего записей: 504 | Зарегистр. 04-12-2006 | Отправлено: 22:47 19-01-2007
    xdude



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Товарищи, кто-то может мне подсказать, в C++ выделение памяти в куче происходит оператором new, насколько я знаю, и насколько могу догадываться, его аналог с С - malloc(). А вот перераспределить память чем можно? В С, например, я юзал realloc(), а в C++ что-то подобное есть?

    Всего записей: 481 | Зарегистр. 04-11-2004 | Отправлено: 00:25 20-01-2007
    veronica b



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    xdude
    В С++ оператора renew нет. Опеатор new предназначен в первую очередь для выделения памяти под объект, так как он взаимодействует с конструктором. например:

    Цитата:
     
                   ABC* ptrObj = new ABC(...);
     
                   ABC& refObj = *new  ABC(...);
     

    А в этой части кода, конечно использовать new можно и не будет никакой ошибки. Но если надо перераспределить память, то используйте сразу  malloc() или сalloc(), а потом, с чистой совестью, realloc(). Кстати, оператор new реализован через malloc().  

    Цитата:
     
        
                  char* ptr = new char[12];
     
                  ptr[0]  = 'a';
                  ptr[11] = 'c';
     
                  delete[] ptr;
     

     
    Qraizer
    Нашел описание в книге Рихтера "Windows для профессионалов", четвертое издание 2001 года, страница 303. По русски переводится как "волокно".
     

    Всего записей: 504 | Зарегистр. 04-12-2006 | Отправлено: 08:36 20-01-2007 | Исправлено: veronica b, 10:12 20-01-2007
    RedLord

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    veronica b

    Цитата:
    кстати, оператор new реализован через malloc().

     
    Обычно так, но необязательно.
     
    xdude
     
    реаллокирования  нет.  но в  стандартный аллокатор, вроде бы,  собираются  добавить  перераспределение.
    ИМХО:  можно использовать  STL-вектор

    Всего записей: 730 | Зарегистр. 05-03-2004 | Отправлено: 12:29 20-01-2007
    SaDFromSpb



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    xdude
    Зависит от компилятора, конечно, но, я думаю, связка delete - new и так, как правило, догадывается выделить память на том же месте, если это возможно.
    Это проявляется даже в таких случаях:

    Код:
        int* p = new int[8];    
        cout << p << endl;    
        delete[] p;
     
        short* pshort = new short[16];    
        cout << pshort << endl;
     

    Так что, видимо, оператор renew просто посчитали лишним по иделогоии.
     
     
    Добавлено:
    Просьба сообщить версию компилятора, если у кого-то адреса в обоих случаях не совпали =)
    Я это проделал на мелкосовтовском cl.

    Всего записей: 209 | Зарегистр. 22-06-2004 | Отправлено: 14:20 20-01-2007 | Исправлено: SaDFromSpb, 14:24 20-01-2007
    veronica b



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    RedLord

    Цитата:
    Обычно так, но необязательно

    Раньше так было, лично прверял, но в общем это совсем не важно. Если теперь есть STL, то любой его контейнер всегда, при необходимости проводит реаллокацию автоматически.
    SaDFromSpb

    Цитата:
        int* p = new int[8];      
        cout << p << endl;      
        delete[] p;  
        Сдесь поток отдает управление, в другом потоке происходит выделение памяти и   у     программиста начинается "весёлая" жизнь!
        short* pshort = new short[16];      
        cout << pshort << endl;
     
     

     

    Всего записей: 504 | Зарегистр. 04-12-2006 | Отправлено: 14:43 20-01-2007
    SaDFromSpb



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Qraizer

    Цитата:
    Мне вот интересно, почему инициатива пришла от MS? Если бы POSIX-сообщество озаботилось этим пораньше,

    Видимо, полностью объектно-ориентированный API им просто не нужен, так как за счет хорошего проектирования системы у них и с процедурными API проблем не возникает.
     
    З.Ы. : Ну не люблю я MS, не люблю!!! И ничего не могу с этим поделать...   Вы уж меня простите!

    Всего записей: 209 | Зарегистр. 22-06-2004 | Отправлено: 14:47 20-01-2007 | Исправлено: SaDFromSpb, 14:48 20-01-2007
    Qraizer



    Advanced Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

    Цитата:
    Видимо, полностью объектно-ориентированный API им просто не нужен, так как за счет хорошего проектирования системы у них и с процедурными API проблем не возникает.
    Так ведь вопрос не в нужности, а в идеологии. Если мне не нужен C++ stuff, я ж не буду из-за этого использовать plain-C компилятор. Моё недоумение связано с тем, что на дворе 21-й век, а API у ОС до сих пор функциональные, а не объектные. Вопрос вполне можно было поднять, хотя бы эктраполировав тенденции политики MS и приняв во внимание идею Java-ы. ИМХО мы имеем (вы имеете?) грубый политический просчёт. Когда речь идёт о борьбе за долю контроля над рынком ОС, нужно/ненужно уходит на второй план.
    Что-то сумбурно как-то получилось, но надеюсь, моя мысль освещена достаточно.

    Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 16:26 20-01-2007
    xdude



    Full Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Вопрос после обсуждения объектно-ориентированного API может показаться туповатым, но все же задам: в STL есть какие-то классы или темплейты классов для управления нитями (они же потоки, они же threads)? Или если не в STL, то хотя бы в стандартной библиотеке C? Или это уже чистейший API и зависит от конкретной системы?

    Всего записей: 481 | Зарегистр. 04-11-2004 | Отправлено: 19:37 20-01-2007
    TeXpert



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    xdude
    Насколько мне известно, в C++ есть что-то связанное а потоками, но а в стандартном C ничего такого нет. Поэтому, лучше для конкретной системы писать с помощью соответствующего API.

    ----------
    Майкудук, Пришахтинск не предлагать!:)
    А на Пирогова приходит снова весенний гомон...

    Всего записей: 3604 | Зарегистр. 08-02-2003 | Отправлено: 20:22 20-01-2007
    freeaccount

    Newbie
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    xdude
    Потоков в STL нету. STL - старая библиотека, которая создавалась в т.ч. для DOS, где о многопоточности речи не было. Так что управления потоками от нее ожидать не приходится.

    Всего записей: 9 | Зарегистр. 25-08-2006 | Отправлено: 20:23 20-01-2007 | Исправлено: freeaccount, 09:50 21-01-2007
    Открыть новую тему     Написать ответ в эту тему

    Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322

    Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по программированию на C/С++


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru