On Fri, 22 Mar 2024 08:20:11 -0400, Chris Ahlstrom wrote:

> operator << is useful with std::ostringstream when you want to avoid
> having deal with allocating enough output space. Still, I use this a
> lot:
>
> char temp[32];
> snprintf(temp, sizeof temp, "We have %d idiots here", idcount);
>
> Sometime a printf specification is just easier to read.

I wrote this a long time ago, for use in some projects in C++. You can
tell it was a long time ago, from the checking for glibc versions:

std::string string_printf
(
const char * Format,
...
)
/* does an sprintf of its remaining arguments according to Format,
returning the formatted result. */
{
std::string Result;
char * TempBuf;
ulong TempBufSize;
TempBuf = nil;
TempBufSize = 128; /* something reasonable to begin with */
for (;;)
{
TempBuf = (char *)malloc(TempBufSize);
if (TempBuf == nil)
break;
va_list Args;
va_start(Args, Format);
const long BufSizeNeeded = vsnprintf(TempBuf, TempBufSize, Format, Args);
/* not including trailing null */
va_end(Args);
if (BufSizeNeeded >= 0 and BufSizeNeeded < TempBufSize)
{
/* the whole thing did fit */
TempBufSize = BufSizeNeeded; /* not including trailing null */
break;
} /*if*/
free(TempBuf);
if (BufSizeNeeded < 0)
{
/* glibc < 2.1 */
TempBufSize *= 2; /* try something bigger */
}
else
{
/* glibc >= 2.1 */
TempBufSize = BufSizeNeeded + 1;
/* now I know how much I need, including trailing null */
} /*if*/
} /*for*/
if (TempBuf != nil)
{
Result.append(TempBuf, TempBufSize);
free(TempBuf);
} /*if*/
return
Result;
} /*string_printf*/

On Fri, 22 Mar 2024 14:06:36 -0400, Chris Ahlstrom wrote:

>> f-strings are so nice, especially since you can use it as arguments for
>> other functions and don't have to rely on a temporary string var.
>
> Those sound like the formatting available for C# String.

I think they were introduced in 3.9. It really smells like a case of 'Duh,
why didn't we think of that?' I think C# got there first from the older

("The {0} blivits were shipped to {1}", "useless", "washington")'

style.

Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:

> On Fri, 22 Mar 2024 08:20:11 -0400, Chris Ahlstrom wrote:
>
>> operator << is useful with std::ostringstream when you want to avoid
>> having deal with allocating enough output space. Still, I use this a
>> lot:
>>
>> char temp[32];
>> snprintf(temp, sizeof temp, "We have %d idiots here", idcount);
>>
>> Sometime a printf specification is just easier to read.
>
> I wrote this a long time ago, for use in some projects in C++. You can
> tell it was a long time ago, from the checking for glibc versions:
>
> std::string string_printf
> (
> const char * Format,
> ...
> )
> /* does an sprintf of its remaining arguments according to Format,
> returning the formatted result. */
> {
> std::string Result;
> char * TempBuf;
> ulong TempBufSize;
> TempBuf = nil;
> TempBufSize = 128; /* something reasonable to begin with */
> for (;;)
> {
> TempBuf = (char *)malloc(TempBufSize);
> if (TempBuf == nil)
> break;
> va_list Args;
> va_start(Args, Format);
> const long BufSizeNeeded = vsnprintf(TempBuf, TempBufSize, Format, Args);
> /* not including trailing null */
> va_end(Args);
> if (BufSizeNeeded >= 0 and BufSizeNeeded < TempBufSize)
> {
> /* the whole thing did fit */
> TempBufSize = BufSizeNeeded; /* not including trailing null */
> break;
> } /*if*/
> free(TempBuf);
> if (BufSizeNeeded < 0)
> {
> /* glibc < 2.1 */
> TempBufSize *= 2; /* try something bigger */
> }
> else
> {
> /* glibc >= 2.1 */
> TempBufSize = BufSizeNeeded + 1;
> /* now I know how much I need, including trailing null */
> } /*if*/
> } /*for*/
> if (TempBuf != nil)
> {
> Result.append(TempBuf, TempBufSize);
> free(TempBuf);
> } /*if*/
> return
> Result;
> } /*string_printf*/

