» Вопросы по программированию на C/С++

veronica b

Цитата:

Мне раз пришлось программу, написанную на С++ перевести на Си. Были только классы, которые я заменил на структуры. Программа на Си работала примерно на 5% быстрее чем Си с плюсами. Иногда, редко, но эти прценты бывают критичны!

Не показательно. Значит программа была написана именно на С без использования всех особенностей С++ - шаблонов, исключений и т.д. Я имел в виду именно это.
Qraizer

Цитата:

Если не чувствуешь, что чего-то не хватает, и удобен в использовании, то просто "хорош" подходящий термин. "В сравнении с..." потоками, объектами синхронизации, API безопасности, названия функций и структур (folk() мне лично ничего не говорит, а CreateProcess() в документировании ИМХО вообще не нуждается)

Ну во-первых, не folk, а fork. В английском это слово означает ветвление, что, кстати, хорошо отражает его значение. ИМХО эта функция API UNIX как раз и является той изюминкой, которую "забыли" перенести в винды увлекшись многопоточностью. Мне этот (не скажу какой) createProcess кучу крови испортил, когда для связи двух процессов по каналу приходилось писать строк 150-200 очень не очевидного кода.
Согласен, что в UNIX набор вызовов ОС очень мнемоничен, но через некоторое время (после изучения определенного набора вызовов) это перестает мешать. В то же время на UNIX набор вызовов гораздо лучше систематизирован, в отличие от виндов. Но это уже совсем другая тема.
Собственно из своего опыта я и пытался понять, чем же так "хорош" WinAPI. Я, как человек испорченный UNIX, никак не могу этого понять. Не, что API есть и он достаточно полон - нет вопросов, но вот его состав...

Qraizer

Цитата:

Разнобой - в чём? Я что-то не понял...

Хотя бы в том, что ошибки в некоторых функциях (например, GetVersion, на другие указывал Рихтер). Да и чувствуется, что в своё время шло соперничество между командами разработчиков Win9x и Windows NT.


Цитата:

Просто Vista уже его держит на уровне экспорта своего ядра

Это точная информация? Хотя не верить вам вроде нет оснований).


Цитата:

Тады давайте перейдём в соответствующий топик

Надо бы, да вот тут обсуждение смешанное идёт.

veronica b

Цитата:

В программировании на С++ нет оффтопа, нет мелочей, там все важно. У меня было не раз, что беседа, как казалось, не в тему, дает шикарный резуьтат именно в программировании на С++!

Просто есть специальный топик под названием "С++ и WinAPI".

Mickey_from_nsk

Цитата:

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

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

Цитата:

Ну во-первых, не folk, а fork. В английском это слово означает ветвление, что, кстати, хорошо отражает его значение. ИМХО эта функция API UNIX как раз и является той изюминкой, которую "забыли" перенести в винды увлекшись многопоточностью.

Тут вы ошибаетесь. В Win32 API есть функция, которая моделирует fork. Как было написаннов хелпе специально для спецов API UNIX, что бы помочь перейти на Win32 API.

Qraizer

Цитата:

Я в обычной практике частенько юзаю эти самые "сложные" вещи.

смотря как : одно дело использовать boost другое дело его писать

Цитата:

Тут видимо дело не в "сложности", а в привычке.

Это уж точно, но тем не менее когда я прочитал александреску, то был сильно удивлен - как-то не задумывался, что такое можно сделать на с++ да и простым это мне не показалось

TeXpert
Ну чтож, я рад!
И так, что бы приступить к самой работе надо прояснить конечную цель, а именно: мы будем добиваться от программы того что она будет иметь вшитую в её бинарник dll, которая при запуске программы загрузиться в систему и останеца там навеки?

