From Newsgroup: comp.lang.c

Lawrence DrCOOliveiro pisze:

On Fri, 8 May 2026 20:16:09 +0200, fir wrote:

thats this simple but this is totally NEEDED, its hell people not
adepted it

Why donrCOt you send them a patch to fix it?

this is a convention many people should use - how i can sent them patch?

winapi will not change names but in some new api they should adopt it


i almost never use things to alloc ram this way (i do things bassed on realloc) but sadly there are probably cases reallock way is not most convenient (it is when you needed to alloc something with function
but you need to alloc many things in parralel - though im still not sure
there is no other way some whould do it and this is all design error

howewer if you do such way it should not be MakeSprite("name.bmp"); OpenSound("some.wav")it should be AllocSprite and AllocSound

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Efc|Efc#Jacek Marcin JaworskiEfc|Efc# pisze:

W dniu 8.05.2026 o-a23:27, fir pisze:

something mistaked in your brain

In Polish: Nie! Pyta+eem o to w prost! I gada+ee+c co+c w tym stylu jak teraz o UMK.
In Eng.: No! I asked straight to you. And you told me some think like
that about UMK.

i studied theoretical phisics on UMK (extremally good times it was)..

i dont remember the user as you at all

In Polish: W przesz+eo+cci u++ywa+eem ksywy "Szyk Cech".
In Eng.: In the past I use "Szyk Cech" as my nick.

oh, great guy Szyk form prof. pajak,leniovo and things - hello..
if yo want to more leisure talk i could later probably give you my
discord link (almost empty but can talk here , i sit there not to be
bored to much)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>

As was mentioned in another post in another thread, let's judge people
here on their posts here. We don't need to know about Fir's - or your - qualifications or lack thereof. We don't need to know people's academic
or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the posts.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

im not sure though if all those functions that use allock inside are in
fact 'children' of alloc in riogramming slang..are they?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown pisze:

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>

As was mentioned in another post in another thread, let's judge people
here on their posts here.-a We don't need to know about Fir's - or your - qualifications or lack thereof.-a We don't need to know people's academic
or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the posts.

few years ago we were in quite good relations witch szyk..he was a
little shizophrenic (as to our day by day typical standards) but kinda respectable (by me and my colegue emo)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

David Brown pisze:

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>

As was mentioned in another post in another thread, let's judge people
here on their posts here.-a We don't need to know about Fir's - or your
- qualifications or lack thereof.-a We don't need to know people's
academic or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the posts.

few years ago we were in quite good relations witch szyk..he was a
little shizophrenic (as to our day by day typical standards) but kinda respectable (by me and my colegue emo)

i meant 'overly shizophrenic')

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 09/05/2026 16:38, fir wrote:

David Brown pisze:

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>

As was mentioned in another post in another thread, let's judge people
here on their posts here.-a We don't need to know about Fir's - or your
- qualifications or lack thereof.-a We don't need to know people's
academic or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the posts.

<snip>

The same applies to you - if you have a personal beef with Jacek, use
email. We don't need that kind of personal attacks here.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> writes:

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>
As was mentioned in another post in another thread, let's judge people
here on their posts here. We don't need to know about Fir's - or your
- qualifications or lack thereof. We don't need to know people's
academic or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the
posts.

Indeed.

And please also consider that many of us here have killfiled fir.
Since so many of us don't see fir's posts, there's not much point
in publicly replying to him.

Of course if fir says something relevant to C, feel free to reply.
But I see no C content in this subthread.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 9 May 2026 08:37:22 +0200, fir wrote:

Lawrence DrCOOliveiro pisze:

On Fri, 8 May 2026 20:16:09 +0200, fir wrote:

thats this simple but this is totally NEEDED, its hell people not
adepted it

Why donrCOt you send them a patch to fix it?

this is a convention many people should use - how i can sent them
patch?

Develop and test a fix against your copy of the source code. Then send
a diff between the original code and your fix.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Keith Thompson pisze:

David Brown <david.brown@hesbynett.no> writes:

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>
As was mentioned in another post in another thread, let's judge people
here on their posts here. We don't need to know about Fir's - or your
- qualifications or lack thereof. We don't need to know people's
academic or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the
posts.

