"Jonathan Blow: "C++ is a weird mess""

[Lynn McGuire]

"Jonathan Blow: "C++ is a weird mess""

https://www.gamesindustry.biz/articles/2018-07-02-jonathan-blow-c-is-a-weird-mess

Just because one is correct does not mean that one's solutions are any
better.

Lynn

[Juha Nieminen]

Lynn McGuire <lynnmc...@gmail.com> wrote:
> "Jonathan Blow: "C++ is a weird mess""
>
> https://www.gamesindustry.biz/articles/2018-07-02-jonathan-blow-c-is-a-weird-mess

"There are only two kinds of languages: the ones people complain about and
the ones nobody uses." - Bjarne Stroustrup

[SG]

True. And C++ being a weird mess seems to be well-accepted:

"Within C++, there is a much smaller and cleaner language
struggling to get out." -- Bjarne Stroustrup

Though, I see Blow's language with mixed feelings, too. There are
some nice things about it (super fast compiler, incredibly powerful metaprogramming) but a lot of the design decisions just seem weird.
For example, in one of his videos he says destructors in C++ were a
bad idea and in another video he introduces a special pointer syntax
for an "owning" pointer which frees memory automatically. That just
seems like cognitive dissonance to me. While I think there are
points to be made for certain things to be core language features
rather than library-provided tools (I'm looking at you, std::tuple &
std::variant), I think unique ownership pointers aren't one of them
and the better design is to make the language powerful enough
(--> destructors) to create things like unique_ptr as a library. If
you have destructors, you get more than just convenient memory
management without introducing a rather limited core-language feature.

Let's see how this Jai turns out ...

Cheers!
sg

[Bart]

