If you ever want to understand the full value of C++, trying locating and
comprehending this module (it's part of glibc, available at GNU Savannah). It
is used in the implementation of a number of gettext functions.

Ignoring the (to me) screwball coding conventions, it is a morass of calls to
malloc(), free(), alloca(), freea(), strcmp(), strlen(), strdup(), jillions of
pointers to characters and structures, checks for _LIBC, IN_LIBGLOCALE,
__GLIBC__, _LIBICONV_VERSION, calls to lock/unlock functions like
gl_rwlock_rdlock(), gl_rwlock_wrlock(), __libc_lock_lock() ....

It's not that large, about 1700 lines, but man....

--
Q: What lies on the bottom of the ocean and twitches?
A: A nervous wreck.

On Sat, 2 Mar 2024 09:10:36 -0500, Chris Ahlstrom wrote:

> If you ever want to understand the full value of C++, trying locating
> and comprehending this module (it's part of glibc, available at GNU
> Savannah). It is used in the implementation of a number of gettext
> functions.

You're saying a C++ implementation would be better or that C++ hides the
ugly bits under a fig leaf? Have you looked at the way a vtable is
implemented?

I'm not saying C++ is bad but somebody has to do the dirty work. C# is
even cleaner looking and hides even more.

foreach (R r in rats) {
string color = r.furColor;
}

In C++ you'd be knee deep in arcane iterators.

rbowman wrote this copyrighted missive and expects royalties:

> On Sat, 2 Mar 2024 09:10:36 -0500, Chris Ahlstrom wrote:
>
>> If you ever want to understand the full value of C++, trying locating
>> and comprehending this module (it's part of glibc, available at GNU
>> Savannah). It is used in the implementation of a number of gettext
>> functions.
>
> You're saying a C++ implementation would be better or that C++ hides the
> ugly bits under a fig leaf? Have you looked at the way a vtable is
> implemented?

Who cares? Unless you are a compiler designer.

> I'm not saying C++ is bad but somebody has to do the dirty work. C# is
> even cleaner looking and hides even more.
>
> foreach (R r in rats) {
> string color = r.furColor;
> }
>
> In C++ you'd be knee deep in arcane iterators.

Nah.

for (const auto & r : rats)
std::string color = r.furColor

You can replace "const auto &" with just "auto" if you don't need to worry
about the overhead of the copy constructor or the const-ness.

for (auto r : rats)
std::string color = r.furColor

--
You display the wonderful traits of charm and courtesy.

On 2 Mar 2024 19:08:53 GMT, rbowman wrote:

> C# is even cleaner looking and hides even more.

Pity nobody uses Dotnet for anything important. Even Microsoft won’t
entrust anything significant to it.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On 2 Mar 2024 19:08:53 GMT, rbowman wrote:
>
>> C# is even cleaner looking and hides even more.
>
>Pity nobody uses Dotnet for anything important. Even Microsoft won’t
>entrust anything significant to it.

I wouldn't even use objects in C++, much less "C#".

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Sat, 2 Mar 2024 16:32:39 -0500, Chris Ahlstrom wrote:

>> You're saying a C++ implementation would be better or that C++ hides
>> the ugly bits under a fig leaf? Have you looked at the way a vtable is
>> implemented?
>
> Who cares? Unless you are a compiler designer.

If you're trying to squeeze out the last bit of speed it helps to know
what C++ is doing under the hood.

rbowman wrote this copyrighted missive and expects royalties:

> On Sat, 2 Mar 2024 16:32:39 -0500, Chris Ahlstrom wrote:
>
>>> You're saying a C++ implementation would be better or that C++ hides
>>> the ugly bits under a fig leaf? Have you looked at the way a vtable is
>>> implemented?
>>
>> Who cares? Unless you are a compiler designer.
>
> If you're trying to squeeze out the last bit of speed it helps to know
> what C++ is doing under the hood.

Maybe. I'll trust the compiler writer over my own experience.

One of my programs reads command-line arguments, reads a bunch of INI-style
configuration files, adjusts as needed for the command-line arguments, and
rereads the configuration files based on that. The configuration-file scanning
is brute force... read in the whole file, and then search over and over for
each option. Very wasteful (and I will fix that in "version 2").

And yet the GUI app comes up completely populated in a second.

Even in a Windows VM it is a second or two.

Obviously one size does not fit all, though, and your point is well taken.

--
You will overcome the attacks of jealous associates.

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

> On 2 Mar 2024 19:08:53 GMT, rbowman wrote:
>
>> C# is even cleaner looking and hides even more.
>
> Pity nobody uses Dotnet for anything important. Even Microsoft won’t
> entrust anything significant to it.

I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
Javascript, and even SRSS (Microsoft's "Crystal Reports").

I was happy to get off of that project, especially since the lead developer was
an arrogant asshole cowboy coder who tended to brush off customer requirements
and complaints. But he owned two Mercedes sedans :-D.

After he left the company (apparently my successor filed a complaint to HR
about him), another guy took over. I worked very briefly, and the project was
even more of a Frankenstein monster, adding "Mustache" and some other tech
that I've forgotten.

It was nice to see what Javascript could do, though.

--
The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"

On Sun, 3 Mar 2024 10:21:13 -0500, Chris Ahlstrom wrote:

> I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
> Javascript, and even SRSS (Microsoft's "Crystal Reports").

SRSS is a piece of work but Power BI is actually usable to produce the eye
candy managers love. It's one of the few report packages that there might
be some hope of a manager being able to use by himself.

> After he left the company (apparently my successor filed a complaint to
> HR about him), another guy took over. I worked very briefly, and the
> project was even more of a Frankenstein monster, adding "Mustache" and
> some other tech that I've forgotten.
>
> It was nice to see what Javascript could do, though.

I did a couple of web maps with Node.js and the Express framework
generator. There are several choices but I always went with the Handlebars
engine. It's very similar to Mustache.

We also did a web SPA with Angular. It uses TypeScript which is helpful if
you use it right. There's a temptation to use 'any' which defeats the
purpose. I mostly worked on the map portion and fortunately Esri has an
Angular package. Their first JavaScript API used AMD with Dojo which was
not not compatible with CommonJS. Going to ES2015 was a definite
improvement.

On Sun, 3 Mar 2024 10:15:45 -0500, Chris Ahlstrom wrote:

> One of my programs reads command-line arguments, reads a bunch of
> INI-style configuration files, adjusts as needed for the command-line
> arguments, and rereads the configuration files based on that. The
> configuration-file scanning is brute force... read in the whole file,
> and then search over and over for each option. Very wasteful (and I will
> fix that in "version 2").

For better or worse working with the Esri API pit me in the COM world

pApp = AfxGetApp();
m_nCrossStreetAngle = pApp->GetProfileInt(_T("Data"),
_T("CrossStreetAngle"), 45);

strDatabase = pApp->GetProfileString(_T("Data"),_T("Database"),_T(""));

makes that relatively painless. Our C apps also read from an ini style
file but a library makes handles the grunt work so it's similar.

allow_alt_cfs = GetLogiOptBool("xmstat", "allow alternate cfs", 0);

For the newer apps I went to JSON rather than ini. ConfigurationBuilder
in .NET streamlines the process and you can suck in a JSON file and the
environment variables in one shot.

On Sun, 3 Mar 2024 10:21:13 -0500, Chris Ahlstrom wrote:

> I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
> Javascript, and even SRSS (Microsoft's "Crystal Reports").

Wot, no PHP? SQL?

> It was nice to see what Javascript could do, though.

It has some remarkably good parts. Strict mode helps.

On Sun, 3 Mar 2024 20:04:41 -0000 (UTC), Lawrence D'Oliveiro wrote:

> On Sun, 3 Mar 2024 10:21:13 -0500, Chris Ahlstrom wrote:
>
>> I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
>> Javascript, and even SRSS (Microsoft's "Crystal Reports").
>
> Wot, no PHP? SQL?

We have a programmer who likes PHP; we try to limit the damage. Something
that started as Personal Home Page so Aunt Tillie could put her casserole
recipes on the web doesn't inspire confidence.

SSRS == SQL Server Reporting Services.
>> It was nice to see what Javascript could do, though.
>
> It has some remarkably good parts. Strict mode helps.

Douglas Crockford's 'JavaScript: The Good Parts' was good in its day but
its day was 2008. He does have a newer book 'How JavaScript Works' that I
haven't read.

rbowman <bowman@montana.com> wrote at 02:42 this Monday (GMT):
> On Sun, 3 Mar 2024 20:04:41 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> On Sun, 3 Mar 2024 10:21:13 -0500, Chris Ahlstrom wrote:
>>
>>> I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
>>> Javascript, and even SRSS (Microsoft's "Crystal Reports").
>>
>> Wot, no PHP? SQL?
>
> We have a programmer who likes PHP; we try to limit the damage. Something
> that started as Personal Home Page so Aunt Tillie could put her casserole
> recipes on the web doesn't inspire confidence.
>
> SSRS == SQL Server Reporting Services.
>
>>> It was nice to see what Javascript could do, though.
>>
>> It has some remarkably good parts. Strict mode helps.
>
> Douglas Crockford's 'JavaScript: The Good Parts' was good in its day but
> its day was 2008. He does have a newer book 'How JavaScript Works' that I
> haven't read.
>

JS and PHP are both way overused.
--
user <candycane> is generated from /dev/urandom

rbowman wrote this copyrighted missive and expects royalties:

> On Sun, 3 Mar 2024 10:15:45 -0500, Chris Ahlstrom wrote:
>
>> One of my programs reads command-line arguments, reads a bunch of
>> INI-style configuration files, adjusts as needed for the command-line
>> arguments, and rereads the configuration files based on that. The
>> configuration-file scanning is brute force... read in the whole file,
>> and then search over and over for each option. Very wasteful (and I will
>> fix that in "version 2").
>
> For better or worse working with the Esri API pit me in the COM world
>
> pApp = AfxGetApp();
> m_nCrossStreetAngle = pApp->GetProfileInt(_T("Data"),
> _T("CrossStreetAngle"), 45);
>
> strDatabase = pApp->GetProfileString(_T("Data"),_T("Database"),_T(""));
>
> makes that relatively painless. Our C apps also read from an ini style
> file but a library makes handles the grunt work so it's similar.
>
> allow_alt_cfs = GetLogiOptBool("xmstat", "allow alternate cfs", 0);
>
> For the newer apps I went to JSON rather than ini. ConfigurationBuilder
> in .NET streamlines the process and you can suck in a JSON file and the
> environment variables in one shot.

JSON is cool. The main reason I'm sticking with INI here is legacy, and
because there isn't much in the way of nested configuration items.

I've had people ask me to switch to XML. No way. Too bulky; INI is
easier for a human to edit if they want to.

--
Are you a turtle?

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

> On Sun, 3 Mar 2024 10:21:13 -0500, Chris Ahlstrom wrote:
>
>> I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
>> Javascript, and even SRSS (Microsoft's "Crystal Reports").
>
> Wot, no PHP? SQL?

MS-SQL (Transact SQL) was used, and accessed in C#.

>> It was nice to see what Javascript could do, though.
>
> It has some remarkably good parts. Strict mode helps.

Another story. So I got the database queries and reports working well.
The "manager" was happy with them. Then the "cowboy" calls us into a
meeting room and basically says "We're scrapping that work."

I could tell the "manager" was flabbergasted. But he acceded to the "cowboy".

So what was the big change? The "cowboy" discovered he could use SQL to
write SQL statements. My god the stuff was almost undebuggable! I swear this
asshole was trying to see if he could make me fail.

After doing that crap for a bit, I was happy to take on a completely different
project. The "manager" had absolutely no sway with that guy.

--
A tall, dark stranger will have more fun than you.

rbowman wrote this copyrighted missive and expects royalties:

> On Sun, 3 Mar 2024 20:04:41 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> On Sun, 3 Mar 2024 10:21:13 -0500, Chris Ahlstrom wrote:
>>
>>> I worked for awhile on a project that was a mishmash of C#, .NET, HTML,
>>> Javascript, and even SRSS (Microsoft's "Crystal Reports").
>>
>> Wot, no PHP? SQL?
>
> We have a programmer who likes PHP; we try to limit the damage. Something
> that started as Personal Home Page so Aunt Tillie could put her casserole
> recipes on the web doesn't inspire confidence.
>
> SSRS == SQL Server Reporting Services.
>
>>> It was nice to see what Javascript could do, though.
>>
>> It has some remarkably good parts. Strict mode helps.
>
> Douglas Crockford's 'JavaScript: The Good Parts' was good in its day but
> its day was 2008. He does have a newer book 'How JavaScript Works' that I
> haven't read.

The book I studied from was something like "Object-Oriented Javascript".

--
You should emulate your heros, but don't carry it too far. Especially
if they are dead.

On 4 Mar 2024 02:42:11 GMT, rbowman wrote:

> We have a programmer who likes PHP; we try to limit the damage.

That deserves a “LOL” if anything does. ;)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 20:56 this Monday (GMT):
> On 4 Mar 2024 02:42:11 GMT, rbowman wrote:
>
>> We have a programmer who likes PHP; we try to limit the damage.
>
> That deserves a “LOL” if anything does. ;)

LOL
--
user <candycane> is generated from /dev/urandom

On Mon, 4 Mar 2024 13:02:08 -0500, Chris Ahlstrom wrote:

> So what was the big change? The "cowboy" discovered he could use SQL to
> write SQL statements. My god the stuff was almost undebuggable! I swear
> this asshole was trying to see if he could make me fail.

We had a support person who came up with a SQL statement to query a DB2
database for archived want/warrant information. It was a work of art and I
have no idea how long it took him to come up with it. At one point it
failed on older DB2 versions that only supported a 4k buffer for queries.

He used a lot of the scalar functions to try to extract a first, middle,
and last name from a full name, did a lot of other manipulations, and
glued it all together with concat. It was all one line with no formatting.
If any of the little twists failed you got nothing at all. I never did
figure it out.

I can get the job done with SQL but I prefer to break it down into bite
sized chunks and use C or C++ for preprocessing strings, formatting dates,
and the like.

On Mon, 4 Mar 2024 12:53:52 -0500, Chris Ahlstrom wrote:

> JSON is cool. The main reason I'm sticking with INI here is legacy, and
> because there isn't much in the way of nested configuration items.

Tell me about legacy :) I got a chuckle one day when another programmer
asked how something was handled. 'Well, according to the comments in the
code, you wrote the function in 1997.'

> I've had people ask me to switch to XML. No way. Too bulky; INI is
> easier for a human to edit if they want to.

It started with the DOJ wanting one schema to rule them all. Particularly
after 9/11 there was a big push about information sharing between
agencies. Of course it never happened because the agencies have their own
little fiefdoms and give zero fucks about sharing anything.

https://en.wikipedia.org/wiki/GJXDM

NCIC and the state CJIN people got into it. I never worked with Wisconsin
so this is an example I found on the web. It's fairly typical with a half
dozen or more namespaces. The best part is ones like <j:ID/> are
contextual. It might be a SSN, OLN, plate number, or who knows what.

https://www.doj.state.wi.us/sites/default/files/etime-schemas/
version2013v01/ncic/WINCICResponse_ViolentPerson.xml

The returns used to be reasonably well formatted plain text. Now I have to
write XSLT stylesheets to beat the mess into some sort of human readable
format.

Hey, Larry, how's your XSLT fu? Make that page look pretty. Oh, I forgot.
You're not interested in skills someone might actually pay you to use. Oh
well.