Indeed.

And please also consider that many of us here have killfiled fir.
Since so many of us don't see fir's posts, there's not much point
in publicly replying to him.

Of course if fir says something relevant to C, feel free to reply.
But I see no C content in this subthread.

you dont see many things keith thompson

obviously it is quite strong c content - it is about naming conventions
and this is important part od c culture/coding (though it is not only c)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Keith Thompson pisze:

David Brown <david.brown@hesbynett.no> writes:

On 08/05/2026 22:32, Efc|Efc#Jacek Marcin JaworskiEfc|Efc# wrote:
<snip>
As was mentioned in another post in another thread, let's judge people
here on their posts here.-a We don't need to know about Fir's - or your
- qualifications or lack thereof.-a We don't need to know people's
academic or professional careers.

If you have something personal to take up with Fir, please do so by
email and not here on Usenet.

Let those that want to read Fir's posts, read them, and let those that
want to reply or comment on the do so based on the contents of the
posts.

Indeed.

And please also consider that many of us here have killfiled fir.
Since so many of us don't see fir's posts, there's not much point
in publicly replying to him.

Of course if fir says something relevant to C, feel free to reply.
But I see no C content in this subthread.

you dont see many things keith thompson

obviously it is quite strong c content - it is about naming conventions
and this is important part od c culture/coding (though it is not only c)

as someone (afir bns user kenny) pointed it is keith gently suggesting
he is better user of some group (opinions my vary) so he indeed gently
suggest he is a dork (and his iq is also doubtfull becouse im not sure
higher iq people would do that, though maybe things are a bit more
complex... maybe he is like a monster watching gates ;c )

i like this group and nice to see nothing changes - as i not being here
chnge a lot and probably for worse (yawn)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 08.05.2026 um 20:16 schrieb fir:

winapi has some functions that when you call it you need to later call
some function to "destroy" it - all knows the topic (not only winapi has
it but winapi is example)

those functions are hell, but i realized today if some gives them to use
for people they simply should be named after Alloc, for example if
uunction uses malloc to alloc the bitmap or font etc (or other alloc may
be platform specyfic) the name of this function should be AllocBitmap AllocFont

thats this simple but this is totally NEEDED, its hell people not
adepted it

In C++ that's easy with some self-documenting code (almost no one uses
WinAPI with C). I've developed a small class which is like experimental ::scope_exit, here it is:

#pragma once
#include <utility>
#include <concepts>
#include "nui.hpp"

template<std::invocable Fn>
struct defer final
{
defer( Fn &&fn ) :
m_enabled( true ),
m_fn( std::forward<Fn>( fn ) )
{
}
defer( defer const & ) = delete;
void operator =( defer const & ) = delete;
~defer() noexcept(false)
{
if( m_enabled ) [[likely]]
m_fn();
}
template<typename ... Fns>
bool operator ()( defer<Fns> &... additional )
{
if( !m_enabled ) [[unlikely]]
return false;
m_enabled = false;
m_fn();
return (additional() && ...);
}
template<typename ... Fns>
void disable( defer<Fns> &... additional ) noexcept
{
m_enabled = false;
(additional.disable(), ...);
}
template<typename ... Fns>
void enable( defer<Fns> &... additional ) noexcept
{
m_enabled = true;
(additional.enable(), ...);
}
private:
bool m_enabled;
NO_UNIQUE_ADDRESS Fn m_fn;
};

With that you'd simply write:

void *xyz = CreateResource( ... );
defer cleanup( [&] { DestroyResource( xyz ); } );

So if allocation and destruction is so closely bound to each other
there's really no need for a naming convention like you suggest.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bonita Montero pisze:

Am 08.05.2026 um 20:16 schrieb fir:

winapi has some functions that when you call it you need to later call
some function to "destroy" it - all knows the topic (not only winapi
has it but winapi is example)

those functions are hell, but i realized today if some gives them to
use for people they simply should be named after Alloc, for example if
uunction uses malloc to alloc the bitmap or font etc (or other alloc
may be platform specyfic) the name of this function should be
AllocBitmap AllocFont