On 10/07/2018 10:41, SG wrote:
> On Tuesday, July 10, 2018 at 1:15:09 AM UTC+2, Lynn McGuire wrote:
>> Jonathan Blow: "C++ is a weird mess"
>>
>> https://www.gamesindustry.biz/articles/2018-07-02-jonathan-blow-c-is-a-weird-mess
>>
>> Just because one is correct does not mean that one's solutions are any
>> better.
>
> True. And C++ being a weird mess seems to be well-accepted:
>
> "Within C++, there is a much smaller and cleaner language
> struggling to get out." -- Bjarne Stroustrup
>
> Though, I see Blow's language with mixed feelings, too. There are
> some nice things about it (super fast compiler,

According to the LLVM link on this page (I won't link direct to the
youtube video so as not to bring down the tone of this group):

https://inductive.no/jai/

the compiler is not so fast at the moment as it relies on LLVM to do the
code generation.

That example uses a 34KLoc example program, and takes some 2.5 seconds
source to executable (I think the version using a C compiler back-end is
somewhat faster).

The 'front-end', what he calls compiling to byte-code, is about 0.2
seconds, so that's pretty fast (about 170Klps). But even if that was
all, it wouldn't be 'super-fast'.

(My own compiler projects at the moment are considerably faster than
even that front end, and the compilers are not themselves optimised
other. But I would still hesitate to call that super-fast; I think I'd
reserve that for 1Mlps and above. I've only occasionally breached that.)

Interesting BTW that he's using a Windows machine for development (one
using SSD too as is mentioned at one point; mine just has a regular
HDD), rather than the usual Linux. To hear people on these groups tell
it, Windows is hopeless for software development.

> Let's see how this Jai turns out ...

The language snippets I saw didn't really grab me. I can't get a sense
of its 'shape' or identity. I think we need to see more complete programs.

--
bart

[Thiago Adams]

On Tuesday, July 10, 2018 at 6:41:20 AM UTC-3, SG wrote:
...

> For example, in one of his videos he says destructors in C++ were a
> bad idea and in another video he introduces a special pointer syntax
> for an "owning" pointer which frees memory automatically.

I didn't find the videos.Do you have the links?

[Bo Persson]

I think the real insight is

"As a project gets bigger the longer it takes to make changes, Blow
explains, and the nature of programming means that significant amounts
of time get dedicated to "what is essentially busywork."

without him fully realizing that.


I have seen the "new system"-syndrome in real life:

We had a group of guys starting to build a new service from scratch in
C# on a bunch of empty Windows servers. The management soon saw that
they churned out code twice as fast as us old guys on the mainframe
(with tons of interfaces to existing systems).

So, apparently, .NET was the silver bullet to solve the productivity
problem for the company!

Unfortunately, a year later the C# guys started on a second project and
soon realized that now they would also have to consider existing systems
and adapt their new code to what they already had.

And they also had to hire techies to run and maintain the servers now
that their system was in 24/7 production.

Not long after that, the productivity gap had mysteriously disappeared.


So, starting from scratch might look promising initially, but...


Bo Persson

[Bart]

Try: https://inductive.no/jai/

[Rick C. Hodgin]

On 7/10/2018 8:48 AM, Bo Persson wrote:
> So, starting from scratch might look promising initially, but...

It is generally foolish to start from scratch. Building on the labor
of prior efforts is most desirable. But still there are valid reasons
to do it. If you don't have desirable licensing for the software, then
you have to start from scratch. If you have specific goals that aren't
possible otherwise from the software at hand (such as my case with CAlive
where I wish to create something from inception designed to honor my
Lord and Savior Jesus Christ, that's simply something not possible using
existing software that was from inception created for other purposes
(Matthew 12:30)). And there are reasons relating to innate design. It
is sometimes better to start over than it is to refactor. But...

It takes A LOT of work to author, debug, and adequately expand soft-
ware to meet the needs of a reasonable project. It is almost always
better to take what you have, sit down in long planning meetings, re-
group, refocus, rewrite portions, document what you have, extend the
API, add additional code, remove or combine lesser-used code, and
perform some kinds of general refactoring than it is to start from
scratch.

I'm also realizing the sometime benefits of simple things like flat
data files, console-based interfaces for increased productivity in
certain circumstances, the ability to have complex viewers available
at the debugger level, etc.

"The right tool for the right job" takes on increasing meaning the
more "advanced" I get in my development.

I'm also beginning to see just how far we went off course embracing
OS designs like Windows. It would've been better to extend DOS to
include driver frameworks which run atop the existing API. Code for
DOS was so much simpler than code for a modern OS. And it doesn't
need to be more complex today. A similar API extended to facilitate
the needs of user requirements would've been doable. In fact, I'm
thinking the further I get into design and support for development
of my OS, just how much should be removed for greater simplicity. A
modern 64-bit OS with GUI abilities should be able to run in a few
MB of source code. It does this by sticking closer to the hardware,
and further away from abstraction. But, we'll see. I could be wrong.

--
Rick C. Hodgin

[bol...@cylonhq.com]

I'm immediately suspicious when someone calls a programming language "exciting".
Languages may be useful, interesting or clever, but they're never exciting.
Overuse of hyperbole using means a load of tedious crap is to follow. Mind you,
he's certainly been busy writing his own praises on wikipedia. I'm thinking
Mr Blow is a good case of nominative determinism.

[Thiago Adams]

Maybe is this one:

Constructors, Destructors
https://youtu.be/8C6zuDDGU2w?list=PLmV5I2fxaiCKfxMBrNsU1kgKJXD3PkyxO

[Vir Campestris]

On 10/07/2018 11:41, Bart wrote:
> To hear people on these groups tell it, Windows is hopeless for software
> development.

IMHO Visual Studio is the best IDE out there.

These days I'm writing semi-embedded Linux stuff, and I miss Visual
Studio. I haven't found a Linux one as good.

Andy

[Ian Collins]

Visual Studio Code?

https://code.visualstudio.com/

--
Ian.

[Lynn McGuire]

+1,000,000

Lynn

[bitrex]

C++ is a good language to write functional sections that need to be
high-performance and utilized as "black box" modules, in some other
language, in.

[Vir Campestris]

I'll have a look. Thanks. It wasn't around when I was last looking for a
tool.

Andy

[Ian Collins]

Most of out ex-Windows developers use it. It's an excellent tool for
anyone moving to Linux who is used to Visual Studio.

--
Ian.

[Rick C. Hodgin]

From Visual Studio 2015 on VS supports GDB directly from the Visual
Studio Debugger.

Visual Studio GDB Debugger
https://www.youtube.com/watch?v=-3toI8L3Oug

--
Rick C. Hodgin

[Rick C. Hodgin]

To be clear about this, you can do Linux development by having
a Windows VM running in Linux, installing Visual Studio in there.
You can share a network drive to access your Linux partition,
and do direct development in Visual Studio on your Linux OS and
disk.

You can cooperatively do VS development, and other development.
VS has always been able to use the GCC toolchain (with MinGW or
CYGWIN) from inside VS using 3rd party compilation tools. It
is simply more integrated now from VS2015 on.

VS2017 is also free to download and use for open source projects,
or single-developer projects:

https://visualstudio.microsoft.com/vs/community/

Single developer:

"Any individual developer can use Visual Studio Community to
create their own free or paid apps."

Open source:

"An unlimited number of users within an organization can use
Visual Studio Community for the following scenarios: in a
classroom learning environment, for academic research, or
for contributing to open source projects."

--
Rick C. Hodgin

[Ian Collins]

On 14/07/18 11:41, Rick C. Hodgin wrote:
> On 7/13/2018 7:12 PM, Rick C. Hodgin wrote:
>> On 7/13/2018 6:46 PM, Ian Collins wrote:
>>> Most of out ex-Windows developers use it. It's an excellent tool for anyone
>>> moving to Linux who is used to Visual Studio.
>>
>> From Visual Studio 2015 on VS supports GDB directly from the Visual
>> Studio Debugger.
>>
>>     Visual Studio GDB Debugger
>>     https://www.youtube.com/watch?v=-3toI8L3Oug
>
>
> To be clear about this, you can do Linux development by having
> a Windows VM running in Linux, installing Visual Studio in there.
> You can share a network drive to access your Linux partition,
> and do direct development in Visual Studio on your Linux OS and
> disk.

There are many ways of doing Linux development, that is possibly the worst.

If you are doing Linux development and like Microsoft tools, use Visual
Studio Code. If you prefer a Windows desktop, use Visual Studio for
development and WSL for your native builds.

--
Ian.

[Alf P. Steinbach]

Assuming WSL means Windows Subsystem for Linux, and further assuming
that that's the beast that one can install by enabling dev-mode in
Windows 10, well I tried it and as of Windows 10 it's still a beta.
About the first it did was mess up a few files: the integration between
the file systems is sort of alpha, if at all tested. I uninstalled it
quickly.

Better to run a real Linux in a virtual box or on separate machine.

The integration with Windows is better in VirtualBox than what I got
with WSL. WSL is just nothing like the earlier Subsystem for Unix.

I can understand that people enable dev-mode in order to get symbolic
links enabled though, but instead of symlinks I just use `mklink /j
source ...` to create junctions for out of source VS projects. It works
fine except that Visual Studio, as probably opposed to the compiler's
handling of `#pragma once`, doesn't understand that a file accessed via
two different paths are the same file, so a little annoying when I just
double-click a diagnostic, fix something and rebuild: hey, changes made
outside of the editor, would you like to reload, blah blah...

Of course I forgot all about that behavior when some MS system (VS?
their web pages?) recently asked what I'd like improved in VS. I just
answered speed of getting up and running, and of loading solutions. But
really, when I /consider/ it, what they first should fix in order to
please just me, would be recognition of different paths = same file.


Cheers!,

- Alf

[Ian Collins]

Odd, probably 40-50 developers on my team are running it!

> Better to run a real Linux in a virtual box or on separate machine.

Real machine, yes, Virtual Box - no. We used to work that way but
dumped it in favour of WSL (which is effectively Ubuntu on Windows) or
docker for Linux builds.

--
Ian

[Chris M. Thomasson]

On 7/13/2018 4:41 PM, Rick C. Hodgin wrote:
> On 7/13/2018 7:12 PM, Rick C. Hodgin wrote:
>> On 7/13/2018 6:46 PM, Ian Collins wrote:
>>> Most of out ex-Windows developers use it. It's an excellent tool for
>>> anyone moving to Linux who is used to Visual Studio.
>>
>> From Visual Studio 2015 on VS supports GDB directly from the Visual
>> Studio Debugger.
>>
>>      Visual Studio GDB Debugger
>>      https://www.youtube.com/watch?v=-3toI8L3Oug
>
>
> To be clear about this, you can do Linux development by having
> a Windows VM running in Linux, installing Visual Studio in there.

Why do that? If you want an IDE, just install Linux, then a Linux
version of an IDE that you like, perhaps, say:

https://code.visualstudio.com/insiders/#linux

Or any other Linux IDE.

Of course, one can just use VIM. Command line? Sure. No problem.

Side note:

Sometimes I think there can be an "addictive" quality to IDE's...

[...]

[Rick C. Hodgin]

Using Visual Studio, you can do the bulk of your development with
native MSVC++ and Visual Studio tools, including its native debugger,
edit-and-conntinue abilities, and then do your periodic compiles with
GCC/GDB and do testing through the same tool and interface.

--
Rick C. Hodgin

[Rick C. Hodgin]

On 7/14/2018 12:25 AM, Chris M. Thomasson wrote:
> Sometimes I think there can be an "addictive" quality to IDE's...

Have you ever used Visual Studio? There is no comparison in other
tools to that developer platform. I've never seen another one that
even comes close. The integration, the edit-and-continue, the ease
of debugging.

It is the most powerful x86-based debugging tool I've ever seen.

If you have one that's on par, I'll look at it as I truly hate
Microsoft and seek to leave their OS and tools forever.

--
Rick C. Hodgin

[Kenny McCormack]

In article <picoiu$d0k$3...@dont-email.me>,

You shouldn't be singing the praises of their flagship product and then
claiming to hate them. It just doesn't wash.

Not, of course, that you and spouting nonsense aren't already on a first
name basis with each other.

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.

[Rick C. Hodgin]

On 7/14/2018 11:18 AM, Kenny McCormack wrote:
> In article <picoiu$d0k$3...@dont-email.me>,
> Rick C. Hodgin <rick.c...@gmail.com> wrote:
>> Have you ever used Visual Studio? There is no comparison in other
>> tools to that developer platform. I've never seen another one that
>> even comes close. The integration, the edit-and-continue, the ease
>> of debugging.
>>
>> It is the most powerful x86-based debugging tool I've ever seen.
>>
>> If you have one that's on par, I'll look at it as I truly hate
>> Microsoft and seek to leave their OS and tools forever.
>
> You shouldn't be singing the praises of their flagship product and then
> claiming to hate them. It just doesn't wash.

Why not? It's the best software developer tool there is. At least
until I get CAlive's IDE working. Nyuck nyuck. :-)

> Not, of course, that you and spouting nonsense aren't already on a first
> name basis with each other.

Oh. Harsh. Tell me, Kenny (may I call you Kenny?), what color is
the sky in your world?

--
Rick C. Hodgin

[Hergen Lehmann]

Am 14.07.2018 um 13:59 schrieb Rick C. Hodgin:

> Have you ever used Visual Studio?  There is no comparison in other
> tools to that developer platform.  I've never seen another one that
> even comes close.  The integration, the edit-and-continue, the ease
> of debugging.

The IDE may be good, but this is immediately put to waste by the
horrible C++ compiler which comes with it.

In my experience, it is slow, produces inefficient code (compared to
Intel or mingw), is still not fully compliant with the standard
(although the current iteration has come much closer), and frequently
produces completely incomprehensible error messages.

> It is the most powerful x86-based debugging tool I've ever seen.

I'm in C/C++ development for more than 30 years now, and in my
experience a good compiler (fast, compliant, with meaningful warnings
and errors) spares much more time than a good debugger. Which is kind of
last-resort anyways - if you spend much time in the debugger, your
design and/or your unit tests were bad.

The difference is so big, that i'm developing new code on Linux most of
the time these days, using the "pretty" Visual Studio merely as a
bare-bone compiler for production builds...

[Rick C. Hodgin]

On 7/14/2018 12:27 PM, Hergen Lehmann wrote:
> Am 14.07.2018 um 13:59 schrieb Rick C. Hodgin:
>
>> Have you ever used Visual Studio?  There is no comparison in other
>> tools to that developer platform.  I've never seen another one that
>> even comes close.  The integration, the edit-and-continue, the ease
>> of debugging.
>
> The IDE may be good, but this is immediately put to waste by the horrible C++
> compiler which comes with it.
>
> In my experience, it is slow, produces inefficient code (compared to Intel or
> mingw), is still not fully compliant with the standard (although the current
> iteration has come much closer), and frequently produces completely
> incomprehensible error messages.

Have you seen statistics?

In addition, you can use 3rd party compilers with Visual Studio.
Intel's compilers integrate directly. You simply need to choose
your target compiler when compiling and Visual Studio does the
rest for you.

The edit-and-continue abilities of the MSVC++ compiler make its
development worthwhile. When you need to do a release build
with greater optimization, then use the other tool.

>> It is the most powerful x86-based debugging tool I've ever seen.
>
> I'm in C/C++ development for more than 30 years now, and in my experience a
> good compiler (fast, compliant, with meaningful warnings and errors) spares
> much more time than a good debugger. Which is kind of last-resort anyways -
> if you spend much time in the debugger, your design and/or your unit tests
> were bad.

All developer work differently. I like an edit-and-continue
compiler, and don't really care that much about performance.
99.9% of the apps I develop run fast enough for what their
target is, and usually the slowest component is the user.

> The difference is so big, that i'm developing new code on Linux most of the
> time these days, using the "pretty" Visual Studio merely as a bare-bone
> compiler for production builds...

Glad it works for you that way. Keep on keepin' on. :-)

--
Rick C. Hodgin

[Rick C. Hodgin]

On 7/14/2018 12:27 PM, Hergen Lehmann wrote:

> Am 14.07.2018 um 13:59 schrieb Rick C. Hodgin:
>
>> Have you ever used Visual Studio?  There is no comparison in other
>> tools to that developer platform.  I've never seen another one that
>> even comes close.  The integration, the edit-and-continue, the ease
>> of debugging.
>
> The IDE may be good, but this is immediately put to waste by the horrible C++
> compiler which comes with it.

I'm curious about this thinking. As a developer, I spend most of my
time writing code. I want to be in a capable tool to minimize the time
I spend spinning my wheels, or doing repetitive tasks that are better
handled by the tool I'm using.

As such, the IDE, the integrated debugger that is so power and easy to
use, these add up to a far greater component during development. It is
only then later, after the code is developed, that performance becomes
an issue.

How is it that your development cycle is otherwise, and to such an ex-
tent you would abandon Visual Studio and use another toolset which may
not have the powerful IDE abilities of Visual Studio, all because the
compiler is perhaps faster to compile, and produces more optimized
code?

Why would you be doing your development in optimized code anyway? It
takes notably longer to compile, and you lose the ability to have all
of your symbols across certain optimizations.

I would think you would want to do development in a debug mode with
few optimizations, and then when finished do some final testing in a
release mode with full optimizations.

-----
Can you explain the mindset? How much time do you gain with the
faster compiler and more optimized code during hours, days, weeks,
months, years, of developer time at the keyboard writing and testing
code?

--
Rick C. Hodgin

[Hergen Lehmann]

Am 14.07.2018 um 18:41 schrieb Rick C. Hodgin:

>> In my experience, it is slow, produces inefficient code (compared to
>> Intel or mingw), is still not fully compliant with the standard
>> (although the current iteration has come much closer), and frequently
>> produces completely incomprehensible error messages.
>
> Have you seen statistics?

In my current main project (which is mostly network I/O and
multi-threaded, sequential processing without much potential for local
optimizations), i experience a difference in code efficiency of around
30%-50%, with another 30-50% being caused by the operating system. In
the end, the same code is on average twice as fast on Linux/g++ compared
to Windows/msvc++ (with Windows/Intel somewhere in-between). That's a lot!

> In addition, you can use 3rd party compilers with Visual Studio.
> Intel's compilers integrate directly.  You simply need to choose
> your target compiler when compiling and Visual Studio does the
> rest for you.

Yeah, but the Intel compiler is production-only and way too slow for
quick edit-and-testing cycles. gcc/mingw on the other hand does NOT
integrate into Visual Studio, while clang is still alpha on Windows. And
that's it for the well-established compilers.

In the end, there is no real alternative during development. I either
had to live with the crude MSVC++ or switch to a completely different
development platform - which i did in the end, because i was tired of
thinking whether me or the compiler is dumb all the time.

> The edit-and-continue abilities of the MSVC++ compiler make its
> development worthwhile.

Unfortunately, that doesn't work to well with C++. Many edits affect
header files and in turn require re-compilation and re-linking of larger
parts of the code - which takes more than twice the time on MSVC++
compared to g++.

> All developer work differently.  I like an edit-and-continue
> compiler, and don't really care that much about performance.
> 99.9% of the apps I develop run fast enough for what their
> target is, and usually the slowest component is the user.

Well, i'm in the server business. While in most installations
performance is just "good enough", others are pushing the limits or
gradually grew into that state.
Unfortunately, these are also the ones, where the customer pays lots of
money for a 24/7 service contract and expects a quick response to
anything which may pop up, including performance issues.

[Rick C. Hodgin]

On 7/14/2018 2:25 PM, Hergen Lehmann wrote:
> Am 14.07.2018 um 18:41 schrieb Rick C. Hodgin:
>
>>> In my experience, it is slow, produces inefficient code (compared to Intel
>>> or mingw), is still not fully compliant with the standard (although the
>>> current iteration has come much closer), and frequently produces
>>> completely incomprehensible error messages.
>>
>> Have you seen statistics?
>
> In my current main project (which is mostly network I/O and multi-threaded,
> sequential processing without much potential for local optimizations), i
> experience a difference in code efficiency of around 30%-50%, with another
> 30-50% being caused by the operating system. In the end, the same code is on
> average twice as fast on Linux/g++ compared to Windows/msvc++ (with
> Windows/Intel somewhere in-between). That's a lot!

30% to 50% is a lot. But if the code is running a simple text editor,
the user will never see it.

Is it a bottleneck in network processing on your system? Does it need
that extra 30% to 50% to handle maximum network throughput?

>> In addition, you can use 3rd party compilers with Visual Studio.
>> Intel's compilers integrate directly.  You simply need to choose
>> your target compiler when compiling and Visual Studio does the
>> rest for you.
>
> Yeah, but the Intel compiler is production-only and way too slow for quick
> edit-and-testing cycles. gcc/mingw on the other hand does NOT integrate into
> Visual Studio, while clang is still alpha on Windows. And that's it for the
> well-established compilers.

Visual Studio 2015 and 2017 do integrate GCC into their toolchain:

At 1:01:
www.youtube.com/watch?v=-3toI8L3Oug&t=1m1s

At 1:47 he speaks about the MinGW environment, and how to setup
the compiler so it works in an NMake environment.

> In the end, there is no real alternative during development. I either had to
> live with the crude MSVC++ or switch to a completely different development
> platform - which i did in the end, because i was tired of thinking whether me
> or the compiler is dumb all the time.

Got it.

I've been looking since the early 2000s for a better platform. I found
one that was close on Solaris, but it's no longer supported outside of
proprietary software models, so that's a dead-end.

>> The edit-and-continue abilities of the MSVC++ compiler make its
>> development worthwhile.
>
> Unfortunately, that doesn't work to well with C++. Many edits affect header
> files and in turn require re-compilation and re-linking of larger parts of
> the code - which takes more than twice the time on MSVC++ compared to g++.

It depends on how you do your development. If you're doing things that
require some major recompilation, break out your source files into much
smaller files with only those functions you're working on at the moment,
and then it will compile much faster, and the change code applied will
be much faster.

Having the ability to maintain your place in the app, your existing data
already processed, and update your algorithm is, to me, a far greater
asset.

>> All developer work differently.  I like an edit-and-continue
>> compiler, and don't really care that much about performance.
>> 99.9% of the apps I develop run fast enough for what their
>> target is, and usually the slowest component is the user.
>
> Well, i'm in the server business. While in most installations performance is
> just "good enough", others are pushing the limits or gradually grew into that
> state.

I have some server software I use and have written on my server, but I
don't have such high traffic that it is ever performance limited. In
fact, I typically don't see even 10% CPU usage when a dozen or more users
are on my site.

> Unfortunately, these are also the ones, where the customer pays lots of money
> for a 24/7 service contract and expects a quick response to anything which
> may pop up, including performance issues.

Those are constraints unique to a business model. They are not for
everyone.

The projects I work with are primarily in-house developed projects,
and we provide a similar service but performance related to compute
is not an issue, though we do have some performance issues with our
backend database. I also work on open source projects, and I do have
some performance issues on my GUI, but it's because I'm doing a thing
a particular way by choice. It enables a feature that I find to be a
desirable thing, but it does impact performance. I get about 6 fps
max on business forms, and for some people that's an issue.

I'll stick with MSVC++ for nearly everything, and cringe each time I
have to go to a GCC+GDB or other Linux-based toolchain.

[Hergen Lehmann]

Am 14.07.2018 um 20:12 schrieb Rick C. Hodgin:

>> The IDE may be good, but this is immediately put to waste by the
>> horrible C++ compiler which comes with it.
>
> I'm curious about this thinking.  As a developer, I spend most of my
> time writing code.  I want to be in a capable tool to minimize the time
> I spend spinning my wheels, or doing repetitive tasks that are better
> handled by the tool I'm using.

Yeah, and the most important tool is the compiler itself.

I need to trust it that
- the code behaves the way it should according to the language standard,
- the optimizer works well enough that i do not need to spend many hours
optimizing the source code and can put emphasis on readability,
- error/warning messages point right to the issue,
- the turnaround time between editing, compiling and testing is quick
enough to immediately test every small change.

> As such, the IDE, the integrated debugger that is so power and easy to
> use, these add up to a far greater component during development.

The IDE is mostly an editor for me.

I rarely use the debugger, because the code is studded with lots of
consistency checks and debug output, which can be turned on on demand.
I need to take this approach, because the application is running 24/7 on
permanent load in production scenarios, and i simply cannot reproduce
most errors by single-stepping through it.
Multi-threading is another hurdle. Did you ever try to step through a
piece of code in the debugger, which is executed by a dozen threads at
the same time?
And some parts don't even work in the debugger, because network
communication will run into timeouts.

> How is it that your development cycle is otherwise, and to such an ex-
> tent you would abandon Visual Studio and use another toolset which may
> not have the powerful IDE abilities of Visual Studio, all because the
> compiler is perhaps faster to compile, and produces more optimized
> code?

As i said, i need to trust the compiler. I cannot trust MSVC++, because
it still has lots of shortcomings and deviations from the language
standard. Each and every error may be on my part or on the compiler's.

Some developers try to avoid these hurdles by collecting experience with
the compilers quirks and writing MSVC-optimized code, but i definitely
don't want to go this way at a time where MS's influence is dwindling
and their strategists try to push everyone away from C/C++ and into
their own C#.

> Why would you be doing your development in optimized code anyway?  It
> takes notably longer to compile,

On MSVC, yes. With g++ or clang, compilation speed isn't much affected
by optimization settings, while at the same time the optimization
results are much better.

But the main reason is, that parts of the code simply run too slow in
their non-optimized version to meet protocol requirements. C++ and
especially the STL relies *A LOT* on optimization by the compiler!

> Can you explain the mindset?  How much time do you gain with the
> faster compiler and more optimized code during hours, days, weeks,
> months, years, of developer time at the keyboard writing and testing
> code?

Depends on the development phase.
When adding new stuff, good turnaround times save at least an hour every
day for code writing and testing.
When doing production builds, good automatic optimization saves LOTS of
hours for optimizing the source code and even more hours by avoiding the
errors resulting from heavily optimized (hardly readable) source code.

[Vir Campestris]

On 14/07/2018 17:27, Hergen Lehmann wrote:
> The IDE may be good, but this is immediately put to waste by the
> horrible C++ compiler which comes with it.

You're absolutely right. It got worse - we were writing managed C++,
because we wanted the power of C++ and the pretty front ends from C#.

C++ will do more than C#.

Anything you couldn't do in C# the debugger didn't understand.

This was 5 years ago, mind.

I did try Visual Studio talking to a Linux box. For a couple of weeks.
It just doesn't understand the filesystem - kept setting the execute bit
on source files for example. I gave up.

BTW @Chris - one of our guys uses EMACS...

Andy

[Hergen Lehmann]

Am 14.07.2018 um 21:00 schrieb Rick C. Hodgin:

> 30% to 50% is a lot.  But if the code is running a simple text editor,
> the user will never see it.
>
> Is it a bottleneck in network processing on your system?  Does it need
> that extra 30% to 50% to handle maximum network throughput?

It's around 30% for algorithm-oriented stuff and more towards 50% when
multi-threading comes into place.

In regards to network throughput, the difference between Windows and
Linux may even reach several 100%. Of course, that's very likely not the
compiler's fault. The API concepts (epoll vs. IOCP) are fundamentally
different and my understatement of the rather complex IOCP may not be
good enough to fully utilize its power. Although a windows expert
consulted back than did not find anything, i'm doing totally wrong...

> Visual Studio 2015 and 2017 do integrate GCC into their toolchain:
>
>     At 1:01:
>     www.youtube.com/watch?v=-3toI8L3Oug&t=1m1s

You did oversee the split-second in which he did click on
"cross-platform". It's only supported for cross-compilation, not for
Windows development. :-(

>> Unfortunately, that doesn't work to well with C++. Many edits affect
>> header files and in turn require re-compilation and re-linking of
>> larger parts of the code - which takes more than twice the time on
>> MSVC++ compared to g++.
>
> It depends on how you do your development.  If you're doing things that
> require some major recompilation, break out your source files into much
> smaller files with only those functions you're working on at the moment,
> and then it will compile much faster, and the change code applied will
> be much faster.

My project is already split into lots of rather small, independent cpp
files. But that does shift the compiler workload even more towards the
interface headers and increases the chance that a change does indeed
have to take place in one of these headers...

> I'll stick with MSVC++ for nearly everything, and cringe each time I
> have to go to a GCC+GDB or other Linux-based toolchain.

For me, it's the other way around.
System APIs are much more straightforward and easier to overlook on
Posix-like systems, while the two major compilers (g++,clang) stick very
close to the language standards. Saves a lot of time figuring out the
differences between theory and practice.
When switching over to Windows towards the end of the development phase,
i already have proven code and do only need to figure out the MSVC++
twirks...

[Chris M. Thomasson]

On 7/15/2018 1:38 AM, Hergen Lehmann wrote:
> Am 14.07.2018 um 21:00 schrieb Rick C. Hodgin:
>
>> 30% to 50% is a lot.  But if the code is running a simple text editor,
>> the user will never see it.
>>
>> Is it a bottleneck in network processing on your system?  Does it need
>> that extra 30% to 50% to handle maximum network throughput?
>
> It's around 30% for algorithm-oriented stuff and more towards 50% when
> multi-threading comes into place.
>
> In regards to network throughput, the difference between Windows and
> Linux may even reach several 100%. Of course, that's very likely not the
> compiler's fault. The API concepts (epoll vs. IOCP) are fundamentally
> different and my understatement of the rather complex IOCP may not be
> good enough to fully utilize its power. Although a windows expert
> consulted back than did not find anything, i'm doing totally wrong...

Fwiw, I used to work with IOCP all the time back in WinNT 4.0.

It can scale. However, it has some interesting quirks.

https://groups.google.com/d/msg/comp.lang.c++/kAz1VAxD2lI/WqeBMQZtAwAJ

https://groups.google.com/forum/#!topic/comp.lang.c++/kAz1VAxD2lI/overview
(read all, there is an interesting discussion about IOCP in there...)

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx

(read all)

The system is fairly nice. Love the following function:

https://docs.microsoft.com/en-us/windows/desktop/FileIO/getqueuedcompletionstatusex-func

Grab a bunch of completions at once! Not available back then in nt4.
Argh! ;^)

[Richard]

[Please do not mail me a copy of your followup]

Bart <b...@freeuk.com> spake the secret code
<N301D.952718$463.5...@fx21.am4> thusly:

>[...] To hear people on these groups tell

>it, Windows is hopeless for software development.

Because those of us who find ourselves productive in Windows have long
since given up on the /. type bigots and their endless whinging.

...but back to the topic of the article. This is like the 40th time
that someone has complained about C++ and introduced a new language to
"solve" the problems that C++ has.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<pi36j6$t2i$4...@dont-email.me> thusly:

>On 10/07/2018 11:41, Bart wrote:

>> To hear people on these groups tell it, Windows is hopeless for software
>> development.
>

>IMHO Visual Studio is the best IDE out there.
>
>These days I'm writing semi-embedded Linux stuff, and I miss Visual
>Studio. I haven't found a Linux one as good.

CLion comes close. Visual Studio Code is well respected as an editor
on linux.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>

[snip]

> Visual Studio Code is well respected as an editor
>on linux.

Hm. Never even heard it referred to outside of this usenet forum.

Well respected by who in the linux community?

We have many linux programmers internally, and aside from a couple
of interns who used eclipse, everyone else uses vim or emacs.

[woodb...@gmail.com]

I use a mixture of vim and emacs to this day.

Do Windows 10 programs still require a WSAStartup call?
Getting rid of that is one thing Windows could do to be
less annoying. They should have done it 10 years ago
though.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Rick C. Hodgin]