You showed me yours. Let me show you mine. :-D

te<typename ... Args>
std::string string_format (const std::string & format, Args ... args)
{ std::string result;
size_t sz = std::snprintf(nullptr, 0, format.c_str(), args ...);
if (sz > 0)
{
std::unique_ptr<char []> buf(new char[sz + 1]);
std::snprintf(buf.get(), sz + 1, format.c_str(), args ...);
result = std::string(buf.get(), buf.get() + sz);
}
return result;
}

Note the variadic template.

In C++20 you can apparently write

#include <format>
std::string result = std::format("{} {}!", "Hello", "world");

--
You seek to shield those you love and you like the role of the provider.

On 3/23/2024 8:11 AM, Chris Ahlstrom wrote:

> te<typename ... Args>
> std::string string_format (const std::string & format, Args ... args)
> {
> std::string result;
> size_t sz = std::snprintf(nullptr, 0, format.c_str(), args ...);
> if (sz > 0)
> {
> std::unique_ptr<char []> buf(new char[sz + 1]);
> std::snprintf(buf.get(), sz + 1, format.c_str(), args ...);
> result = std::string(buf.get(), buf.get() + sz);
> }
> return result;
> }
>
> Note the variadic template.

I note the two thousand uses of std::.

Couldn't you just use 'using namespace std;' inside this function (or
whatever this 'te' thing is?)

On Sat, 23 Mar 2024 08:11:18 -0400, Chris Ahlstrom wrote:

> In C++20 you can apparently write
>
> #include <format>
> std::string result = std::format("{} {}!", "Hello", "world");

Strictly positional? If you're perverted

string result = string.Format("{1} {0}!", "Hello", "world");

will give you "world Hello" in C#. There are legitimate uses where you
might want to repeat an object I guess.

On Sat, 23 Mar 2024 10:16:46 -0400, DFS wrote:

> I note the two thousand uses of std::.
>
> Couldn't you just use 'using namespace std;' inside this function (or
> whatever this 'te' thing is?)

Evil! Evil! Don't you realize there is a 1 in 23 million chance someone
has defined cout locally? I suppose you're one of those people in Python
that have

import KitchenSink

rather than

from KitchenSink import stopper

On Sat, 23 Mar 2024 10:16:46 -0400, DFS wrote:

> I note the two thousand uses of std::.

using-clauses are fine inside .cpp files. Not so good in .h files, because
then they contaminate the namespace of every source file that includes
them.

In C++, it seems quite common to write header-only code (using inlines
etc), so there are no additional object files to link against.

DFS wrote this copyrighted missive and expects royalties:

> On 3/23/2024 8:11 AM, Chris Ahlstrom wrote:
>
>> te<typename ... Args>
>> std::string string_format (const std::string & format, Args ... args)
>> {
>> std::string result;
>> size_t sz = std::snprintf(nullptr, 0, format.c_str(), args ...);
>> if (sz > 0)
>> {
>> std::unique_ptr<char []> buf(new char[sz + 1]);
>> std::snprintf(buf.get(), sz + 1, format.c_str(), args ...);
>> result = std::string(buf.get(), buf.get() + sz);
>> }
>> return result;
>> }
>>
>> Note the variadic template.

Heh, didn't notice that "template" got chopped to "te". Fumble-fingers!

> I note the two thousand uses of std::.

Actually, I left out one for the size_t declaration: std::size_t.

> Couldn't you just use 'using namespace std;' inside this function (or
> whatever this 'te' thing is?)
^ template DOH!

Like Larry said about using them in headers. But I will use them in headers in
this manner:

namespace foo
{ using container = std::vector<std::byte>;

class bar
{
using container = std::map<std::string, std::string>;
. . .
};
}

So the caller can choose to use foo::container or foo::bar::container.

If all those namespace bug you, you will surely hate the Boost libraries.
As I recall, it has nested namespaces galore.

One other note: I never use "using namespace std", even in the cpp file.
Also the same with namespaces used in other libraries, including my own
libraries. Better to show them upfront to avoid puzzlement.

And I don't do that in main(), either... always specify the namespace.
Adds clarity (and clutter, I will admit).

--
Q: What do Winnie the Pooh and John the Baptist have in common?
A: The same middle name.

On 3/24/2024 7:43 AM, Chris Ahlstrom wrote:
> Heh, didn't notice that "template" got chopped to "te". Fumble-fingers!

No. Ignorance in how to toggle "typing replaces selected text".

--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

On 3/20/2024 7:53 PM, Lawrence D'Oliveiro wrote:

> Python does away with that redundancy, by making the indentation serve
> as statement-bracketing as well. I think this is a mistake. However, I
> restore the redundancy by adding “#end” lines (which the compiler
> ignores). E.g.
>
> def parse_headers() :
> nonlocal content_type, content_type_opts
> for keyword, value in scope["headers"] :
> keyword = keyword.decode().lower()
> if keyword == "content-type" :
> content_type = value.decode()
> elif keyword == "cookie" :
> for item in value.decode().split(";") :
> name, val = item.strip().replace(" ", "").split("=", 1)
> cookies[name] = val
> #end for
> #end if
> #end for
> if content_type != None :
> content_type, content_type_opts = \
> multipart.multipart.parse_options_header(content_type)
> content_type = content_type.decode()
> content_type_opts = dict((k.decode(), v) for k, v in content_type_opts.items())
> #end if
> #end parse_headers

Let me fix that back for you:

def parse_headers() :
nonlocal content_type, content_type_opts
for keyword, value in scope["headers"] :
keyword = keyword.decode().lower()
if keyword == "content-type" :
content_type = value.decode()
elif keyword == "cookie" :
for item in value.decode().split(";") :
name, val = item.strip().replace(" ", "").split("=", 1)
cookies[name] = val
if content_type != None :
content_type, content_type_opts = \
multipart.multipart.parse_options_header(content_type)
content_type = content_type.decode()
content_type_opts = dict((k.decode(), v) for k, v in
content_type_opts.items())

much better

On 3/21/2024 11:17 PM, rbowman wrote:
> On Thu, 21 Mar 2024 10:10:33 -0400, Chris Ahlstrom wrote:
>
>> for (int n : { 2, 4, 6, 8 })
>> std::cout << n << ", ";
>>
>> std::cout << "who do we appreciate?" << std::endl
>>
>> (std::endl is \n with a flush.
>
> cout never did much for me either. That's one of the areas that seemed
> like a gratuitous departure from C.
>
> Then there is the Python
>
> print("Never again!", end="\r")

in a console that prints:
r again!

use end="\n", which flushes stdout

in a 'real' program:

import time
for i in range(5):
print(i+1,"Never again!",end='\r',flush=True)
time.sleep(0.5)

On Wed, 27 Mar 2024 14:22:46 -0400, DFS wrote:

> import time for i in range(5):
> print(i+1,"Never again!",end='\r',flush=True)
> time.sleep(0.5)

Odd.

import time

print("start")
for i in range(5):
print("never again!",end='\r')
time.sleep(0.5)
print("\ndone")

You don't need the sleep either.

print(i, "never again!",end='\r')

without the sleep gives

$ python junk.py
start
4 never again!
done

Put the sleep back in and you can see it counting up. It must be a timing
thing in the console. My original use was reading a DHT11 with a Pico
using MicroPython

https://www.mouser.com/datasheet/2/758/DHT11-Technical-Data-Sheet-
Translated-Version-1143054.pdf

The print() output goes to the terminal in VS Code. I wanted the update to
be

temperature: 68.0 F humidity: 36%

and stay on the one line without scrolling each second. You can't read the
DHT11 faster than once a second so it worked fine. end='\n' is the
default for print() and exactly what I didn't want.

On Tue, 26 Mar 2024 10:39:07 -0400, DFS wrote:

> Let me fix that back for you:

You can see why I think this is a mistake.

On 4/3/2024 3:37 AM, Lawrence D'Oliveiro wrote:
> On Tue, 26 Mar 2024 10:39:07 -0400, DFS wrote:
>
>> Let me fix that back for you:
>
> You can see why I think this is a mistake.

I cannot.

def
if
for
if
if
for
if
break

calm

def() {
if () {
for () {
if() {
if() {
for() {
if() {
break
}
}
}
}
}
}
}
}