thats this simple but this is totally NEEDED, its hell people not
adepted it

In C++ that's easy with some self-documenting code (almost no one uses
WinAPI with C). I've developed a small class which is like experimental ::scope_exit, here it is:

#pragma once
#include <utility>
#include <concepts>
#include "nui.hpp"

template<std::invocable Fn>
struct defer final
{
-a-a-a-adefer( Fn &&fn ) :
-a-a-a-a-a-a-a m_enabled( true ),
-a-a-a-a-a-a-a m_fn( std::forward<Fn>( fn ) )
-a-a-a-a{
-a-a-a-a}
-a-a-a-adefer( defer const & ) = delete;
-a-a-a-avoid operator =( defer const & ) = delete;
-a-a-a-a~defer() noexcept(false)
-a-a-a-a{
-a-a-a-a-a-a-a if( m_enabled ) [[likely]]
-a-a-a-a-a-a-a-a-a-a-a m_fn();
-a-a-a-a}
-a-a-a-atemplate<typename ... Fns>
-a-a-a-abool operator ()( defer<Fns> &... additional )
-a-a-a-a{
-a-a-a-a-a-a-a if( !m_enabled ) [[unlikely]]
-a-a-a-a-a-a-a-a-a-a-a return false;
-a-a-a-a-a-a-a m_enabled = false;
-a-a-a-a-a-a-a m_fn();
-a-a-a-a-a-a-a return (additional() && ...);
-a-a-a-a}
-a-a-a-atemplate<typename ... Fns>
-a-a-a-avoid disable( defer<Fns> &... additional ) noexcept
-a-a-a-a{
-a-a-a-a-a-a-a m_enabled = false;
-a-a-a-a-a-a-a (additional.disable(), ...);
-a-a-a-a}
-a-a-a-atemplate<typename ... Fns>
-a-a-a-avoid enable( defer<Fns> &... additional ) noexcept
-a-a-a-a{
-a-a-a-a-a-a-a m_enabled = true;
-a-a-a-a-a-a-a (additional.enable(), ...);
-a-a-a-a}
private:
-a-a-a-abool m_enabled;
-a-a-a-aNO_UNIQUE_ADDRESS Fn m_fn;
};

With that you'd simply write:

-a-a-a-avoid *xyz = CreateResource( ... );
-a-a-a-adefer cleanup( [&] { DestroyResource( xyz ); } );

So if allocation and destruction is so closely bound to each other
there's really no need for a naming convention like you suggest.

absolutely there is becouse you must be warned, and you must be aware