On 7/17/2018 3:12 PM, woodb...@gmail.com wrote:
> Do Windows 10 programs still require a WSAStartup call?
> Getting rid of that is one thing Windows could do to be
> less annoying. They should have done it 10 years ago
> though.

WSAStartup() is only required for apps that use windows
sockets. Other apps have no need for it, so why would
every app auto-call it?

--
Rick C. Hodgin

[Alf P. Steinbach]

On 17.07.2018 21:12, woodb...@gmail.com wrote:
> On Tuesday, July 17, 2018 at 1:16:51 PM UTC-5, Scott Lurndal wrote:
>> legaliz...@mail.xmission.com (Richard) writes:
>>> [Please do not mail me a copy of your followup]
>>>
>> [snip]
>>
>>> Visual Studio Code is well respected as an editor
>>> on linux.
>>
>> Hm. Never even heard it referred to outside of this usenet forum.
>>
>> Well respected by who in the linux community?
>>
>> We have many linux programmers internally, and aside from a couple
>> of interns who used eclipse, everyone else uses vim or emacs.
>
> I use a mixture of vim and emacs to this day.
>
> Do Windows 10 programs still require a WSAStartup call?
> Getting rid of that is one thing Windows could do to be
> less annoying. They should have done it 10 years ago
> though.

