Можно и лямбду с this'ом, тока имей в виду, что некоторые котомордые тут в теме в примере накосячили. У Ворот в примере используется неявный захват this через "=". Но, это, во-первых, и раньше работало, а во-вторых, в стандарте 20 года скорее всего будет объявлено deprecated. Если реально проверять фичу 17-го стандарта, то надо *this передавать лямбде явно.
Прошу прощения, канешно, но я реально половину слов не догоняю, мои знания кончаются на Страуструпе, а он про такие восокоматерьяльные хрени тоже не знал тогда. Когда-нибуть я обязательно всё это всосу и попробую. (наерна)
Дед, есть хорошая статья про развитие лямбд в С++ от 11-го года и до 20-го. Она в двух частях, посмотри, если интересно. Там с оценками автора можно и поспорить, но по фактам я так сходу никаких особых ляпов не заметил - вполне качественно.
Когда-то, с подачи wdrakula, я писал, что если поставить в IDE 1.8.9 опцию С++17, то можно пользоваться разделителем разрядов чисел (например, писать 16'000'000 вместо трудночитаемого 16000000) и нормальными constexpr функциями, но, к сожалению, не поддерживаются "if constexpr" и, самое интересное - свёртки.
Поставил IDE 1.8.10, заметил, что там более свежий релиз GCC и полез смотреть как оно там.
Выяснил, что теперь и "if constexpr" и свёртки поддерживаются. Сейчас исследую как это реализовано (например, насколько эффективны свёртки), а также смотрю какие ещё вкусности появились.
Надо писать здесь о результатах и о том, как этими вкусностями пользоваться? А то, если это никому нафиг не сдалось, мне жаль пальцы об клавиши бить.
Забыл, что не зависимо от типа программы, настройки компилятора прописывает в винде 7 и выше по пути - C:\Users\User\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.1
)))
Ребята, подскажите пожалуйста, с чем связано то что при avr-gcc-7.2.0 виртуальные деструкторы работали, а на avr-gcc-7.3.0 ( точнее, с добавлением опции -std=gnu++1z ) пришлось дописывать delete(void * ptr, unsigned int) и deletep[(void * ptr, unsigned int) и что это за второй, не используемый параметр?
С тем, что их там нет, а они требуются, см. ISO/IEC 14882:2017 § 8.3.5 п.8, (стр. 128)
kokuam пишет:
что это за второй, не используемый параметр?
Размер. Нужен не всегда, но бывает. Тонкостей и подробностей там море, очень много описывать, лучше Вам почитать в оригинале.
Для начала общие сведения о том, как устроены аллокаторы (§ 6.7.4.1, стр.71) и деаллокаторы (§ 6.7.4.2, стр. 72). Там уже встречаются эти параметры и говорится о них.
Далее можно посмотреть требования к т.н. библиотекам поддержки языка в части выделения и освобождения памяти. Это § 21.6.2 (стр.493). Там всё описано предельно подробно.
Спасибо, почитал ISO/IEC 14882:2017 § 8.3.5 п.8, там ничего про второй интовый параметр нету.
Note: An implementat ion provides default definit ions of the global deallocat ion funct ions operat or delet e
for non-arrays ( 21 . 6 . 2 . 1 ) and operat or delet e[] for arrays (21 . 6 . 2 . 2) . A C++ program can provide alternat ive definitions of these funct ions (20 . 5 . 4 . 6) , and/or class- sp ecific versions (1 5 . 5) . — end note ]
Дальше уже по-лучше, и разумеется параметр д.б. не интовый а size_t, мелочь но стало тревожно.
Дайте пожалуйста ссылочку откуда вы взяли эти (delete(void * ptr, unsigned int) and delete[](void * ptr, unsigned int)) функции, хочется спросить/понять чем руководствовались авторы. Спасибо!
Ну, да, в этом разделе просто сказано, что функции обязаны быть и указаны разделы где подробнее. А подробности в других, Вы их тоже нашли.
size_t - правильно. В данном случае это как раз unsigned, так что всё правильно, но, наверное, лучше было size_t писать.
Насчёт "тревожно", Вы не разобрались откуда там что может взяться и что означает? Там идея такая, если при вызове аллокатора использовалось количество элементов, то это количество элементов нужно передать и деаллокатору. Но, поскольку здесь нет хитрых аллокаторов (смотрите на них - они все в том файле и все тривиальны), вот я и написал generic деаллокаторы (я их ниоткуда не брал). Нужно по синтаксису - на, кушай. Должно работать нормально. Напишите проверочный пример пример и проверьте, ну или я могу сам написать, только уж завтра.
void operator delete(void * ptr, unsigned int value){
Serial.print("singularDelete, value = ");
Serial.println(value);
free(ptr);
}
void operator delete[](void * ptr, unsigned int value){
Serial.print("multipleDelete, value = ");
Serial.println(value);
free(ptr);
}
и стало еще тревожнее, т.к. во втором параметре действительно передаются реальные размеры и они игнорируются.
Не понятно как free(ptr) и в случае родных операторов и в случае самодельных понимает что ей удалять?
Я проверил, при создании массива в куче перед нулевым элементом исправно записывается размер массива.
class A{
public:
uint8_t x;
uint8_t ballast[100]={0};
A(int value):x(value){};
A():x(125){};
inline static uint8_t z = 3; // to make sure we are in cpp-1z mode
~A(){Serial.println(" dTor ");};
};
void setup() {
Serial.begin(9600);
A* a = new A(1);
Serial.println(a->x + A::z); // to avoid warnings and possible optimization
delete a; // got " singularDelete, value = 101 "
A* aPtr = new A[3];
Serial.println( aPtr[0].x ); // to avoid warnings and possible optimization
delete []aPtr; // got multipleDelete, value = 305
}
void loop() {}
Занятно, что если не прописать деструктор, то самодельный delete[](...) вообще не вызывается
Дело в том, что размер известен из самого блока памяти (malloc там его помещает, а free читает). Нетривиальный деаллокатор нужен, если используется нетривиальный аллокатор, а здесь во всех аллокаторах используется простой malloc, ну так чего выпендриваться?
Чтобы совсем успокоиться, проверьте память (адрес начала кучи) перед созданием кучи объектов (в т.ч. и массивов объектов) и после их уничтожения. Увидите. что всё нормально.
Память я проверил, на разных сценариях сотни тысяч раз создавал-удалял, вроде всё ОК, но это-ж тестовые сценарии, в жизни всё по-другому складывается.
Меня смущал синтаксис delete vs delete[], Брюс Эккель Философия С++ гл 13. стр 412 пишет что эти команды работают по-разному. Я из этого делал вывод что при создании массива в куче сохраняется и его размер, а для "скалярных" типов - нет. А по тестам - оказалось, что и при создании в куче uint8_t - там тоже сохраняется ее размер. Исходников free & malloc я не нашел, хотя на www.nongnu.org/avr-libc/ есть нечто похожее.
По факту, получается, что в случае Arduino разницы между delete и delete[] нет и можно спать относительно спокойно :)
У меня есть, правда не самая свежая библиотека - avr-libc-1.8.1
/* Copyright (c) 2002, 2004, 2010 Joerg Wunsch
Copyright (c) 2010 Gerben van den Broeke
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
* Neither the name of the copyright holders nor the names of
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
*/
/* $Id: malloc.c 2149 2010-06-09 20:45:37Z joerg_wunsch $ */
#include <stdlib.h>
#include "sectionname.h"
#include "stdlib_private.h"
#ifdef MALLOC_TEST
char mymem[256];
#else
#include <avr/io.h>
#endif /* MALLOC_TEST */
/*
* Exported interface:
*
* When extending the data segment, the allocator will not try to go
* beyond the current stack limit, decreased by __malloc_margin bytes.
* Thus, all possible stack frames of interrupt routines that could
* interrupt the current function, plus all further nested function
* calls must not require more stack space, or they'll risk to collide
* with the data segment.
*/
/* May be changed by the user only before the first malloc() call. */
size_t __malloc_margin = 32;
char *__malloc_heap_start = &__heap_start;
char *__malloc_heap_end = &__heap_end;
char *__brkval;
struct __freelist *__flp;
ATTRIBUTE_CLIB_SECTION
void *
malloc(size_t len)
{
struct __freelist *fp1, *fp2, *sfp1, *sfp2;
char *cp;
size_t s, avail;
/*
* Our minimum chunk size is the size of a pointer (plus the
* size of the "sz" field, but we don't need to account for
* this), otherwise we could not possibly fit a freelist entry
* into the chunk later.
*/
if (len < sizeof(struct __freelist) - sizeof(size_t))
len = sizeof(struct __freelist) - sizeof(size_t);
/*
* First, walk the free list and try finding a chunk that
* would match exactly. If we found one, we are done. While
* walking, note down the smallest chunk we found that would
* still fit the request -- we need it for step 2.
*
*/
for (s = 0, fp1 = __flp, fp2 = 0;
fp1;
fp2 = fp1, fp1 = fp1->nx) {
if (fp1->sz < len)
continue;
if (fp1->sz == len) {
/*
* Found it. Disconnect the chunk from the
* freelist, and return it.
*/
if (fp2)
fp2->nx = fp1->nx;
else
__flp = fp1->nx;
return &(fp1->nx);
}
else {
if (s == 0 || fp1->sz < s) {
/* this is the smallest chunk found so far */
s = fp1->sz;
sfp1 = fp1;
sfp2 = fp2;
}
}
}
/*
* Step 2: If we found a chunk on the freelist that would fit
* (but was too large), look it up again and use it, since it
* is our closest match now. Since the freelist entry needs
* to be split into two entries then, watch out that the
* difference between the requested size and the size of the
* chunk found is large enough for another freelist entry; if
* not, just enlarge the request size to what we have found,
* and use the entire chunk.
*/
if (s) {
if (s - len < sizeof(struct __freelist)) {
/* Disconnect it from freelist and return it. */
if (sfp2)
sfp2->nx = sfp1->nx;
else
__flp = sfp1->nx;
return &(sfp1->nx);
}
/*
* Split them up. Note that we leave the first part
* as the new (smaller) freelist entry, and return the
* upper portion to the caller. This saves us the
* work to fix up the freelist chain; we just need to
* fixup the size of the current entry, and note down
* the size of the new chunk before returning it to
* the caller.
*/
cp = (char *)sfp1;
s -= len;
cp += s;
sfp2 = (struct __freelist *)cp;
sfp2->sz = len;
sfp1->sz = s - sizeof(size_t);
return &(sfp2->nx);
}
/*
* Step 3: If the request could not be satisfied from a
* freelist entry, just prepare a new chunk. This means we
* need to obtain more memory first. The largest address just
* not allocated so far is remembered in the brkval variable.
* Under Unix, the "break value" was the end of the data
* segment as dynamically requested from the operating system.
* Since we don't have an operating system, just make sure
* that we don't collide with the stack.
*/
if (__brkval == 0)
__brkval = __malloc_heap_start;
cp = __malloc_heap_end;
if (cp == 0)
cp = STACK_POINTER() - __malloc_margin;
if (cp <= __brkval)
/*
* Memory exhausted.
*/
return 0;
avail = cp - __brkval;
/*
* Both tests below are needed to catch the case len >= 0xfffe.
*/
if (avail >= len && avail >= len + sizeof(size_t)) {
fp1 = (struct __freelist *)__brkval;
__brkval += len + sizeof(size_t);
fp1->sz = len;
return &(fp1->nx);
}
/*
* Step 4: There's no help, just fail. :-/
*/
return 0;
}
ATTRIBUTE_CLIB_SECTION
void
free(void *p)
{
struct __freelist *fp1, *fp2, *fpnew;
char *cp1, *cp2, *cpnew;
/* ISO C says free(NULL) must be a no-op */
if (p == 0)
return;
cpnew = p;
cpnew -= sizeof(size_t);
fpnew = (struct __freelist *)cpnew;
fpnew->nx = 0;
/*
* Trivial case first: if there's no freelist yet, our entry
* will be the only one on it. If this is the last entry, we
* can reduce __brkval instead.
*/
if (__flp == 0) {
if ((char *)p + fpnew->sz == __brkval)
__brkval = cpnew;
else
__flp = fpnew;
return;
}
/*
* Now, find the position where our new entry belongs onto the
* freelist. Try to aggregate the chunk with adjacent chunks
* if possible.
*/
for (fp1 = __flp, fp2 = 0;
fp1;
fp2 = fp1, fp1 = fp1->nx) {
if (fp1 < fpnew)
continue;
cp1 = (char *)fp1;
fpnew->nx = fp1;
if ((char *)&(fpnew->nx) + fpnew->sz == cp1) {
/* upper chunk adjacent, assimilate it */
fpnew->sz += fp1->sz + sizeof(size_t);
fpnew->nx = fp1->nx;
}
if (fp2 == 0) {
/* new head of freelist */
__flp = fpnew;
return;
}
break;
}
/*
* Note that we get here either if we hit the "break" above,
* or if we fell off the end of the loop. The latter means
* we've got a new topmost chunk. Either way, try aggregating
* with the lower chunk if possible.
*/
fp2->nx = fpnew;
cp2 = (char *)&(fp2->nx);
if (cp2 + fp2->sz == cpnew) {
/* lower junk adjacent, merge */
fp2->sz += fpnew->sz + sizeof(size_t);
fp2->nx = fpnew->nx;
}
/*
* If there's a new topmost chunk, lower __brkval instead.
*/
for (fp1 = __flp, fp2 = 0;
fp1->nx != 0;
fp2 = fp1, fp1 = fp1->nx)
/* advance to entry just before end of list */;
cp2 = (char *)&(fp1->nx);
if (cp2 + fp1->sz == __brkval) {
if (fp2 == NULL)
/* Freelist is empty now. */
__flp = NULL;
else
fp2->nx = NULL;
__brkval = cp2 - sizeof(size_t);
}
}
#ifdef MALLOC_TEST
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
void *handles[32];
size_t sizes[32];
void *
alloc(size_t s)
{
void *p;
if ((p = malloc(s)) == 0)
return 0;
memset(p, 0xd0, s);
return p;
}
void
printfreelist(void)
{
struct __freelist *fp1;
int i;
if (!__flp) {
printf("no free list\n");
return;
}
for (i = 0, fp1 = __flp; fp1; i++, fp1 = fp1->nx) {
printf("entry %d @ %u: size %u, next ",
i, (char *)fp1 - mymem, fp1->sz);
if (fp1->nx)
printf("%u\n", (char *)fp1->nx - mymem);
else
printf("NULL\n");
}
}
int
compare(const void *p1, const void *p2)
{
return *((size_t *)p1) - *((size_t *)p2);
}
void
printalloc(void)
{
int j, k;
size_t i;
size_t sum, sum2;
void *sortedhandles[32];
struct __freelist *fp;
char *cp;
for (i = j = k = sum = sum2 = 0;
i < sizeof handles / sizeof (void *);
i++)
if (sizes[i]) {
j++;
sum += sizes[i];
if (handles[i]) {
k++;
sum2 += sizes[i];
}
}
printf("brkval: %d, %d request%s => sum %u bytes "
"(actually %d reqs => %u bytes)\n",
(char *)__brkval - mymem, j, j == 1? "": "s", sum, k, sum2);
memcpy(sortedhandles, handles, sizeof sortedhandles);
qsort(sortedhandles, 32, sizeof(void *), compare);
for (i = j = 0; i < sizeof sortedhandles / sizeof (void *); i++)
if ((cp = sortedhandles[i])) {
cp -= sizeof(size_t);
fp = (struct __freelist *)cp;
printf("block %d @ %u: %u bytes\n",
j, (char *)&fp->nx - mymem, fp->sz);
j++;
}
}
int
main(void)
{
int i, j, k, l, m, om, p, f;
size_t s;
srand(time(0) ^ getpid());
for (k = 0; k < 100; k++) {
memset(handles, 0, sizeof handles);
memset(sizes, 0, sizeof sizes);
j = rand() % 16 + 15;
l = rand() % 80 + 7;
for (i = s = 0; i < j && s < 256; i++) {
sizes[i] = rand() % l + 1;
s += sizes[i];
}
j = i;
for (m = om = 1, p = 1, f = 0; m < 1000; m++) {
for (i = s = 0; i < j; i++)
if (handles[i])
s++;
if (s == (unsigned)j)
break;
if (m / om > 10) {
p <<= 1;
p |= 1;
}
for (i = 0; i < j; i++)
if (rand() & p) {
if (!handles[i] &&
(handles[i] = alloc(sizes[i])) == 0)
f++;
}
for (i = 0; i < j; i++)
if (rand() & 1) {
free(handles[i]);
handles[i] = 0;
}
}
if (f)
printf("%d alloc failure%s total\n",
f, f == 1? "": "s");
printf("After alloc:\n");
printalloc();
printfreelist();
for (i = 0; i < j; i++)
free(handles[i]);
printf("After cleanup:\n");
printfreelist();
}
return 0;
}
#endif /* MALLOC_TEST */
Да MsStore.
В меню пуск есть, но там нет свойств в ярлыка.
Если перетащить на рабочий стол, то показывает "Расположение объекта: Applications"
Рабочая папка : Нет
Да, всё заработало как встарь.
Свёртки-то попробуй!
Можно и лямбду с this'ом, тока имей в виду, что некоторые котомордые тут в теме в примере накосячили. У Ворот в примере используется неявный захват this через "=". Но, это, во-первых, и раньше работало, а во-вторых, в стандарте 20 года скорее всего будет объявлено deprecated. Если реально проверять фичу 17-го стандарта, то надо *this передавать лямбде явно.
Свёртки-то попробуй!
Можно и лямбду с this'ом
Прошу прощения, канешно, но я реально половину слов не догоняю, мои знания кончаются на Страуструпе, а он про такие восокоматерьяльные хрени тоже не знал тогда. Когда-нибуть я обязательно всё это всосу и попробую. (наерна)
Дед, есть хорошая статья про развитие лямбд в С++ от 11-го года и до 20-го. Она в двух частях, посмотри, если интересно. Там с оценками автора можно и поспорить, но по фактам я так сходу никаких особых ляпов не заметил - вполне качественно.
https://habr.com/ru/company/otus/blog/444524/ - 1 часть
https://habr.com/ru/company/otus/blog/455978/ - 2 часть
Спасибо,почитаю.
Upd. Почитал. Не просто темный лес, а дремучая сказочная тайга.
...я так и не понял, как пользоваться 000'000'000.
здрасти клапауций это для читабельности) не приходилось считать нули?))
здрасти клапауций это для читабельности) не приходилось считать нули?))
Это у тебя для читабельности, а у Клапы - для троллинга :)
Блин, и правда ведь - на автомате написал.
А что, некоторые свинорылые не могли вчера ещё носом ткнуть? Я б давно поправил.
Вот так нада :)
Блин, и правда ведь - на автомате написал.
А что, некоторые свинорылые не могли вчера ещё носом ткнуть? Я б давно поправил.
Вот так нада :)
неважно, у меня из-за вашегогада 1.8.10 пока не заработала, надо его снести, всё впереди
и я пошёл попил, поел, не полегчало...
А что, некоторые свинорылые не могли вчера ещё носом ткнуть? Я б давно поправил.
Так я тока сегодня заметил.
А вообще, мне нравится выражение в строке №23 - посмотреть приятно :)
здрасти клапауций это для читабельности) не приходилось считать нули?))
полюбому их(нули) приходится считать - раньше по одному, теперь можно по три нуля и одной одинарной кавычке.
до того выбешивала в некоторых калькуляторах группировка нулей по три, разделение нулей точками, запятыми одинарными кавычками.
теперь смертельно больным дислексией можно поручать вбивать мулиарды в код - здобулы, епта.
Когда-то, с подачи wdrakula, я писал, что если поставить в IDE 1.8.9 опцию С++17, то можно пользоваться разделителем разрядов чисел (например, писать 16'000'000 вместо трудночитаемого 16000000) и нормальными constexpr функциями, но, к сожалению, не поддерживаются "if constexpr" и, самое интересное - свёртки.
Поставил IDE 1.8.10, заметил, что там более свежий релиз GCC и полез смотреть как оно там.
Выяснил, что теперь и "if constexpr" и свёртки поддерживаются. Сейчас исследую как это реализовано (например, насколько эффективны свёртки), а также смотрю какие ещё вкусности появились.
Надо писать здесь о результатах и о том, как этими вкусностями пользоваться? А то, если это никому нафиг не сдалось, мне жаль пальцы об клавиши бить.
а я Вам что говорил )))
и я пошёл попил, поел, не полегчало...
Так Вы же опции на 17-го года стандарт не настроили. См. строку №24 Вашей ругани.
Также см. #48
и я пошёл попил, поел, не полегчало...
Так Вы же опции на 17-го года стандарт не настроили. См. строку №24 Вашей ругани.
Также см. #48
но бросить пить не может быть )))
Забыл, что не зависимо от типа программы, настройки компилятора прописывает в винде 7 и выше по пути - C:\Users\User\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.1
)))
А я говнокодя на PHP любил foreach, он хороший и удобный (если говнокодить на PHP), жалко.... Говнокодить хочу и на мк!]
А я говнокодя на PHP любил foreach, он хороший и удобный (если говнокодить на PHP), жалко.... Говнокодить хочу и на мк!]
уж не в Битриксе? Уж там этого говнокода ... (зато его много)из народного фольклора
Ребята, подскажите пожалуйста, с чем связано то что при avr-gcc-7.2.0 виртуальные деструкторы работали, а на avr-gcc-7.3.0 ( точнее, с добавлением опции -std=gnu++1z ) пришлось дописывать delete(void * ptr, unsigned int) и deletep[(void * ptr, unsigned int) и что это за второй, не используемый параметр?
p.s. на https://gcc.gnu.org/gcc-7/changes.html ничего на эту тему не нашел
с чем связано то что ... пришлось дописывать
С тем, что их там нет, а они требуются, см. ISO/IEC 14882:2017 § 8.3.5 п.8, (стр. 128)
что это за второй, не используемый параметр?
Размер. Нужен не всегда, но бывает. Тонкостей и подробностей там море, очень много описывать, лучше Вам почитать в оригинале.
Для начала общие сведения о том, как устроены аллокаторы (§ 6.7.4.1, стр.71) и деаллокаторы (§ 6.7.4.2, стр. 72). Там уже встречаются эти параметры и говорится о них.
Далее можно посмотреть требования к т.н. библиотекам поддержки языка в части выделения и освобождения памяти. Это § 21.6.2 (стр.493). Там всё описано предельно подробно.
Спасибо, почитал ISO/IEC 14882:2017 § 8.3.5 п.8, там ничего про второй интовый параметр нету.
Note: An implementat ion provides default definit ions of the global deallocat ion funct ions operat or delet e
for non-arrays ( 21 . 6 . 2 . 1 ) and operat or delet e[] for arrays (21 . 6 . 2 . 2) . A C++ program can provide alternat ive definitions of these funct ions (20 . 5 . 4 . 6) , and/or class- sp ecific versions (1 5 . 5) . — end note ]
Дальше уже по-лучше, и разумеется параметр д.б. не интовый а size_t, мелочь но стало тревожно.
Дайте пожалуйста ссылочку откуда вы взяли эти (delete(void * ptr, unsigned int) and delete[](void * ptr, unsigned int)) функции, хочется спросить/понять чем руководствовались авторы. Спасибо!
Ну, да, в этом разделе просто сказано, что функции обязаны быть и указаны разделы где подробнее. А подробности в других, Вы их тоже нашли.
size_t - правильно. В данном случае это как раз unsigned, так что всё правильно, но, наверное, лучше было size_t писать.
Насчёт "тревожно", Вы не разобрались откуда там что может взяться и что означает? Там идея такая, если при вызове аллокатора использовалось количество элементов, то это количество элементов нужно передать и деаллокатору. Но, поскольку здесь нет хитрых аллокаторов (смотрите на них - они все в том файле и все тривиальны), вот я и написал generic деаллокаторы (я их ниоткуда не брал). Нужно по синтаксису - на, кушай. Должно работать нормально. Напишите проверочный пример пример и проверьте, ну или я могу сам написать, только уж завтра.
я добавил отладку в эти функции :
Не понятно как free(ptr) и в случае родных операторов и в случае самодельных понимает что ей удалять?
Я проверил, при создании массива в куче перед нулевым элементом исправно записывается размер массива.
Занятно, что если не прописать деструктор, то самодельный delete[](...) вообще не вызывается
Дело в том, что размер известен из самого блока памяти (malloc там его помещает, а free читает). Нетривиальный деаллокатор нужен, если используется нетривиальный аллокатор, а здесь во всех аллокаторах используется простой malloc, ну так чего выпендриваться?
Чтобы совсем успокоиться, проверьте память (адрес начала кучи) перед созданием кучи объектов (в т.ч. и массивов объектов) и после их уничтожения. Увидите. что всё нормально.
Память я проверил, на разных сценариях сотни тысяч раз создавал-удалял, вроде всё ОК, но это-ж тестовые сценарии, в жизни всё по-другому складывается.
Меня смущал синтаксис delete vs delete[], Брюс Эккель Философия С++ гл 13. стр 412 пишет что эти команды работают по-разному. Я из этого делал вывод что при создании массива в куче сохраняется и его размер, а для "скалярных" типов - нет. А по тестам - оказалось, что и при создании в куче uint8_t - там тоже сохраняется ее размер. Исходников free & malloc я не нашел, хотя на www.nongnu.org/avr-libc/ есть нечто похожее.
По факту, получается, что в случае Arduino разницы между delete и delete[] нет и можно спать относительно спокойно :)
Исходников free & malloc я не нашел
У меня есть, правда не самая свежая библиотека - avr-libc-1.8.1
спасибо, про www.nongnu.org/avr-libc/ я уже писал
Поставил я 1.8.11.
Теперь не могу найти папку с программой.
Где она валяется по умолчанию не подскажете ?
Посмотри в свойствах ярлыка, там указан путь к папке.
Посмотри в свойствах ярлыка, там указан путь к папке.
Ярлыка нет.
Устанавливал через установщик win10.
Ярлыка нет.
Что и в меню "Пуск" тоже нет?
Устанавливал через установщик win10.
Что за установщик win10? Это Microsoft Store?
Да MsStore.
В меню пуск есть, но там нет свойств в ярлыка.
Если перетащить на рабочий стол, то показывает "Расположение объекта: Applications"
Рабочая папка : Нет
Ну а если поискать файл arduino.exe или просто arduino* по диску c:/ ?
Или вот так:
https://superuser.com/questions/1298194/how-do-i-figure-out-the-installation-path-of-apps-from-the-microsoft-store
Будет в C:/Program Files/WindowsApps/...
Ппц закопали.
Доступа нет в свои же папки.
У кого как, cacls.exe пока не отменили. Погромисты, млин.
У кого как, cacls.exe пока не отменили. Погромисты, млин.
Погромисты другими делами занимаются.
Тут любители ардуины.
Да и программист и сисадмин, немного разные специальности.
Погромисты вон пишут вот такую Виндоус, где херь куда ручками полезешь без предварительной подготовки