i mean it is not even you must be warned of the functions which alocare
ram but you must be warned about functions who "populate" it (if this is
right word, srry weak english: i mean those functions that will allocate
new ram each time you will call it - ITS ABSOLUTELLY UST TO BE WARNED
about those functions and imo naming it Allocate is reasonable way

those handles are second problem..handles are kinda bad design, ofc you
may learn to use it and code with it can be sorta good butimo handles
overally are not top design

reason is when say you need to alocate something say game resource
loaded from disk into ram you need this resource loaded and visible
but damn you dont need a handle..handle is somehing that is in fact not
needed

if you load such resource you need it loaded and just present in given visibility area..best way to have it is to have thsi resource avaliable
this way that its identyficator is wisible and avaliable to use

handle is something other lik something that you have locally and you
have it assign to something that will be visible globally, it is bad

(im not sure hovever how the very good way of doing that would look like
becuse there is some problem/conflict

if you want something wide visible you need to put it out the scope of functions - but in turn dhe decisions lo load it or unload (alloc
dealloc) you make locally in functions flow..so it is probably a sign
there is some lack in language here

maybe solution would be makin something global (im mean inner module
scope as global is a myth) in functions just not to spread things in two places

void load_things()
{
global font f; AllocFont(&f, "verdana")
}

soem could say i cluld do

font f; void load_things()
{
AllocFont(&f, "verdana")
}

maybe, but it seems something is slightly wrong here in both versions maybe


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bonita Montero pisze:

font f; void load_things()
{
-a AllocFont(&f, "verdana")
}

maybe, but it seems something is slightly wrong here in both versions maybe

stil this above is better design logically than this with handles
(which i guess almast always are pointers to structures, unless they are
maybe ints if the allocations are kept in internal array)

its beter becouse those entities you use are structures and pointers to
it are not needed - you have pointers you have not needed things, you
have segfaults and so on

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bonita Montero pisze:

Am 08.05.2026 um 20:16 schrieb fir:

winapi has some functions that when you call it you need to later call
some function to "destroy" it - all knows the topic (not only winapi
has it but winapi is example)

those functions are hell, but i realized today if some gives them to
use for people they simply should be named after Alloc, for example if
uunction uses malloc to alloc the bitmap or font etc (or other alloc
may be platform specyfic) the name of this function should be
AllocBitmap AllocFont

thats this simple but this is totally NEEDED, its hell people not
adepted it

In C++ that's easy with some self-documenting code (almost no one uses
WinAPI with C). I've developed a small class which is like experimental ::scope_exit, here it is:

#pragma once
#include <utility>
#include <concepts>
#include "nui.hpp"

template<std::invocable Fn>
struct defer final
{
-a-a-a-adefer( Fn &&fn ) :
-a-a-a-a-a-a-a m_enabled( true ),
-a-a-a-a-a-a-a m_fn( std::forward<Fn>( fn ) )
-a-a-a-a{
-a-a-a-a}
-a-a-a-adefer( defer const & ) = delete;
-a-a-a-avoid operator =( defer const & ) = delete;
-a-a-a-a~defer() noexcept(false)
-a-a-a-a{
-a-a-a-a-a-a-a if( m_enabled ) [[likely]]
-a-a-a-a-a-a-a-a-a-a-a m_fn();
-a-a-a-a}
-a-a-a-atemplate<typename ... Fns>
-a-a-a-abool operator ()( defer<Fns> &... additional )
-a-a-a-a{
-a-a-a-a-a-a-a if( !m_enabled ) [[unlikely]]
-a-a-a-a-a-a-a-a-a-a-a return false;
-a-a-a-a-a-a-a m_enabled = false;
-a-a-a-a-a-a-a m_fn();
-a-a-a-a-a-a-a return (additional() && ...);
-a-a-a-a}
-a-a-a-atemplate<typename ... Fns>
-a-a-a-avoid disable( defer<Fns> &... additional ) noexcept
-a-a-a-a{
-a-a-a-a-a-a-a m_enabled = false;
-a-a-a-a-a-a-a (additional.disable(), ...);
-a-a-a-a}
-a-a-a-atemplate<typename ... Fns>
-a-a-a-avoid enable( defer<Fns> &... additional ) noexcept
-a-a-a-a{
-a-a-a-a-a-a-a m_enabled = true;
-a-a-a-a-a-a-a (additional.enable(), ...);
-a-a-a-a}
private:
-a-a-a-abool m_enabled;
-a-a-a-aNO_UNIQUE_ADDRESS Fn m_fn;
};

With that you'd simply write:

-a-a-a-avoid *xyz = CreateResource( ... );
-a-a-a-adefer cleanup( [&] { DestroyResource( xyz ); } );

So if allocation and destruction is so closely bound to each other
there's really no need for a naming convention like you suggest.

note i dont know what your class is doin (i detaste c+ new cobol
horrible language) but the problem of AllocFunctions() is not to meke
sure programmer wil call Dealloc (which in most cases is not needed at
all) - the problem is not to allow it call many times with no need

in winapi trash naming this gdi is fatel you need lo create some gdy
functions like birmaps dibs whateever it is some brushes maybe yet some
more thinghs and if you would simply know which one is allocating
something you would use it quite sane way without it its kinda gate to
small insanity (at least for some)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bonita Montero pisze:

Am 08.05.2026 um 20:16 schrieb fir:

winapi has some functions that when you call it you need to later
call some function to "destroy" it - all knows the topic (not only
winapi has it but winapi is example)

those functions are hell, but i realized today if some gives them to
use for people they simply should be named after Alloc, for example
if uunction uses malloc to alloc the bitmap or font etc (or other
alloc may be platform specyfic) the name of this function should be
AllocBitmap AllocFont

thats this simple but this is totally NEEDED, its hell people not
adepted it

In C++ that's easy with some self-documenting code (almost no one uses
WinAPI with C). I've developed a small class which is like experimental
::scope_exit, here it is:

#pragma once
#include <utility>
#include <concepts>
#include "nui.hpp"

template<std::invocable Fn>
struct defer final
{
-a-a-a-a-adefer( Fn &&fn ) :
-a-a-a-a-a-a-a-a m_enabled( true ),
-a-a-a-a-a-a-a-a m_fn( std::forward<Fn>( fn ) )
-a-a-a-a-a{
-a-a-a-a-a}
-a-a-a-a-adefer( defer const & ) = delete;
-a-a-a-a-avoid operator =( defer const & ) = delete;
-a-a-a-a-a~defer() noexcept(false)
-a-a-a-a-a{
-a-a-a-a-a-a-a-a if( m_enabled ) [[likely]]
-a-a-a-a-a-a-a-a-a-a-a-a m_fn();
-a-a-a-a-a}
-a-a-a-a-atemplate<typename ... Fns>
-a-a-a-a-abool operator ()( defer<Fns> &... additional )
-a-a-a-a-a{
-a-a-a-a-a-a-a-a if( !m_enabled ) [[unlikely]]
-a-a-a-a-a-a-a-a-a-a-a-a return false;
-a-a-a-a-a-a-a-a m_enabled = false;
-a-a-a-a-a-a-a-a m_fn();
-a-a-a-a-a-a-a-a return (additional() && ...);
-a-a-a-a-a}
-a-a-a-a-atemplate<typename ... Fns>
-a-a-a-a-avoid disable( defer<Fns> &... additional ) noexcept
-a-a-a-a-a{
-a-a-a-a-a-a-a-a m_enabled = false;
-a-a-a-a-a-a-a-a (additional.disable(), ...);
-a-a-a-a-a}
-a-a-a-a-atemplate<typename ... Fns>
-a-a-a-a-avoid enable( defer<Fns> &... additional ) noexcept
-a-a-a-a-a{
-a-a-a-a-a-a-a-a m_enabled = true;
-a-a-a-a-a-a-a-a (additional.enable(), ...);
-a-a-a-a-a}
private:
-a-a-a-a-abool m_enabled;
-a-a-a-a-aNO_UNIQUE_ADDRESS Fn m_fn;
};

With that you'd simply write:

-a-a-a-a-avoid *xyz = CreateResource( ... );
-a-a-a-a-adefer cleanup( [&] { DestroyResource( xyz ); } );

So if allocation and destruction is so closely bound to each other
there's really no need for a naming convention like you suggest.

note i dont know what your class is doin (i detaste c+ new cobol
horrible language) but the problem of AllocFunctions() is not to meke
sure programmer wil call Dealloc (which in most cases is not needed at
all) - the problem is not to allow it call many times with no need

in winapi trash naming this gdi is fatel you need lo create some gdy functions like birmaps dibs whateever it is some brushes maybe yet some
more thinghs and if you would simply know which one is allocating
something you would use it quite sane way without it its kinda gate to
small insanity (at least for some)

this insanity is hovever interesting possibly:

it seems it is becouse if you have api that makes some internal things
but you dont know boundaries (it is what this functions are for sure not doing) you hell dont know what it really do, especially if thise
functions need some way of internal composition and dpends one on
another..it is swamp

so probably i thing apis should be done this way user is sure of its boundaries (in what area those functions strictly operte) ...maybe there
could more be said on such things

today hoever it seems to me that genarally people can code and probably
ralely step intu such swamp (probably) (im not strictly sure hovever)
(hovever i was alway interested in such topics of what is good design in language or code and what not)

one of things i noted and said here was for example good design is to
minimise code jumping that way classic enum is totally bad, top code
consts (i mena those consts you define at top of the code and then they
have many places of use) seem also not much good, handles are bad and so on\but in turn aspect programming ehen you can write function locally
and assign it to a place when it need to be called without jumping there
would be good


--- Synchronet 3.22a-Linux NewsLink 1.2