WSAStartup is an initialization of the Winsocks library. It's needed if
you use Winsocks, and not otherwise. The only library that every Windows
desktop program has to use is Kernel32, because it provides the
ExitProcess function.

Undocumented: you can simply return instead of calling ExitProcess. Or
at least that used to be the case. It's been some years.


Cheers & hth.,

- Alf

[Lynn McGuire]

On 7/17/2018 12:47 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Bart <b...@freeuk.com> spake the secret code
> <N301D.952718$463.5...@fx21.am4> thusly:
>
>> [...] To hear people on these groups tell
>> it, Windows is hopeless for software development.
>
> Because those of us who find ourselves productive in Windows have long
> since given up on the /. type bigots and their endless whinging.
>
> ...but back to the topic of the article. This is like the 40th time
> that someone has complained about C++ and introduced a new language to
> "solve" the problems that C++ has.

Shoot, it could the 400th time.

Lynn

[Ian Collins]

On 18/07/18 06:16, Scott Lurndal wrote:
> legaliz...@mail.xmission.com (Richard) writes:
>> [Please do not mail me a copy of your followup]
>>
> [snip]
>
>> Visual Studio Code is well respected as an editor
>> on linux.
>
> Hm. Never even heard it referred to outside of this usenet forum.
>
> Well respected by who in the linux community?

All of our native Linux developers except for me and probably most
others who come from a windows background.

> We have many linux programmers internally, and aside from a couple
> of interns who used eclipse, everyone else uses vim or emacs.

The same Linux programmers who don't know how to use smart pointers
efficiently?

--
Ian.

[woodb...@gmail.com]

I know. I don't want to have to call it at all.


Brian

[jacobnavia]

Le 17/07/2018 à 19:47, Richard a écrit :
> This is like the 40th time
> that someone has complained about C++ and introduced a new language to
> "solve" the problems that C++ has.

Most people do not develop a new language but use a subset of C++. For
instance NASA, in its Curiosity rover software has used following C++
subset:
(https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20on%20Mars%20-%20Incorporating%20C%2B%2B%20into%20Mars%20Rover%20Flight%20Software/C%2B%2B%20On%20Mars%20-%20Mark%20Maimone%20-%20CppCon%202014.pdf)
<quote>
So we limited our code to “Embedded C++” constructs
Exceptions: none
Templates: none
Iostream: none
Multiple inheritance: none
Operator overloading: almost none (only “new” and
“delete”).
Dynamic Allocation: Guarantee no system heap corruption
using a dedicated memory pool and Placement New
<end quote>

[Richard]

[Please do not mail me a copy of your followup]

>On 18/07/18 06:16, Scott Lurndal wrote:

>> We have many linux programmers internally, and aside from a couple
>> of interns who used eclipse, everyone else uses vim or emacs.

I'm always amazed at the number of C/C++ developers that haven't
upgraded their development environment in 30+ years. By this point, I
would have expected that all the emacs afficionados would have
automated refactoring implemented in elisp, but nope. They have
essentially the same environment I had in 1988.

[bol...@cylonhq.com]

On Wed, 18 Jul 2018 19:14:18 +0200
jacobnavia <ja...@jacob.remcomp.fr> wrote:
>Le 17/07/2018 à 19:47, Richard a écrit :
>> This is like the 40th time
>> that someone has complained about C++ and introduced a new language to
>> "solve" the problems that C++ has.
>
>Most people do not develop a new language but use a subset of C++. For
>instance NASA, in its Curiosity rover software has used following C++
>subset:
>(https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20on%20
>Mars%20-%20Incorporating%20C%2B%2B%20into%20Mars%20Rover%20Flight%20Software/C%
>2B%2B%20On%20Mars%20-%20Mark%20Maimone%20-%20CppCon%202014.pdf)
><quote>
>So we limited our code to “Embedded C++” constructs
>Exceptions: none
>Templates: none
>Iostream: none
>Multiple inheritance: none

Does multiple inheritance get used much anyway? I can count the number of times
I've seen it in my 20+ year career on one hand. To me it seems like one of
those features that should be useful but almost never is because composition
or aggregation are almost always a better solution.

[Rosario19]

On Thu, 19 Jul 2018 08:44:24 +0000 (UTC), boltar wrote:
>On Wed, 18 Jul 2018 19:14:18 +0200
>jacobnavia <jacob> wrote:
>>Le 17/07/2018 à 19:47, Richard a écrit :
>>> This is like the 40th time
>>> that someone has complained about C++ and introduced a new language to
>>> "solve" the problems that C++ has.
>>
>>Most people do not develop a new language but use a subset of C++. For
>>instance NASA, in its Curiosity rover software has used following C++
>>subset:
>>(https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20on%20
>>Mars%20-%20Incorporating%20C%2B%2B%20into%20Mars%20Rover%20Flight%20Software/C%
>>2B%2B%20On%20Mars%20-%20Mark%20Maimone%20-%20CppCon%202014.pdf)
>><quote>

>>So we limited our code to “Embedded C++�€? constructs
>>Exceptions: none

this seems to me ok... each function return error if can, and each
that call see if some error (if this is important)

>>Templates: none

where templates are the problem? the code that has <int> is traslated
as it is one int type in what i understand

>>Iostream: none

than one has to write his own routines... seems ok, if one not
introduce bugs (one can rewrite iostream eliminate their i presume bug
(can not possible to check for sucessfull/wrong input or remember it
wrong? because i rewrote getint getdouble with cin input etc))

possible now make error more than usual because some grappa

>>Multiple inheritance: none

i don't know the meaning...

[Rosario19]

On Thu, 19 Jul 2018 12:07:45 +0200, Rosario19 wrote:

>On Thu, 19 Jul 2018 08:44:24 +0000 (UTC), boltar wrote:
>>On Wed, 18 Jul 2018 19:14:18 +0200
>>jacobnavia <jacob> wrote:
>>>Le 17/07/2018 à 19:47, Richard a écrit :
>>>> This is like the 40th time
>>>> that someone has complained about C++ and introduced a new language to
>>>> "solve" the problems that C++ has.
>>>
>>>Most people do not develop a new language but use a subset of C++. For
>>>instance NASA, in its Curiosity rover software has used following C++
>>>subset:
>>>(https://github.com/CppCon/CppCon2014/blob/master/Presentations/C%2B%2B%20on%20
>>>Mars%20-%20Incorporating%20C%2B%2B%20into%20Mars%20Rover%20Flight%20Software/C%
>>>2B%2B%20On%20Mars%20-%20Mark%20Maimone%20-%20CppCon%202014.pdf)
>>><quote>
>>>So we limited our code to “Embedded C++�€? constructs
>>>Exceptions: none
>
>this seems to me ok... each function return error if can, and each
>that call see if some error (if this is important)

"exceptions" could be ok in some exceptional case
but i could be wrong on this (and in all the remain)
this is just my opinion

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>>On 18/07/18 06:16, Scott Lurndal wrote:
>
>>> We have many linux programmers internally, and aside from a couple
>>> of interns who used eclipse, everyone else uses vim or emacs.
>
>I'm always amazed at the number of C/C++ developers that haven't
>upgraded their development environment in 30+ years. By this point, I
>would have expected that all the emacs afficionados would have
>automated refactoring implemented in elisp, but nope. They have
>essentially the same environment I had in 1988.

If it works for them, why should they change?

[Scott Lurndal]

bol...@cylonHQ.com writes:

>
>Does multiple inheritance get used much anyway? I can count the number of times
>I've seen it in my 20+ year career on one hand. To me it seems like one of
>those features that should be useful but almost never is because composition
>or aggregation are almost always a better solution.
>

From a current project:

class c_xyz: public c_device,
public c_tx_sink_interface,
public c_tx_src_interface,
public c_rx_sink_interface,
public c_rx_src_interface,
public c_memory_accessors


class c_zyx: public c_device,
public c_thread,
public c_memory_accessors,
public c_pci_callback


Granted in most cases the secondary base classes are
pure virtual interface classes (c_thread is an exception
to that - it automatically creates a thread and invokes the
derived class 'run' function from that thread after the
derived class constructor completes).

[bol...@cylonhq.com]

On Thu, 19 Jul 2018 14:29:52 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:
>bol...@cylonHQ.com writes:
>
>>
>>Does multiple inheritance get used much anyway? I can count the number of
>times
>>I've seen it in my 20+ year career on one hand. To me it seems like one of
>>those features that should be useful but almost never is because composition
>>or aggregation are almost always a better solution.
>>
>
>From a current project:
>
>class c_xyz: public c_device,
> public c_tx_sink_interface,
> public c_tx_src_interface,
> public c_rx_sink_interface,
> public c_rx_src_interface,
> public c_memory_accessors
>
>
>class c_zyx: public c_device,

I hope your real class names are better than c_xyz and c_zyx!

> public c_thread,
> public c_memory_accessors,
> public c_pci_callback
>
>
>Granted in most cases the secondary base classes are
>pure virtual interface classes (c_thread is an exception
>to that - it automatically creates a thread and invokes the
>derived class 'run' function from that thread after the
>derived class constructor completes).

And if the derived class constructor doesn't complete but throws an exception?
Presumably you have to tell the thread not to bother in the exception handler.
That seems a rather obtuse and error prone way to obtain a new thread.

[Scott Lurndal]

