Здравствуйте! Хочется спросить вот о чём, программируя в winapi чтобы считать строку, например, из Listbox нужно выделять массив зачастую довольно большого размера, что не всегда удобно и расточительно(на мой взгляд) из чего возникает вопрос, а возможно ли контейнеры С++ приспособить для этого, допустим istringstream или ostringstream(или что в этом роде) я пробовал, но у меня ничего не вышло. Возможно, кто-то уже задавался этим вопросом я даже в этом уверен что кто-то им задавался, если есть решения, не слишком геморное, то хотелось бы о нём узнать.
ты сможешь получить данные только так, как написано в API, тебе все равно придется создавать буфер, чтобы поместить туда данные, потом их этих данных можешь уже сделать объекты в C++ и почистить буфер из памяти, но его все равно выделять придется
Ежели строки в листбоксе - статика, можно наперед аллоцировать массив и без динамической аллокации обойтись передавая указатель на статик буфер в памятиче иначе да.. придется динамицировать
Думаю, что это уже чистой воды гемморой, если я правильно понял. Если я сейчас делаю так: Код (C++): const int MAX_SIZE = 1024; TCHAR szBuffer[MAX_SIZE]; SendMessage(hListbox, LB_GETTEXT, idx, (LPARAM)szBuffer); А хотелось бы, как то вот так: Код (C++): istringstream is; SendMessage(hListbox, LB_GETTEXT, idx, (LPARAM)is.str().c_str()); Вы же предлагаете, насколько я понял, делать так: Код (C++): LRESULT lenString = SendMessage(hListbox, LB_GETTEXTLEN, idx, 0L); TCHAR* szBuffer = new[lenString+1]; LRESULT len = SendMessage(hListbox, LB_GETTEXT, idx, (LPARAM)szBuffer); szBuffer[len] = '\0'; delete[] szBuffer; Но это же ресурсозатратно постоянно выделять и освобождать память. Можно создать самопальный буффер(точнее попытаться создать), но вот как работает сообщение LB_GETTEXT, как оно внутри считывает, как работает с памятью...
а как еще? все эти буферы это просто обертка с удобными методами для работы, внутри все равно память выделяется, просто жизненный цикл объекта легко контролируется. Если память на пару инструкций выделить, то ничего страшного не случится, можете ее кусками выделять, хоть по 1 байту, если ресурсы ограничены, но это будет работать очень медленно, надо выбирать, что важнее, скорость или место в памяти --- Сообщение объединено, 24 авг 2023 --- оно никак по сути и не работает, оно просто берет текст с окна и через strcpy копирует его в буфер на который указывает аргумент LPARAM
Это понятно, что память внутри всех этих объектов выделяется, но я же показал, что я бы хотел получить, просто не выделять под массивы память, которая будет не востребована. Короче говоря можно функцию написать, которая внутри будет это проделывать, так гораздо легче, чем писать буфер, который сможет работать с этими объектами winapi, к тому же не ясно, как это сделать. Тем более, если так, то тут без заранее созданного массива или выделенной памяти ничего не выйдет.
Добро пожаловать в реальный мир. Если хочешь держать все в С++ контейнерах, бери контейнер, который позволяет тебе выделить пустой буфер и передавай указатель на этот буфер вместе с его размером в соответствующую функцию. Типа как у std::vector есть reserve и &vector[0], или как там у вас Плюсовых хипстеров это называется... Ну или ты можешь поехать в Индию, стать аутсорсером мелкомягких и переписать им все апишки с Цэ на Плюсы.
чой-то ты совсем дурью страдаешь ну-ежли тебе так важен лишний кб озу/кэша - пиши консоли.. вин32 вполне добротная штука именно в плане экономии ресурсов и именно поэтому его писали сугубо сишечкой. глянь ту же нт 4.0
Спойлер С чего это вдруг я хипстер?! И как это сделать, если в параметрах указывается только буфер, размер буфера куда запихнуть прикажете, и причём тут vector тогда уж лучше использовать string, но это исключительно моё предположение. Для форматирования строк и прочих безобразий с символьными данными, насколько я знаю, в с++ предусмотрены istringstream, ostringstream. Уже мчусь, аж шуба заворачивается. Я бы попробовал написать что-то похожее на listbox исключительно в познавательных целях, но, пожалуй, это слишком для меня. --- Сообщение объединено, 25 авг 2023 --- Ага экономная... одно окно без всего под 30-50 Кб весит, очень экономно. А?!
https://en.wikipedia.org/wiki/Windows_NT_4.0 это размер стандартных либ, кои пихаються в приложуху.. можно собрать без них, но придётся прописывать свою либу для вызова тех же апишек + на аномальный экзешник могут агриться аверки - стоят ли 3-4кб того???
Т.е. объединить их, скажем, в структуру, так что ли? --- Сообщение объединено, 25 авг 2023 --- Ну не знаю, возможно, стоит. Стоит хотя бы для того чтобы узнать, что это за зверь такой "агриться", "аверки" Даже так..., и как это делается, никогда с таким не сталкивался. --- Сообщение объединено, 25 авг 2023 --- Там всё на буржуинском...
https://stackoverflow.com/questions/437685/reduce-windows-executable-size привыкай юзать/использовать аглицкий - сильно облегчает житуХУ агриться - сердиться, аверка - антивирус на плюсах пиши свой класс, кой может выделять буфер, можно прям систему управления памятью прописать. но в итоге у тебя будет оверхед (избыточное использование) по памяти + появятся весёлые ошибки.. к примеру, гонка потоков, использование убитого буфера, слишком малый буфер да прочая лабуда. короче, выигрыша по памяти и скорости едва ли получишь, а гемору получишь много
В современных реалиях, где картинка может весить по 5 мб, 30-50, даже 100 кб для ехе не так критично, разве нет? Главное чтобы не было веселых, трудно-улавливаемых ошибок.
Не понимаю, что непонятного. Объявил экземпляр класса, проинициализировал, выделив с его помощью буффер, передал буффер и размер в функцию, определил сколько получилось данных, обрезал буффер до длины данных, вернул куда тебе нужно.
ваще, коли уж пошла такая пьянка.. Код (C++): #include <iostream> void *buff(int size) { int *p = new int[size]; return p; } int main(int argc, char* argv[]){ int *p = (int*)buff(4); auto i = 15; p[i] = 7; int d = p[i]; printf("*p[%d]: %d", i, d); } вот она - настоящая динамика