storm

On Wed, 3 Apr 2024 12:16:50 -0400, DFS wrote:

> I cannot.

Here’s another example. First, without #end comments:

class xattr(ct.Structure) :
_fields_ = \
[
("fsx_xflags", ct.c_uint32),
("fsx_extsize", ct.c_uint32),
("fsx_nextents", ct.c_uint32),
("fsx_projid", ct.c_uint32),
("fsx_cowextsize", ct.c_uint32),
("fsx_pad", 8 * ct.c_ubyte),
]

def copy(self) :
celf = type(self)
res = celf()
for f in celf._fields_ :
setattr(res, f[0], getattr(self, f[0]))
return \
res

def __repr__(self) :
return \
(
"(%s)"
%
", ".join
(
"%%s = %s" % ("%d", "%#0.8x")[f == "fsx_xflags"]
%
(f, getattr(self, f))
for f in
("fsx_xflags", "fsx_extsize", "fsx_nextents", "fsx_projid", "fsx_cowextsize")
)
)

XFLAG_REALTIME = 0x00000001
XFLAG_PREALLOC = 0x00000002

Where does the “xattr” class end? Does it include those symbolic
parameters at the bottom? Can you see that clearly? Compare this way:

class xattr(ct.Structure) :
_fields_ = \
[
("fsx_xflags", ct.c_uint32),
("fsx_extsize", ct.c_uint32),
("fsx_nextents", ct.c_uint32),
("fsx_projid", ct.c_uint32),
("fsx_cowextsize", ct.c_uint32),
("fsx_pad", 8 * ct.c_ubyte),
]

def copy(self) :
celf = type(self)
res = celf()
for f in celf._fields_ :
setattr(res, f[0], getattr(self, f[0]))
#end for
return \
res
#end copy

def __repr__(self) :
return \
(
"(%s)"
%
", ".join
(
"%%s = %s" % ("%d", "%#0.8x")[f == "fsx_xflags"]
%
(f, getattr(self, f))
for f in
("fsx_xflags", "fsx_extsize", "fsx_nextents", "fsx_projid", "fsx_cowextsize")
)
)
#end __repr__

#end xattr

XFLAG_REALTIME = 0x00000001
XFLAG_PREALLOC = 0x00000002

On 4/4/2024 8:54 PM, Lawrence D'Oliveiro wrote:
> On Wed, 3 Apr 2024 12:16:50 -0400, DFS wrote:
>
>> I cannot.
>
> Here’s another example. First, without #end comments:
>
> class xattr(ct.Structure) :
> _fields_ = \
> [
> ("fsx_xflags", ct.c_uint32),
> ("fsx_extsize", ct.c_uint32),
> ("fsx_nextents", ct.c_uint32),
> ("fsx_projid", ct.c_uint32),
> ("fsx_cowextsize", ct.c_uint32),
> ("fsx_pad", 8 * ct.c_ubyte),
> ]
>
> def copy(self) :
> celf = type(self)
> res = celf()
> for f in celf._fields_ :
> setattr(res, f[0], getattr(self, f[0]))
> return \
> res
>
> def __repr__(self) :
> return \
> (
> "(%s)"
> %
> ", ".join
> (
> "%%s = %s" % ("%d", "%#0.8x")[f == "fsx_xflags"]
> %
> (f, getattr(self, f))
> for f in
> ("fsx_xflags", "fsx_extsize", "fsx_nextents", "fsx_projid", "fsx_cowextsize")
> )
> )
>
> XFLAG_REALTIME = 0x00000001
> XFLAG_PREALLOC = 0x00000002
>
> Where does the “xattr” class end?