bol...@cylonHQ.com writes:
>On Thu, 19 Jul 2018 14:29:52 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>bol...@cylonHQ.com writes:
>>
>>>
>>>Does multiple inheritance get used much anyway? I can count the number of
>>times
>>>I've seen it in my 20+ year career on one hand. To me it seems like one of
>>>those features that should be useful but almost never is because composition
>>>or aggregation are almost always a better solution.
>>>
>>
>>From a current project:
>>
>>class c_xyz: public c_device,
>> public c_tx_sink_interface,
>> public c_tx_src_interface,
>> public c_rx_sink_interface,
>> public c_rx_src_interface,
>> public c_memory_accessors
>>
>>
>>class c_zyx: public c_device,
>
>I hope your real class names are better than c_xyz and c_zyx!

Yes, they were altered to avoid exposing proprietary designators.

>
>> public c_thread,
>> public c_memory_accessors,
>> public c_pci_callback
>>
>>
>>Granted in most cases the secondary base classes are
>>pure virtual interface classes (c_thread is an exception
>>to that - it automatically creates a thread and invokes the
>>derived class 'run' function from that thread after the
>>derived class constructor completes).
>
>And if the derived class constructor doesn't complete but throws an exception?

They cannot, by design.

[Vir Campestris]

30 years ago I was writing C. C worked for me, why should I change?

Andy

[Ian Collins]

30 years ago I had a 13" CRT. C worked for me, why should I change?

--
Ian

[bol...@cylonhq.com]

On Thu, 19 Jul 2018 15:43:12 GMT

sc...@slp53.sl.home (Scott Lurndal) wrote:
>bol...@cylonHQ.com writes:
>Yes, they were altered to avoid exposing proprietary designators.

I doubt a class name is going to give us any insight into your proprietary
code.

>>>Granted in most cases the secondary base classes are
>>>pure virtual interface classes (c_thread is an exception
>>>to that - it automatically creates a thread and invokes the
>>>derived class 'run' function from that thread after the
>>>derived class constructor completes).
>>
>>And if the derived class constructor doesn't complete but throws an exception?
>
>
>They cannot, by design.

It still seems a very obtuse way to obtain a thread. Perhaps its just because
I prefer things to be explicit as it makes it a lot easier to maintain and
debug. If someone in my team ever wrote code that created a thread in a
base class constructor that then called a method in a child class I'd throw it
back at them and tell them to rewrite it in a sane manner.

[Scott Lurndal]

False analogy.

In any case, there is quite a bit of C code still being developed
and maintained.

[Scott Lurndal]

bol...@cylonHQ.com writes:
>On Thu, 19 Jul 2018 15:43:12 GMT
>sc...@slp53.sl.home (Scott Lurndal) wrote:
>>bol...@cylonHQ.com writes:
>>Yes, they were altered to avoid exposing proprietary designators.
>
>I doubt a class name is going to give us any insight into your proprietary
>code.

no point in taking chances.

>
>>>>Granted in most cases the secondary base classes are
>>>>pure virtual interface classes (c_thread is an exception
>>>>to that - it automatically creates a thread and invokes the
>>>>derived class 'run' function from that thread after the
>>>>derived class constructor completes).
>>>
>>>And if the derived class constructor doesn't complete but throws an exception?
>>
>>
>>They cannot, by design.
>
>It still seems a very obtuse way to obtain a thread. Perhaps its just because
>I prefer things to be explicit as it makes it a lot easier to maintain and
>debug. If someone in my team ever wrote code that created a thread in a
>base class constructor that then called a method in a child class I'd throw it
>back at them and tell them to rewrite it in a sane manner.

It works just like this:

https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html

"There are two ways to create a new thread of execution. One is
to declare a class to be a subclass of Thread. This subclass
should override the run method of class Thread. An instance
of the subclass can then be allocated and started."

[Thiago Adams]

The problem I see is not check the new just because
the old is working. What is important is to check the
new and compare with the old.
Something new is not necessary better, but people
tend to like more the new and think it is better.
This is natural considering we want to improve something
and not to make it worst.

For computer languages I think all ideas must be taken
in account, but also it doesn't mean that we need a new
language for that. Sometimes is easy insert new ideas
into an existing language.

For instance, one feature I like in C++ is the
member initializer for non static member.
This was added latter and its fine.

[bol...@cylonhq.com]

On Fri, 20 Jul 2018 13:32:43 GMT

Its always good to be reminded why I gave up on java and went back to C++.

[Richard]

[Please do not mail me a copy of your followup]

Vir Campestris <vir.cam...@invalid.invalid> spake the secret code

<piqs7v$l3$3...@dont-email.me> thusly:

>30 years ago I was writing C. C worked for me, why should I change?

If your needs haven't progressed beyond what you were writing 30 years
ago, then no need to change. A current example of where that might be
the case is coding for small embedded processors. There is limited
memory and ROM storage space, so the kinds of situations where large
scale problems appear just don't occur.

However, I find myself working in larger problem spaces now and C
doesn't scale well to larger code bases because of its limited ability
to express abstractions directly in code.

[Cholo Lennon]

On 07/17/2018 02:47 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
> <pi36j6$t2i$4...@dont-email.me> thusly:
>
>> On 10/07/2018 11:41, Bart wrote:
>>> To hear people on these groups tell it, Windows is hopeless for software
>>> development.
>>
>> IMHO Visual Studio is the best IDE out there.
>>
>> These days I'm writing semi-embedded Linux stuff, and I miss Visual
>> Studio. I haven't found a Linux one as good.
>
> CLion comes close. Visual Studio Code is well respected as an editor
> on linux.

My problem with CLion (and Eclipse CDT) is the slow code indexing, it's
really slow. Qt Creator and Visual Studio don't have this problem. I use
CMake in all cases.



--
Cholo Lennon
Bs.As.
ARG

[Ian Collins]

Qt Creator and Visual Studio aren't written in (spit) Java.

--
Ian.

[Cholo Lennon]

Yeah, good point :-) To be fair, IntelliJ and Eclipse JEE work very well
with big Java projects. What is more, I don't know why CLion and Eclipse
CDT perform a full reindex every time I open a project, that's
unnecessary IMO :-O

[woodb...@gmail.com]

On Friday, July 20, 2018 at 3:51:57 PM UTC-5, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
> <piqs7v$l3$3...@dont-email.me> thusly:
>
> >30 years ago I was writing C. C worked for me, why should I change?
>
> If your needs haven't progressed beyond what you were writing 30 years
> ago, then no need to change. A current example of where that might be
> the case is coding for small embedded processors. There is limited
> memory and ROM storage space, so the kinds of situations where large
> scale problems appear just don't occur.
>
> However, I find myself working in larger problem spaces now and C
> doesn't scale well to larger code bases because of its limited ability
> to express abstractions directly in code.
>

I wonder if 2011 C++ is the new C. I think a lot of people,
myself included, have been surprised by the staying power of
a language like C. Just as there have been some tweaks to C
over the years, there will need to be a few to 2011 C++ --
support for string_view would be an obvious one.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
https://github.com/Ebenezer-group/onwards

[Ian Collins]

On 22/07/18 10:15, woodb...@gmail.com wrote:
> On Friday, July 20, 2018 at 3:51:57 PM UTC-5, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
>> <piqs7v$l3$3...@dont-email.me> thusly:
>>
>>> 30 years ago I was writing C. C worked for me, why should I change?
>>
>> If your needs haven't progressed beyond what you were writing 30 years
>> ago, then no need to change. A current example of where that might be
>> the case is coding for small embedded processors. There is limited
>> memory and ROM storage space, so the kinds of situations where large
>> scale problems appear just don't occur.
>>
>> However, I find myself working in larger problem spaces now and C
>> doesn't scale well to larger code bases because of its limited ability
>> to express abstractions directly in code.
>>
>
> I wonder if 2011 C++ is the new C. I think a lot of people,
> myself included, have been surprised by the staying power of
> a language like C. Just as there have been some tweaks to C
> over the years, there will need to be a few to 2011 C++ --
> support for string_view would be an obvious one.

There have been, c++14 and C++17, which includes std::string_view.

--
Ian.

[woodb...@gmail.com]

I don't think all of those are needed -- the last two
standards seem to be producing mixed results. I wish
I could say that 2020 C++ was going to fix everything,
but I'm skeptical at this point.


Brian

[Ian Collins]

C++14 was as much a bug fix and clean up of C++11 as anything, so it's
an incremental improvement. I see no evidence of it producing mixed
results, what have you seen?

C++17 is new, so the jury is still out.

--
Ian.

[Vir Campestris]

Unless you are seriously resource constrained I think C++ is a better
tool than C. But C still has its place.

I can't imagine why you should want to use a tool that was designed back
in the 1970s (or maybe 1988) these days, unless you have to. I use VI
from time to time - git checkins, for example. But there are better
editors for more complex work.

But I guess we'll have to agree to differ on this :)

Andy

[Thiago Adams]

On Friday, July 20, 2018 at 5:51:57 PM UTC-3, Richard wrote:
...

> However, I find myself working in larger problem spaces now and C
> doesn't scale well to larger code bases because of its limited ability
> to express abstractions directly in code.

I would like to understand better what you want to say.
More abstract code scale better? How? Maybe because you can
do the same think in less lines of code?

I believe C can scale well. (Maybe SOs are a good sample?)

One case where C would not scale well is let's say you
build a container (like map something like that) and
then you have to duplicate the code and create other
containers because you don't have templates.
Then at some point you realize that the
implementation should be a little bit different, and then is
hard to change all the implementations (duplicate code) you have.
The C alternatives to solve this problem are not so easy as
well.

But I would like to hear other opinions about this.

[Richard]

[Please do not mail me a copy of your followup]

Thiago Adams <thiago...@gmail.com> spake the secret code
<69dfd33d-78fc-4d44...@googlegroups.com> thusly:

>On Friday, July 20, 2018 at 5:51:57 PM UTC-3, Richard wrote:
>...
>> However, I find myself working in larger problem spaces now and C
>> doesn't scale well to larger code bases because of its limited ability
>> to express abstractions directly in code.
>
>I would like to understand better what you want to say.
>More abstract code scale better? How? Maybe because you can
>do the same think in less lines of code?

C only has two facilities for abstraction: the struct and the function.

While it is possible to build abstract data types on top of these two
things (e.g. every "handle" based API in existence), the language
doesn't really help you out. You can't do things like use 3D vectors
or 3D points naturally with transformation matrices. (I often work
in the 3D graphics problem domain.) Everything has to be written in
terms of function calls instead of the natural notation of the problem
space. This is one of the problem domains that is very "mathematical"
in nature and overloading the arithemetic operators makes very good
sense.

Even outside of a mathematically oriented problem domain, I can't
express object-oriented relationships between concepts directly in C.
I have to invent my own virtual function mechanism using function
pointers and the whole thing is very fragile. It can be done, but it
requires significant programmer discipline in order to avoid bugs due
to the manual nature of the mechanisms that you must use in C because
the language doesn't support the construct directly. A good example
is the abstractions in the X Window System server -- everything is
done in an object-oriented way *by hand* because the server was
written in C in order to obtain the most portability at the time.
(The Xserver predates widespread adoption of C++.)

>I believe C can scale well. (Maybe SOs are a good sample?)

It can be done, but the language doesn't support sufficient
abstraction mechanisms in order for the scaling to be done well.

>One case where C would not scale well is let's say you
>build a container (like map something like that) and
>then you have to duplicate the code and create other
>containers because you don't have templates.