WiseAlex
Читал оглавленеи, предисловия, по диаганали просмотрел несколько глав, и понял что мне доэтого ещё учиться, учиться и ещё раз учиться.
Жаль что это пособие не оказалось полезным для вас (Можно его так назвать?), но всё таки хочу заметить что идеи, даже не очень близкии к самому языку, всё же благо. Почему? Потому что реализовать лучшую идею какого либо языка в С++ значит улутшить С++, хотя бы до уровня того языка, откуда была взята идея, что собственно и было вложенно в язык путём его расширяемости. Что касательно не дочётов и ошибок это несомненно минус автору (Да и мне в какой то степени тоже).
Что ж, аксиома о том что по конкретной теме надо смотреть не в энциклопедии, а в компетентном источнике, верна и здесь, но вот без этого пособия, я и мысли бы не допустил о таких возможностях. Если говорить о книге в обшем и не придераться к орфографии то мы будем спорить о вкусах, ведь для вас эта книга может быть водой на киселе, а для меня бесценным фолиантом.
Кстати! Можно поинтересоваться в чём ошибся автор: в самих идеях или в реализации кода на С++, дабы не повторить его ошибок?

TeXpert


Цитата:

Просто есть специальный топик под названием "С++ и WinAPI".

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

veronica b


Цитата:

В программировании на С++ нет оффтопа, нет мелочей, там все важно. У меня было не раз, что беседа, как казалось, не в тему, дает шикарный резуьтат именно в программировании на С++!

Обсалютно согласен. Плох то, кто пренебрегает мелочами или делает их делает их из всего.

FMeat

Цитата:

...dll, которая при запуске программы загрузиться в систему и останеца там навеки?

В вашей власти её загрузить/выгрузить, когда вам вздумается.


Цитата:

Всё бы так просто!

Так я сам чуть выше ещё кое-что отметил.

FMeat

Цитата:

Можно поинтересоваться в чём ошибся автор:

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

veronica b

Цитата:

А мне кажется, что вы сделали достаточно сложные вещи и зря бросили. Так что вам не понравилось. А на чем вы сейчас пишите программы?

Я под Линуксом работаю. Хотя, признаться, тесно с его API не общался. На мой взгляд, в линуксе есть стремление к минимализму, а в винде к раздутой функциональности с ее различными варинатами функций, и кучей заумных путей, с помощью которых можно сделать одно и то же. На юниксе вызов какого-нибудь системного метода выглядит так:
dothis(param),
а в WinAPI так:
MakeThisWonderfulThingEx(lpcstr, handle1, descriptor2, someInStructure, someOut Structure, и еще n параметров).
Ну это я конечно гипертрофированно и с иронией изображаю...
К тому же нужно лазить по MSDN и смотреть, на кой фиг нужны handle1 и descriptor2, и как их доставать; как должна выглядеть структура someInStructure, и , какое поле мне нужно из someOutStructure. Вот это мое ощущение от WinAPI.

Подозреваю, что если бы пришлось долгое время на нем работать, если бы я запомнил, что где искать в MSDN, чтобы не искать там каждую вещь по пол-часа, тоже бы, наверное, полюбил бы...
Qraizer
Цитата:

GUI однозначно не трогаем, ибо на API его рисовать - это не только в Win32, но и где угодно будет напрягать. Однако всё равно не могу сказать, что GUI в Win32 API плохо спроектирован.

Согласен. GUI библиотека должна быть объектно-ориентированной по-любому. (Я бы может и не стал так четко это утверждать, если бы не пописал GUI на Java-SWING). API - это база для нее.

Нда, что-то все таки действительно Оффтопом попахивает это все.