At the XFLAG REALTIME line.

> Does it include those symbolic parameters at the bottom?

No.

> Can you see that clearly?

I can.

>Compare this way:
>
> class xattr(ct.Structure) :
> _fields_ = \
> [
> ("fsx_xflags", ct.c_uint32),
> ("fsx_extsize", ct.c_uint32),
> ("fsx_nextents", ct.c_uint32),
> ("fsx_projid", ct.c_uint32),
> ("fsx_cowextsize", ct.c_uint32),
> ("fsx_pad", 8 * ct.c_ubyte),
> ]
>
> def copy(self) :
> celf = type(self)
> res = celf()
> for f in celf._fields_ :
> setattr(res, f[0], getattr(self, f[0]))
> #end for
> return \
> res
> #end copy
>
> def __repr__(self) :
> return \
> (
> "(%s)"
> %
> ", ".join
> (
> "%%s = %s" % ("%d", "%#0.8x")[f == "fsx_xflags"]
> %
> (f, getattr(self, f))
> for f in
> ("fsx_xflags", "fsx_extsize", "fsx_nextents", "fsx_projid", "fsx_cowextsize")
> )
> )
> #end __repr__
>
> #end xattr
>
> XFLAG_REALTIME = 0x00000001
> XFLAG_PREALLOC = 0x00000002

I just don't have a problem following Python blocks. Of course if they
go more than one page it's tougher.

But go with what works for you.

My usual editor on Windows and WSL is Notepad++, and it has faint
vertical lines called indent guides, corresponding with the tab widths,
which makes the Python code (or any indented code, with or without
brackets) a touch easier to follow. They're on by default.

https://imgur.com/a/IqfufKA

On Fri, 5 Apr 2024 00:13:14 -0400, DFS wrote:

> My usual editor on Windows and WSL is Notepad++, and it has faint
> vertical lines called indent guides, corresponding with the tab widths,
> which makes the Python code (or any indented code, with or without
> brackets) a touch easier to follow.

So you had to copy and paste the code into your editor before you could
make sense of it? You couldn’t do it unaided?

If that’s how you have to manage your code--whatever works for you, I
guess.

Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:

> On Wed, 3 Apr 2024 12:16:50 -0400, DFS wrote:
>
>> I cannot.
>
> Here’s another example. First, without #end comments:

Snipped because who wants to read Python code?

https://github.com/mathialo/bython

Python with braces.

--
Don't get stuck in a closet -- wear yourself out.

Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 12:35 this Friday (GMT):
> Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:
>
>> On Wed, 3 Apr 2024 12:16:50 -0400, DFS wrote:
>>
>>> I cannot.
>>
>> Here’s another example. First, without #end comments:
>
> Snipped because who wants to read Python code?
>
> https://github.com/mathialo/bython
>
> Python with braces.

I thought python already had braces.
--
user <candycane> is generated from /dev/urandom

On 4/5/2024 1:57 AM, Lawrence D'Oliveiro wrote:
> On Fri, 5 Apr 2024 00:13:14 -0400, DFS wrote:
>
>> My usual editor on Windows and WSL is Notepad++, and it has faint
>> vertical lines called indent guides, corresponding with the tab widths,
>> which makes the Python code (or any indented code, with or without
>> brackets) a touch easier to follow.
>
> So you had to copy and paste the code into your editor before you could
> make sense of it?