Yes, this is another example where C has insufficient abstraction
mechanisms to avoid code duplication, but this is not the kind of
scaling I'm talking about.

[Richard]

[Please do not mail me a copy of your followup]

Cholo Lennon <cholo...@hotmail.com> spake the secret code
<piudpj$1ndl$1...@gioia.aioe.org> thusly:

They continue to improve it over time. However the consequence of the
extensive indexing is that the refactoring is much more accurate than
other tools. ReSharper for C++ and CLion routinely get the best
scores on my refactoring test suite[1]. I don't know how much of the
slowness is due to the implementation being in Java/C#. It's a "road
not taken" hypothesis and the only way to get a fair measurement would
be to reimplement the entire system in C++ and spend a lot of time
tuning the C++. I guarantee you that they spend time tuning the IDE
and improve it over time as I have witnessed many improvements over
time. I used CLion on the LLVM/clang codebase, which is *huge*. This
was a couple years ago, so I haven't tested more recent builds but I
expect them to be much faster.

[1] <https://github.com/LegalizeAdulthood/refactor-test-suite>

[Richard]

[Please do not mail me a copy of your followup]

Cholo Lennon <cholo...@hotmail.com> spake the secret code

<pivt1o$4os$1...@gioia.aioe.org> thusly:

>Yeah, good point :-) To be fair, IntelliJ and Eclipse JEE work very well
>with big Java projects. What is more, I don't know why CLion and Eclipse
>CDT perform a full reindex every time I open a project, that's
>unnecessary IMO :-O

File bugs. JetBrains is much more responsive to my bug reports than
other software vendors.

[jacobnavia]

Le 23/07/2018 à 17:40, Richard a écrit :
> One case where C would not scale well is let's say you
> build a container (like map something like that) and
> then you have to duplicate the code and create other
> containers because you don't have templates.

Look at the C containers library. The code is available for free at:

https://github.com/shiva/ccl

I use simply a set of macros to define a container for any type <T>

jacob navia

[Thiago Adams]

I already sent my comments on comp lang c for this lib
some time ago.

[jacobnavia]

I do not remember all threads you started, sorry.

I told you that "some time ago"...

:-)

In any case, for the people that do not read that threads, care to comment?

[Richard]

[Please do not mail me a copy of your followup]

ja...@jacob.remcomp.fr spake the secret code
<pj57gs$4g1$1...@dont-email.me> thusly:

>Le 23/07/2018 à 17:40, Richard a écrit :
>> One case where C would not scale well is let's say you
>> build a container (like map something like that) and
>> then you have to duplicate the code and create other
>> containers because you don't have templates.

Nit: I didn't write the above.

[Lynn McGuire]

On 7/19/2018 3:44 AM, bol...@cylonHQ.com wrote:
...

> Does multiple inheritance get used much anyway? I can count the number of times
> I've seen it in my 20+ year career on one hand. To me it seems like one of
> those features that should be useful but almost never is because composition
> or aggregation are almost always a better solution.

Yes, we use multiple inheritance to combine a modeless MFC dialog with
our own private dialog class. Worked well.

Lynn

[Lynn McGuire]

class ViewSummary : public CDialog, public DesDialog
{
// Construction
public:
ViewSummary(CWnd* pParent = NULL); // standard constructor

// Dialog Data
//{{AFX_DATA(ViewSummary)
enum { IDD = IDD_VIEWSUMMARY };
//}}AFX_DATA

CString m_documentName;

COLORREF m_crConvergence;


// Overrides
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(ViewSummary)
public:
virtual BOOL Create(CWnd* pParentWnd, CString documentName);
//virtual BOOL Create(LPCTSTR lpszClassName, LPCTSTR lpszWindowName,
DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID,
CCreateContext* pContext = NULL);
protected:
virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
virtual void PostNcDestroy();
virtual LRESULT DefWindowProc(UINT message, WPARAM wParam, LPARAM
lParam) override;
//}}AFX_VIRTUAL

// Implementation
protected:

// Generated message map functions
//{{AFX_MSG(ViewSummary)
virtual void OnOK();
afx_msg void OnDblclk101();
afx_msg void OnDblclk201();
virtual BOOL OnInitDialog();
afx_msg void OnTheWorks();
afx_msg void OnMaterialBalance();
afx_msg void OnStreamSummary();
afx_msg void OnDetailedStream();
afx_msg void OnEquipmentSummary();
afx_msg void OnCaseStudyOnly();
afx_msg void OnGoToErrorPage();
afx_msg void OnGoToIndexPage();
afx_msg BOOL OnHelpInfo(HELPINFO* pHelpInfo);
afx_msg void OnHelp();
afx_msg void OnConfigurationOptions();
afx_msg void OnAllStreams();
afx_msg void OnSelectedStreams();
afx_msg void OnDblclk112();
afx_msg void OnAddOne();
afx_msg void OnAddAll();
afx_msg void OnRemove();
afx_msg void OnToTop();
afx_msg void OnMoveUp();
afx_msg void OnMoveDown();
afx_msg void OnToBottom();
afx_msg HBRUSH OnCtlColor (CDC* pDC, CWnd* pWnd, UINT nCtlColor);
afx_msg void OnDrawItem (int nIDCtl, LPDRAWITEMSTRUCT lpDrawItemStruct);
//}}AFX_MSG
DECLARE_MESSAGE_MAP()

virtual void OnCancel();
void getSolutionMessage (FILE *of);
void initListBoxes (FILE *of);

};

Lynn

[Cholo Lennon]

On 07/23/2018 12:45 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Cholo Lennon <cholo...@hotmail.com> spake the secret code
> <pivt1o$4os$1...@gioia.aioe.org> thusly:
>
>> Yeah, good point :-) To be fair, IntelliJ and Eclipse JEE work very well
>> with big Java projects. What is more, I don't know why CLion and Eclipse
>> CDT perform a full reindex every time I open a project, that's
>> unnecessary IMO :-O
>
> File bugs. JetBrains is much more responsive to my bug reports than
> other software vendors.

That's good to know, I'll do it.

[Thiago Adams]

On Monday, July 23, 2018 at 7:18:01 PM UTC-3, Lynn McGuire wrote:

I think you are using inheritance in this case to inject
functions. Maybe you wish to add function inside the CDialog
but because it is not your code then you had to use another base
class.
The alternative design is create free functions and
pass the 'this' pointer as parameter.
The code using inheritance is much harder to reasoning
about considering the base class has access to all
protected members and consequently is less encapsulated
compared with free function where you only can access public
data/functions.
If you need to inject more functions you have to create more
base classes and at some point you will have to select sets
of functions that make sense to you.
Using the alternative, free functions, you may have to select
the best header to group functions but you can more easily (less
code to type) apply changes.

Use inheritance to get implementations can be good
to avoid to implement the same code in different
objects but at the same time can create a difficult
common denominator for all derived classes creating
a very coupled problem.
This is something very apparent when you realize
you have some virtual that doesn't make sense
in your object but you need to implement it doing nothing
just follow the interface.

Other languages, like C#, that don't have free functions
had to create a mechanism to archive similar functionality
called extension methods.

[Thiago Adams]

On Monday, July 23, 2018 at 12:41:03 PM UTC-3, Richard wrote:
> [Please do not mail me a copy of your followup]
>

> Thiago Adams spake the secret code

> thusly:
>
> >On Friday, July 20, 2018 at 5:51:57 PM UTC-3, Richard wrote:
> >...
> >> However, I find myself working in larger problem spaces now and C
> >> doesn't scale well to larger code bases because of its limited ability
> >> to express abstractions directly in code.
> >
> >I would like to understand better what you want to say.
> >More abstract code scale better? How? Maybe because you can
> >do the same think in less lines of code?
>
> C only has two facilities for abstraction: the struct and the function.
>
> While it is possible to build abstract data types on top of these two
> things (e.g. every "handle" based API in existence), the language
> doesn't really help you out. You can't do things like use 3D vectors
> or 3D points naturally with transformation matrices. (I often work
> in the 3D graphics problem domain.) Everything has to be written in
> terms of function calls instead of the natural notation of the problem
> space. This is one of the problem domains that is very "mathematical"
> in nature and overloading the arithemetic operators makes very good
> sense.

To get the benefits of math notation you also need to use
exceptions. Are you using exceptions?
And also you lost the control about how the computation is done.
For instance, sometimes we can do the calculation "in place"
the matrix is in/out at the same time avoiding temporaries.
Or we can arrange temporaries to avoid recalculation, because
math expressions don't care how the computation is done.
Also math expressions don't care about floating /overflow
problems.
I remember in C++ 03, the C++ programming language book,
Stroustrup showed some tricks to avoid temporaries in matrix
multiplication. I think now this is done using move semantics.

Some expressions are better if specialized functions
like hypot are used.

For these reasons, something I would like to have, or to
do is a especial transpiler where we could just write the math
expression as it is (in a declarative way), and the transpiler
would create the computational steps trying to reasoning about errors/overflow and creating the minimum steps (performance)
to archive the computation (imperative version) of the
expression.

Then, for instance if the input was

sqtr(x^2 + y^2)

the output would be

hypot(x, y)

if the input was X^2
the ouput could be x*x or alternatively using
pow depending on the exponent.

For big matrices I also think the transpiler could
take advantage of many cores.

I am sure I can find much more sample
then I believe this tool would be useful. I don't need
too much math expression in by job and this is one reason
I didn't make this transpiler yet.

This also shows that C++ syntax using operator overloading
and exceptions can represent math expressions but sometimes
for real code we need to think about how the computation is
done and make the steps manually.

I have one more sample that is for chart applications where
the used can do infinite zoom at the screen I had to define
the limit to avoid overflows. To do that I am not using the
full expression and waiting for some exception, but instead,
I can handle the problem using only the "zoom factor" instead
of all expression.
For the time axis I used 64 integers then I have the perfect
overflow check.

[Thiago Adams]

I just open the book The C++ programming language C++ 11,
on page 853, 29.5.4 Fused operations

Then he defines other types to represent expressions
MVMult and MVmulvAdd to archive the thing I was
talking about to avoid temporaries,reuse loops
and keeping the math syntax.

[Ian Collins]

You can write your maths routines however you like, optimising where
required. Our positioning system algorithms makes extensive use of
optimised matrix maths routines.

> For these reasons, something I would like to have, or to
> do is a especial transpiler where we could just write the math
> expression as it is (in a declarative way), and the transpiler
> would create the computational steps trying to reasoning about errors/overflow and creating the minimum steps (performance)
> to archive the computation (imperative version) of the
> expression.

You appear to be describing MatLab code generation..

--
Ian.

[Richard]

[Please do not mail me a copy of your followup]

bol...@cylonHQ.com spake the secret code
<pipj18$1jfi$1...@gioia.aioe.org> thusly:

>Does multiple inheritance get used much anyway?

Yes.

Oh, you wanted more?

People use private inheritance for composition of implementation, for
example.

It is the core building block of composing objects with ATL. Read
"ATL Internals" for a really good design stufy of templates and
composition of implementation through inheritance. It is worth
reading even if you don't plan on ever writing COM objects on Windows.

[Richard]

[Please do not mail me a copy of your followup]