Ух. Без цитирования, а то пол поста цитаты займут.
Mickey_from_nsk
fork(), конечно. Взглючил. Вот только с переводом накладочка - так перевести можно ещё с пяточек имён функций. Если б кто объяснил, почему fork, а не, например, rebirn или там dptsk, а заодно так ещё и поделился опытом приобретения навыков по расшифровке смысла имён таких функций... Мы можем привыкнуть к мнемоничности, но может быть лучше сэкономить на комментах?
Чтобы связать два процесса, есть более приятные методы, а на предмет неочевидности - просто без комментавиев: по мне, так вполне всё очевидно пишется. Видимо это дело привычки к архитектуре, т.е. субъективно ощущается. И CreateProcess() тоже изумителен, не в пример spawn().
boost не так уж сложно писать. Гораздо сложнее сделать его переносимым с учётом глюков и фичей всех компиляторов. Но тут и STLPort вспомнить можно.
Вот-вот, именно в привычке, как я и сказал. Александреску жжёт однозначно. Причём и в буквальном смысле - я брюки в курилке прожёг, когда его читал. Собственно, с его книги и началось моё сегодняшнее отношение к шаблонам, а "привык" я к ним примерно через год.
TeXpert
Насчёт ошибок - не знаю, о чём это. Они либо исправляются, либо являются наследием, соблюдать которое нужно из соображений обратной совместимости. К слову сказать, в C++ тоже немало такого, что следовало бы исключить или исправить, да нельзя.
Верить мне не обязательно - это утверждение Microsoft, я все лишь выразил его другими словами.
veronica b
Честно говоря, я впервые слышу о полной эмуляции fork-а в Wind-ах.
Вообще же, если Mickey_from_nsk или SaDFromSpb найдут время объяснить, почему она так любима, то я изменю своё мнение по этому вопросу, но мне кажется, что эта функция вообще-то лишняя (хотя не спорю, при случае удобная), т.к. её функциональность мне кажется малополезной. Ведь есть же <setjmp.h>, но кто им сейчас пользуется, если есть эксепшны. Не, реально просвятите меня, что в ней такого притягательного? Насколько мне в своё время говорили - эта функция есть наследие домультитридовой эпохи.
SaDFromSpb
Пути не заумные, а разные, для разных ситуаций эффективнее те или иные. А что, не заметно? Странно, мне казалось это очевидным...
Тогда уж в Linux-е - как dths(something), а в WinAPI даже в MSDN идти не надо, чтобы понять, что этот вызов делает, если эту функцию в первый раз в жизни видишь. Это также относится к хождению по MSDN в поисках смысла параметров. К тому же не стОит передёргивать: ни разу не видел, чтобы параметры были лишние. И если в аналоге у Linux-ов их меньше, то это означает либо меньшую функиональность, либо большую инкапсуляцию параметров в поля структуры something, заполнение которых отнюдь не уменьшит исходник. Ирония, конечно, у меня тоже присутствует...
Где что в MSDN лежит, запоминать не надо. Тут уже упонималась мнемоничность имён функций в unix-ах. Могу ответить встречно: поняв архитектуру и принципы построения WinAPI, всегда найдёшь нужную информацию с одной-трёх попыток. Ну, ладно, с пяти, если не знаешь, как называется функция или структура, т.к. с трёх попыток "подберёшь" её правильное имя (ещё немного иронии...)

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

Qraizer

Цитата:

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

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

Цитата:

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

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

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 не разгорятся с новой силой.

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

Qraizer
Похоже наш диалог таки сходится к консенсусу

Цитата:

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

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

прошу помочь мне. Срочно нужно решить задачку(напишу пока первую).

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

Заранее огромное спасибо.

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
Программу, которую вы просили, выложена в топике "Задачи по С++"
Удачи вам при здачи.

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

Qraizer
А что вообще за файберы? Процессы знаю, потоки(они же thread - нити) знаю. А файберы?

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

Добавлено:
SaDFromSpb
Ну, может быть они произносятся как "фиберы". В оригинале они fiber

Qraizer

Цитата:

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

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

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

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. По русски переводится как "волокно".

veronica b

Цитата:

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

Обычно так, но необязательно.

xdude

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

xdude
Зависит от компилятора, конечно, но, я думаю, связка delete - new и так, как правило, догадывается выделить память на том же месте, если это возможно.
Это проявляется даже в таких случаях:

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

short* pshort = new short[16];
cout << pshort << endl;

RedLord

Цитата:

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

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

Цитата:

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

Qraizer

Цитата:

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

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

З.Ы. : Ну не люблю я MS, не люблю!!! И ничего не могу с этим поделать... Вы уж меня простите!

Цитата:

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

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

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

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

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

Но поговаривают, что в новом стндарте потоки появятся. И то правда: нельзя же их игнорировать, когда уже не поддерживающих потоков операционных систем практически не осталось... К тому же в POSIX они вроде как уже стандартизованы...