Of course not.

bad strawman

candycanearter07 wrote this copyrighted missive and expects royalties:

> Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 12:35 this Friday (GMT):
>> Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:
>>
>>> On Wed, 3 Apr 2024 12:16:50 -0400, DFS wrote:
>>>
>>>> I cannot.
>>>
>>> Here’s another example. First, without #end comments:
>>
>> Snipped because who wants to read Python code?
>>
>> https://github.com/mathialo/bython
>>
>> Python with braces.
>
> I thought python already had braces.

Yes, but not for delimiting the statements in a function.

--
There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
-- Wm. Shakespeare, "Hamlet"

On Fri, 5 Apr 2024 10:25:20 -0400, DFS wrote:

> On 4/5/2024 1:57 AM, Lawrence D'Oliveiro wrote:
>
>> On Fri, 5 Apr 2024 00:13:14 -0400, DFS wrote:
>>
>>> My usual editor on Windows and WSL is Notepad++, and it has faint
>>> vertical lines called indent guides, corresponding with the tab
>>> widths, which makes the Python code (or any indented code, with or
>>> without brackets) a touch easier to follow.
>>
>> So you had to copy and paste the code into your editor before you could
>> make sense of it?
>
> Of course not.

Then why did you need to mention the help your editor gave?

On 4/5/2024 7:20 PM, Lawrence D'Oliveiro wrote:
> On Fri, 5 Apr 2024 10:25:20 -0400, DFS wrote:
>
>> On 4/5/2024 1:57 AM, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 5 Apr 2024 00:13:14 -0400, DFS wrote:
>>>
>>>> My usual editor on Windows and WSL is Notepad++, and it has faint
>>>> vertical lines called indent guides, corresponding with the tab
>>>> widths, which makes the Python code (or any indented code, with or
>>>> without brackets) a touch easier to follow.
>>>
>>> So you had to copy and paste the code into your editor before you could
>>> make sense of it?
>>
>> Of course not.
>
> Then why did you need to mention the help your editor gave?

informing and educating YOU.

Now let it go, wacko.

Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 16:36 this Friday (GMT):
> candycanearter07 wrote this copyrighted missive and expects royalties:
>
>> Chris Ahlstrom <OFeem1987@teleworm.us> wrote at 12:35 this Friday (GMT):
>>> Lawrence D'Oliveiro wrote this copyrighted missive and expects royalties:
>>>
>>>> On Wed, 3 Apr 2024 12:16:50 -0400, DFS wrote:
>>>>
>>>>> I cannot.
>>>>
>>>> Here’s another example. First, without #end comments:
>>>
>>> Snipped because who wants to read Python code?
>>>
>>> https://github.com/mathialo/bython
>>>
>>> Python with braces.
>>
>> I thought python already had braces.
>
> Yes, but not for delimiting the statements in a function.

Oh, right.
--
user <candycane> is generated from /dev/urandom

On Fri, 5 Apr 2024 19:59:33 -0400, DFS wrote:

> On 4/5/2024 7:20 PM, Lawrence D'Oliveiro wrote:
>> On Fri, 5 Apr 2024 10:25:20 -0400, DFS wrote:
>>
>>> On 4/5/2024 1:57 AM, Lawrence D'Oliveiro wrote:
>>>
>>>> On Fri, 5 Apr 2024 00:13:14 -0400, DFS wrote:
>>>>
>>>>> My usual editor on Windows and WSL is Notepad++, and it has faint
>>>>> vertical lines called indent guides, corresponding with the tab
>>>>> widths, which makes the Python code (or any indented code, with or
>>>>> without brackets) a touch easier to follow.
>>>>
>>>> So you had to copy and paste the code into your editor before you
>>>> could make sense of it?
>>>
>>> Of course not.
>>
>> Then why did you need to mention the help your editor gave?
>
> informing and educating YOU.

That you needed help to understand your version of the code? As opposed to
my version, which didn’t need such help?