Thiago Adams <thiago...@gmail.com> spake the secret code

<b6c3e16d-d24b-49ba...@googlegroups.com> thusly:

>And also you lost the control about how the computation is done.

Welcome to any language except assembly language.

[Lynn McGuire]

Actually, the multiple inheritance is to "inject" our standard object
data storage so that the user's choices on this modeless dialog can be
saved for their future usage.

Lynn

[bol...@cylonhq.com]

On Tue, 24 Jul 2018 21:33:31 +0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
>bol...@cylonHQ.com spake the secret code
><pipj18$1jfi$1...@gioia.aioe.org> thusly:
>
>>Does multiple inheritance get used much anyway?
>
>Yes.
>
>Oh, you wanted more?
>
>People use private inheritance for composition of implementation, for
>example.

And again in English?

>It is the core building block of composing objects with ATL. Read
>"ATL Internals" for a really good design stufy of templates and
>composition of implementation through inheritance. It is worth
>reading even if you don't plan on ever writing COM objects on Windows.

I don't plan on ever writing anything for Windows.

[BGB]

On 7/10/2018 5:41 AM, Bart wrote:
> On 10/07/2018 10:41, SG wrote:
>> On Tuesday, July 10, 2018 at 1:15:09 AM UTC+2, Lynn McGuire wrote:
>>> Jonathan Blow: "C++ is a weird mess"
>>> https://www.gamesindustry.biz/articles/2018-07-02-jonathan-blow-c-is-a-weird-mess
>>>
>>>
>>> Just because one is correct does not mean that one's solutions are any
>>> better.
>>
>> True. And C++ being a weird mess seems to be well-accepted:
>>
>>    "Within C++, there is a much smaller and cleaner language
>>     struggling to get out." -- Bjarne Stroustrup
>>
>> Though, I see Blow's language with mixed feelings, too.  There are
>> some nice things about it (super fast compiler,
>
> According to the LLVM link on this page (I won't link direct to the
> youtube video so as not to bring down the tone of this group):
>
>     https://inductive.no/jai/
>
> the compiler is not so fast at the moment as it relies on LLVM to do the
> code generation.
>
> That example uses a 34KLoc example program, and takes some 2.5 seconds
> source to executable (I think the version using a C compiler back-end is
> somewhat faster).
>

I just ran across this thread.
But, yeah, I am not personally expecting that much from Jai, and my own
language design preferences are quite different (and to me, his design
seems a bit misguided; like something which could "crash and burn"
and/or quickly transform into an unusable mess).


I have my own custom C compiler (*) which can compile Quake and Doom in
about 5 seconds. I "could" try to make it faster, but it is mostly
sufficient. A decent chunk of this time seems to be mostly IO (reading
in header files and similar).

I "could" possibly shave a little time off by effectively bundling the C
library headers and similar into a VFS (probably compressed with an LZ4
like scheme).

Note that doing a C++ compiler would be a whole different level of pain
vs just supporting C.


*: Mostly for custom CPU designs, for native development I mostly use
MSVC or GCC. Mine "basically works" but is also sort of buggy/crap.

I am mostly using Doom and Quake as test cases for my CPU/ISA design (as
a stand-in for "doing actual work").


> The 'front-end', what he calls compiling to byte-code, is about 0.2
> seconds, so that's pretty fast (about 170Klps). But even if that was
> all, it wouldn't be 'super-fast'.
>
> (My own compiler projects at the moment are considerably faster than
> even that front end, and the compilers are not themselves optimised
> other. But I would still hesitate to call that super-fast; I think I'd
> reserve that for 1Mlps and above. I've only occasionally breached that.)
>

A lot depends on how much is done by the compiler.

If one does ASTs, 3AC/SSA, and uses multiple passes for things like
register allocation and branch-distance-optimization, ... then it is
bound to be a little slower.

Avoiding textual header inclusion can also help a bit (preprocessing and
parsing header declarations being a significant time waster).


Though, a goal is to keep it down to maybe a few seconds or so, as too
much more than this starts to eat into flow. Though, as is, I suspect I
spend more time with things like "interactive testing" than compiling...


However, on the other hand, when build times are an hour or more, this
is unworkable (as-is, LLVM/Clang takes ~ 1 hour to rebuild on my PC),
seriously dethroning Doom 3 which rebuilds in about 15 minutes.


> Interesting BTW that he's using a Windows machine for development (one
> using SSD too as is mentioned at one point; mine just has a regular
> HDD), rather than the usual Linux. To hear people on these groups tell

> it, Windows is hopeless for software development.
>

I am using Windows, with an SSD for 'C:\', but pretty much everything
else is on HDD's. Putting Windows on an SSD makes nearly everything else
go faster, as well as having a big page-file. My PC has 32GB of RAM and
112 GB of swap/pagefile space.

This may seem like a lot, but every so often I run into a situation
which needs a large amount of memory.


>> Let's see how this Jai turns out ...
>
> The language snippets I saw didn't really grab me. I can't get a sense
> of its 'shape' or identity. I think we need to see more complete programs.
>

Yeah, I haven't seen much personally to instill much confidence.

But, for the most part, the languages I am using most right now are
mostly C, ASM, and Verilog. C++ is probably in 4th place (following
Verilog), but still ranking above "most other" languages.



I had considered some ideas for doing a language to address the sorts of
things I am doing, or basically something that could be "C competitive"
for some of my use cases.

Roughly what it started looking like:
Syntax is partway between C and early versions of Java;
Language structure is more like C#;
Typesystem design is intermediate between C, Java, and C#.
Unlike Java or C#, there would be no GC.
Pointers would exist, but are confined to 'unsafe' locations.
However, array-references may be used similar to pointers.
But, would be type-safe and bounds-checked (at a cost).
There would be no generics or similar.
But, there would be a type-inferred 'auto' type.
There would be overloading and namespaces/packages.
These are "sufficiently useful".

Object model was considered to be "similar" to the one in Java:
With more explicit constraints and semantics for object lifetime.
For most objects, there will be rules to make lifetime explicit.
For the "general case", there is new/delete.
Methods are 'final' by default.
The 'virtual' keyword is needed to allow overloading.
Likewise, single inheritance with interfaces.

Structs would also exist, with similar semantics to C and C#.

Had also defined "string" as a semi-opaque immutable type (in contrast,
say, to Java defining them as being object instances).

...


To some degree, it would be similar to my prior "BGBScript2" language,
but with minor syntax and semantics changes (for example, BS2 used
"virtual by default" semantics for object methods, ...).

However, other than this, there wouldn't be a whole lot of "features".
(A design goal would be to try to limit adding too many unnecessary
features).


This idea is partly held back by inertia though, namely in that for much
of what I am doing, C is sufficient. Similarly, it would have the usual
"not being C" drawbacks, and it is unclear if there is really all that
much of a point.


Similarly, things like bounds-checked array references are cause for
concern, as accessing them could require additional metadata and
bounds-checks, which don't come free (and are harder to infer-away than
null-checks).

This would mean "safe" would come at a performance premium, and "fast"
would effectively devolve to "just use pointers".

So, yeah, debatable at best, and a few people had complained before
about how conservative my past design ideas were... (like, they want
fancy/new/different rather than "something that looks like C mixed with
Java"...).

[Richard]

[Please do not mail me a copy of your followup]

BGB <cr8...@hotmail.com> spake the secret code
<pj9gc7$r12$1...@news.albasani.net> thusly:

>I have my own custom C compiler (*) which can compile Quake and Doom in
>about 5 seconds.

Are your customizations around making the compilation process faster?
If so, what exactly are you doing to get the speedup? Is this
something that could be contributed to clang?

[BGB]

On 7/25/2018 3:56 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> BGB <cr8...@hotmail.com> spake the secret code
> <pj9gc7$r12$1...@news.albasani.net> thusly:
>
>> I have my own custom C compiler (*) which can compile Quake and Doom in
>> about 5 seconds.
>
> Are your customizations around making the compilation process faster?
> If so, what exactly are you doing to get the speedup? Is this
> something that could be contributed to clang?
>

Nothing that really seems that particularly notable (beyond just its
potentially "unusual" architecture).

The original form of this compiler was written about 10 years ago (based
on a fork of an early form of my BGBScript language, which was at the
time a lazy JavaScript mockup with "pretty much awful" performance;
which I had hacked into being able to parse C), and is stand-alone /
ground-up, and written in C. But, at the time, the original idea was
partly inspired by the scripting system used by Quake 3 Arena.

It has been used/maintained on-off for much of this time. It spent many
years ignored and/or used as a "parse C headers for metadata" tool,
before fairly recently being "reborn" back as a a full fledged C
compiler for some of my recent projects.


I don't know Clang well enough to comment how much is applicable to
LLVM/Clang, and its speed doesn't really seem to be due to anything in
particular (beyond maybe being fairly small/simple).

Speeds otherwise generally aren't that drastically different from what I
see from MSVC (whereas compiling Quake with GCC in WSL is closer to
around 35s on my PC; though it seems a little faster if compiled via
Linux inside VirtualBox).


Vs a normal C compiler (such as GCC):
The compilation process is essentially monolithic.
A single binary does everything, rather than spawning new processes.
There is currently a cache where headers are kept one read-in.
Otherwise, not much seems particularly notable on this front.
Some minor lexer/parser tricks exist, but nothing major.
AST nodes are essentially small key/value B-Trees.
It is faster and uses less memory than CONS lists or XML DOM.
But, many other compilers use tagged-unions (probably faster).
All the translation-units use a shared context in the middle/backend.
Internal renaming is used to isolate TU-local features.
Ex: 'static' variables are renamed to hide them from other TU's.
As-is, this abstraction has some leaks which can break stuff (*1).
Only during parsing/frontend stuff are TU's independent.
Code generation uses a few major stages.
There is no separate assembler or linker stage.
Codegen sends commands directly to an "instruction emitter".
Resembles the inner part of an assembler, w/o an ASM parser.
I did later add an ASM parser, but mostly to support ASM.
Just relocates sections and spits out a binary as its output.


( *1: In particular, mismatched declarations between translation units
can break compilation. As can quietly having global variables and
functions with overlapping names (though MSVC also rejects these, but
GCC seems to accept them in certain cases).

Doom stumbled on a lot of these edge cases, so ended up modifying the
code so that, either, the declarations matched, or in other cases things
were manually renamed such that there was no longer a name clash. GCC
and MSVC just sort of quietly merged these cases union-style (unless
they were initialized with a value, in which case the linker would
typically complain).

Granted, a better solution could be making this work, probably along
with a few other cases which aren't currently handled, like initializer
expressions performing arithmetic or other calculations on the addresses
of other variables (which can't be handled in the front-end).

An overall better solution (to the naming issue) may be to have a
two-level scheme, with a partially separate per-translation-unit
namespace, and a second-level "extern" space which bindings may be
promoted to if referenced from within another translation unit, but
which may be shadowed by bindings local within each TU. Uninitialized
variables may be merged across TU's if their names match and their types
can be reconciled (otherwise, "do something sane").

These sorts of edge cases weren't really much of an issue for Quake or
for most of my own code though.
)



Beyond the frontend stage, there is no real separation between
translation units in the middle-end or backends.

Things like the C library are handled by compiling to an intermediate
stack-based bytecode (vaguely similar to CLR bytecode, produced with
only partial type-information), which is reloaded by the middle-end and
converted into a 3AC/SSA form used by the backend. No bytecode is used
at runtime, but exists purely as an IR stage (between the front-end and
middle-end). In the conversion to 3AC, stack-locations get remapped to
temporaries.

The current stack bytecode is called "RIL3", which consists of blobs of
stack-based bytecode within a collection of begin/end tag structuring.
The format can also contain LZ compressed data blobs (using an LZ4 like
format), which are used for various purposes (such as blobs of ASM code).


The backend basically works with everything in 3AC form, and using an
SSA-like scheme, but it differs from the one used in LLVM in that,
rather than giving each instance of a variable its own "name", it is
given a name with a revision number (and implicitly a "phi" just sort of
merges everything which corresponds to the same base variable).

Though, in general the backend is pretty naive (fancy optimizations
aren't really its strong area).


Eliminating a lot of the "infrastructural busywork" compared with
something like GCC does help with keeping the code smaller and simpler.

Namely, there is a whole lot of stuff in GCC which just doesn't need to
exist in this design.


As-is, compiler code size:
Current total = ~ 157 kLOC;
27 kLOC, BSR1 ISA backend;
34 kLOC, BJX2 ISA backend;
41 kLOC, SuperH/BJX1 ISA backend.
10 kLOC, C parser.
23 kLOC, front/middle-end (AST -> RIL -> 3AC);
15 kLOC, MM/AST/util code.
~7 kLOC, misc stuff

Compiler binary is currently approx 2.5 MB.
Compiler can also be itself recompiled within a few seconds.


There was a debatable possible feature to allow front-ends and back-ends
to exist as plug-in DLLs or SOs, but I have been on the fence as this
would add complexity to the compiler.


ISA Support Overview:

Where BJX1 was a prior ISA of mine developed as a superset of the
Hitachi SH-4 ISA. A later incarnation was a 64-bit ISA with 32 GPRs and
only a superficially similar instruction set remained (code was not
binary compatible between the 32 and 64 bit ISAs). Much hair developed
trying to deal with this much ISA variation in a single backend.

BSR1 was similar to SH, but somewhat simplified (left out features that
unnecessarily created pain when trying to implement the ISA in Verilog,
or "in-general"). It was intended to be a small/simple ISA. Like SH, it
is a 32-bit ISA with fixed-width 16-bit instructions and 16 GPRs, and
was intended for smaller/cheaper FPGAs (ex: lower cost 9kLUT devices).


BJX2 was essentially a redesign of the BJX1 ISA based on BSR1. In many
regards it is a cleaner and simpler design, but expands to support
16/32/48 bit instruction-forms (the larger 48-bit forms being able to
support larger immediate values and displacements). Note that it is
otherwise a 64-bit RISC-style ISA with 32 GPRs.


I have also had a little more success getting a working Verilog
implementation, mostly due to design simplifications in many areas.

The latter two backends were mostly copy/paste/edit versions of the
original SH / BJX1 backend.

Note that it is a fairly minimal ISA if compared with something like
x86, as many things which are done natively in hardware in x86 need to
be faked in software in these ISAs (such as integer division). Granted,
it is intended to work on a "hobbyist grade" FPGA dev-board (currently
targeting an Arty S7 with a 50 kLUT Spartan-7).


There is not currently an x86/x86-64 compiler backend, mostly because I
typically use MSVC or GCC for these (and, for the most part, C is C).
Though, x86-64 support is still a possibility.


Canonically, currently used output formats are either raw ROM images, or
PE/COFF (the BJX2 Boot-ROM expects to load a PE/COFF image). For BJX2,
the PE/COFF format is based on the PE32+ format, but lacks anything in
the MZ stub.

For both boot and program launching, currently PE/COFF is the format
used, but program launching (unlike launch via the Boot-ROM) will
support base-relocatable binaries and DLLs.


Or such...

[Juha Nieminen]

Richard <legaliz...@mail.xmission.com> wrote:
> I'm always amazed at the number of C/C++ developers that haven't
> upgraded their development environment in 30+ years. By this point, I
> would have expected that all the emacs afficionados would have
> automated refactoring implemented in elisp, but nope. They have
> essentially the same environment I had in 1988.

In my experience there is no perfect C++ source code editor. Every
single editor is lacking something.

Typically their auto-indentation feature sucks (except (mostly) in emacs),
or they lack code completion (most non-IDE editors, including emacs),
they lack or have lacking programmable keyboard shortcuts, and so on and
so forth.

[Paavo Helde]

On 26.07.2018 9:06, Juha Nieminen wrote:
> Richard <legaliz...@mail.xmission.com> wrote:
>> I'm always amazed at the number of C/C++ developers that haven't
>> upgraded their development environment in 30+ years. By this point, I
>> would have expected that all the emacs afficionados would have
>> automated refactoring implemented in elisp, but nope. They have
>> essentially the same environment I had in 1988.
>
> In my experience there is no perfect C++ source code editor. Every
> single editor is lacking something.
>
> Typically their auto-indentation feature sucks (except (mostly) in emacs),
> or they lack code completion (most non-IDE editors, including emacs),

I have heard one can have code completion in emacs, but this probably
requires special setup and I do not use emacs often enough to bother
about that. When I do not recall the exact symbol name in Emacs I will
switch over to Visual Studio window and do a lookup or search there.

[Ian Collins]

Those features or lack of then shape our choice of editors. I for one
don't like Visual Studio's indentation, but it has excellent code
completion which I don't really use. NetBeans has near infinite code
layout configuration, but sluggish code completion.

--
Ian.

[Paavo Helde]

On 26.07.2018 12:55, Ian Collins wrote:
> Those features or lack of then shape our choice of editors. I for one
> don't like Visual Studio's indentation, but it has excellent code
> completion which I don't really use.

Visual Studio's indentation is highly customizable (I count 16 related
options), I am just curious what style it does not support?

[Ian Collins]

NetBeans has 81 just for C++!

The one that bugs me most (not say it can't be fixed, just haven't found
how) is brace placement on initialisers; it appears to confuse them with
inline function bodies.

--
Ian

[bart...@gmail.com]

On Thursday, 26 July 2018 06:17:11 UTC+1, BGB wrote:
> On 7/25/2018 3:56 PM, Richard wrote:

> > Are your customizations around making the compilation process faster?
> > If so, what exactly are you doing to get the speedup? Is this
> > something that could be contributed to clang?
> >

> Namely, there is a whole lot of stuff in GCC which just doesn't need to
> exist in this design.
>
>
> As-is, compiler code size:
> Current total = ~ 157 kLOC;
> 27 kLOC, BSR1 ISA backend;
> 34 kLOC, BJX2 ISA backend;
> 41 kLOC, SuperH/BJX1 ISA backend.
> 10 kLOC, C parser.
> 23 kLOC, front/middle-end (AST -> RIL -> 3AC);
> 15 kLOC, MM/AST/util code.
> ~7 kLOC, misc stuff
>
> Compiler binary is currently approx 2.5 MB.
> Compiler can also be itself recompiled within a few seconds.

That sounds like quite a substantial product. My 'C' compiler is about 20Kloc (of original source, as it's not written in C; expressed in C it's only a bit longer).

That targets only x64, and outputs x64 asm source. (My own format and run through my own assembler, which assembles/links multiple .asm files to .exe at some 2-3Mlps. Perhaps about 9Kloc for that.)

Compilation speed on a PC, .c to .asm, is typically 0.6Mlps. (Plus .asm preocessing, but that stage could be incorporated into the main compiler without probably affecting that 0.6Mlps much.)

However, it only processes one C file per compiler invocation, so multi-module projects are slow. Also, it has so many other problems that I now just call it a C dialect compiler (suitable for the intermediate C I sometimes generate). While it can compile and run certain open-source programs (eg. Lua), making it work for arbitrary C code involves going down a rabbit-hole I'm longer interested in exploring.

I'm concentrating at the minute on an alternative low-level language, visually different from C, with a module system and designed for whole-program compilation. This needs more passes to compile, and I'm only getting up to 0.4Mlps, but there are no C-like headers to repeatedly process so all of that throughput is usable.

Neither product optimises code, which looks pretty terrible when you look at the output. But on my apps, the difference between this code, and gcc-O3, is fairly narrow; gcc might be 20-50% faster.

(Which is still worthwhile enough that I am reinstating a C target for this compiler - which will always be a single whole-project C source file - just so I can pass it through gcc-O3 and step up those lps figures a couple of notches.

Not that it needs them on the PC: all my 20-25Kloc multi-module programs each build from source to .exe, including asm processing, in the time it takes me to press Enter. But it'll be useful on a slower machine.)

> Canonically, currently used output formats are either raw ROM images, or
> PE/COFF (the BJX2 Boot-ROM expects to load a PE/COFF image). For BJX2,
> the PE/COFF format is based on the PE32+ format, but lacks anything in
> the MZ stub.

PE/COFF formats are horrible (trust MS to overcomplicate matters). I used to generate COFF for object files, but since I generated PE directly, I hardly ever bother. (My PEs don't support DLLs so I might need COFF still which have to be passed through a conventional linker.) However I find my PEs attract unwelcome attention from AV software.

Anyway, in response to the query, it is possible to streamline compilation of a C-like language to it can be done quickly if you don't care about code-speed.

C itself doesn't make things easy with its macro language and its textual include files which must be reprocessed not only in different TU but within the same one, unless you use guards or things like #pragma once, all very messy.

But Tiny C shows it can be done.

As for C++ though, I can only say it's making a rod for its own back.

--
bart

[bol...@cylonhq.com]

If someone is so lazy they need an editor to do something as basic and quick
as indentation then perhaps development isn't the right job for them.

[Rosario19]

agree the appaence and indentation on the paper or on the sheet or in
the screen is almost all (quasi tutto)
at last so has to think someone that see programming as an art

[Juha Nieminen]

Paavo Helde <myfir...@osa.pri.ee> wrote:
> Visual Studio's indentation is highly customizable (I count 16 related
> options), I am just curious what style it does not support?

I really like the indentation mechanism in emacs, where you simply press
tab (regardless of where the cursor is at the moment) and it will
auto-indent the current line based on the previous line(s). It will move
it to the left or the right so that it becomes indented according to the
indentation rules. Even if the indentation of a block of code is completely
messed up, you can quickly indent it by simply pressing tab on each line.

(Of course you can also select the block of code and run the indent-region
command on it, which will do the same even easier. Obviously if you find
yourself running this command a lot, you can bind it to a keyboard
shortcut. But when we are talking about a few lines of code, pressing tab
on each is also viable and handy.)

There may be other editors which have similar or even the exact same
functionality (at least as an option), but I have not encountered one.
(To be fair, though, it's not like I have tried an enormous amount of
them.)

The major drawback of emacs is that configuring the indentation is
complicated, as there are no easy menus with mouse-clickable options.
It also doesn't always get the indentation of certain types of code
as I like, and it's difficult to configure it to do so. (It's possible,
but usually requires you to understand elisp.)