Alternatives to Visual Studio 2015 or later

[Rick C. Hodgin]

Does anybody have any tools they use that are similar in ability
to compile and debug C++ projects, but do so faster than Visual
Studio?

I'm waiting about 1 second between single steps in source code.
I remote connected to a foreign server and it was faster there
over our LAN than it is here locally when I debug this particular
process.

In the alternative, does anybody have any ideas on how to make
Visual Studio 2015 or later go faster in debugging? It has a
great IDE, and edit-and-continue is excellent, but single-step
speed is slow enough I'm looking for another tool. If I can
correct my setup here so it goes faster, I'll be happy to try
these tools.

--
Rick C. Hodgin

[Rick C. Hodgin]

I was able to switch back to Visual Studio 2010 and it is working
as I would expect.

For some reason on this project (which has one source file that's
around 25K lines of code) it is slow single-stepping. But in
VS2010 it is normal speed.

I will also try VS2008, and I may switch back to those dev tools
for daily development, and then use VS2015 only at the end when
I want a modern compile.

--
Rick C. Hodgin

[Rick C. Hodgin]

What alternatives are there to MSVC, and GCC and CLang?

Are there any free compilers that are distinct and unique from
those code bases? The only one I am aware of is Intel's C++
compiler, and it's $1600 for the professional version per year,
which I also think is outrageous. Intel should give away their
compilers because it would encourage people to use their CPUs
instead of other manufacturer CPUs.

Does anybody have a free compiler that's of its own source code
base, not deriving from GCC or CLang?

--
Rick C. Hodgin

[Chris M. Thomasson]

You can try:

http://www.smorgasbordet.com/pellesc

It is fairly nice.

[Chris M. Thomasson]

One little quirk I found:

https://forum.pellesc.de/index.php?topic=7167.0

[Ian Collins]

It's also a C compiler!

--
Ian.

[Ian Collins]

On 03/25/2018 12:13 PM, Rick C. Hodgin wrote:
> What alternatives are there to MSVC, and GCC and CLang?
>
> Are there any free compilers that are distinct and unique from
> those code bases? The only one I am aware of is Intel's C++
> compiler, and it's $1600 for the professional version per year,
> which I also think is outrageous.

On par with other "professional" offerings.

> Intel should give away their
> compilers because it would encourage people to use their CPUs
> instead of other manufacturer CPUs.

The Intel tools selling point is performance on Intel CPUs; if that's
what you need, the cost is fair.

> Does anybody have a free compiler that's of its own source code
> base, not deriving from GCC or CLang?

What's wrong with those options?

--
Ian

[Daniel]

On Friday, March 23, 2018 at 2:43:49 PM UTC-4, Rick C. Hodgin wrote:

> does anybody have any ideas on how to make
> Visual Studio 2015 or later go faster in debugging? It has a
> great IDE, and edit-and-continue is excellent, but single-step
> speed is slow enough I'm looking for another tool.

I find it curious that you seem to be spending so much time in the debugger.
I rarely, hardly ever, do. Is there something about how you approach a
programming problem that requires you to be in the debugger that much?

Thanks,
Daniel

[Rick C. Hodgin]

I typically use Visual Studio. It has an edit-and-continue ABI. I
am able to write code, begin running it, then make changes or add
code on-the-fly, apply code changes, and keep going. I single-step
through most everything and examine structures and variables as I go.

It's been my long-term development style since the early 2000s.

--
Rick C. Hodgin

[Chris M. Thomasson]

Argh! Touche. Ouch.

;^o

[Chris M. Thomasson]

Well, Rick does seem to like compiling C code in C++...

[Mr Flibble]

Sounds an egregious way of doing things. Debuggers are primarily for
debugging not for day-to-day code cutting.

/Flibble

--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."

[Rick C. Hodgin]

On Saturday, March 24, 2018 at 8:25:34 PM UTC-4, Mr Flibble wrote:
> Sounds an egregious way of doing things. Debuggers are primarily for
> debugging not for day-to-day code cutting.

It works well. I've been able to code everything to date using
that model.

You can seem some of my coding sessions here. Go to the end of
the page. They are the videos recorded mostly in 2012 and 2013:

http://www.visual-freepro.org/videos/

Here's one of me refactoring some of my bitmap algorithms (best
viewed on 1920 x 1200, 2.5 hr, 4 fps):

http://www.visual-freepro.org/videos/2012_11_04__01_development__refactoring_load_bitmaps_from_disk.ogv

--
Rick C. Hodgin

[Melzzzzz]

Intel compiler is now free. You can purchase 70 day free commercial
license, and then renew it after these days, for free eternally ...
>


--
press any key to continue or any other to quit...

[Melzzzzz]

Heh, when I want C, I use C compiler.

[Mr Flibble]

Out of curiosity I started playing this to confirm my suspicion that it
is another platform where you egregiously proselytize and I wasn't
disappointed. Stopped playing after a minute (didn't want to throw up).

Speed of light mate.

#atheism

[Ian Collins]

Way slower and less robust than write test, code to pass test, refactor,
repeat...

A slow or poor debugger is good motivation to write good tests!

--
Ian

[Rick C. Hodgin]

On Saturday, March 24, 2018 at 9:38:10 PM UTC-4, Mr Flibble wrote:
> On 25/03/2018 00:56, Rick C. Hodgin wrote:
> > On Saturday, March 24, 2018 at 8:25:34 PM UTC-4, Mr Flibble wrote:
> >> Sounds an egregious way of doing things. Debuggers are primarily for
> >> debugging not for day-to-day code cutting.
> >
> > It works well. I've been able to code everything to date using
> > that model.
> >
> > You can seem some of my coding sessions here. Go to the end of
> > the page. They are the videos recorded mostly in 2012 and 2013:
> >
> > http://www.visual-freepro.org/videos/
> >
> > Here's one of me refactoring some of my bitmap algorithms (best
> > viewed on 1920 x 1200, 2.5 hr, 4 fps):
> >
> > http://www.visual-freepro.org/videos/2012_11_04__01_development__refactoring_load_bitmaps_from_disk.ogv
>
> Out of curiosity I started playing this to confirm my suspicion that it
> is another platform where you egregiously proselytize and I wasn't
> disappointed. Stopped playing after a minute (didn't want to throw up).

Most likely all of my videos are like that in one way or another.
I picked one at random ... something that I thought might have
some interesting code.

The whole Visual FreePro project was an offering given over to
the Lord, a free and open source-level compatible alternative to
Microsoft's Visual FoxPro 9 final release before they canceled
the product. In 2012 I was hopeful other developers would come
on board and help me complete it, but to date I've only had two
other developers come on board and help, and only for short
whiles:

http://www.visual-freepro.org/wiki/index.php/VXB#Contributions

People have shied away from the project for similar reasons,
that they don't want to be involved with a project honoring
Jesus Christ explicitly. I've had people tell me (VFP experts)
that if I made it a commercial project they would help me.

This post came through my Facebook page today:

https://www.facebook.com/real.men.read.pink/posts/1771445106240930?pnref=story

"It is the duty of God’s servants to warn men of their danger,
to point out that the way of rebellion against God leads to
certain destruction and to call upon them to throw down the
weapons of their revolt and flee from the wrath to come.

"It is their duty to teach men that they must turn from their
idols and serve the living God, otherwise they will eternally
perish.

"It is their duty to rebuke wickedness wherever it be found
and to declare that the wages of sin is death.

"This will not make for their popularity, for it will condemn
and irritate the wicked, and such plain speaking will seriously
annoy them. Those who expose hypocrites, resist tyrants, oppose
the wicked, are ever viewed by them as troublemakers. But as
Christ declared --- Blessed are ye, when men shall revile you,
and persecute you, and shall say all manner of evil against you
falsely, for My sake. Rejoice, and be exceedingly glad: for great
is your reward in heaven: for so persecuted they the prophets
which were before you --- (Matthew 5:11, 12)."

-- Arthur Pink, "The Life of Elijah," 1963

Christianity is a real thing, Leigh ... though you may only know
the other hypocritical form that is so prevalent in modern society.
The "do whatever you want and call yourself a Christian" religion
of lies and hypocrisy.

Being a true Christian is a conversion. It's a new life, from the
inside out, and it permeates everything you do, and everything you
are.

--
Rick C. Hodgin

[Rick C. Hodgin]

It works for me. It has for a long time. I also have dyslexia and
despite my best efforts, I still write wrong things. I can even
think "if not variable_name" intending to code "if (!variable_name)"
and code "if (variable_name)". I don't know how I do it, but it
happens regularly.

The edit-and-continue debugger is an absolute essential tool for me.
As is stepping through my code line-by-line and examining variables.
It helps me to double-check things to overcome my shortcomings in
coding.

> A slow or poor debugger is good motivation to write good tests!

Only Visual Studio 2015 has been slow. I've used Visual Studio
2003 (my favorite), 2008 (second favorite), 2010, and 2015, and I've
tried 2017 briefly. I typically code in VS 2008 today because it
has the Code Definition Window. If VS 2003 had that window, I would
use it instead. I've considered writing an add-on for that version
which did exactly that. Once my goal is to complete CAlive, and then
I'll have no need so I've just stuck with VS 2008.

--
Rick C. Hodgin

[Mr Flibble]

On 25/03/2018 02:59, Rick C. Hodgin wrote:
[snip]

> Being a true Christian is a conversion. It's a new life, from the
> inside out, and it permeates everything you do, and everything you
> are.

[Rick C. Hodgin]

On Saturday, March 24, 2018 at 10:10:40 PM UTC-4, Mr Flibble wrote:
> On 25/03/2018 02:59, Rick C. Hodgin wrote:
> [snip]
> > Being a true Christian is a conversion. It's a new life, from the
> > inside out, and it permeates everything you do, and everything you
> > are.
>
> Speed of light mate.
>
> #atheism

You can repeat your statements all the way to your death, Leigh.
I've given you a response to them, and you've rejected it. There's
nothing I can do about that.

I am not responsible for other people believing the truth, only
for teaching them the truth rightly. I have done that, and my work
is fulfilled such that should I die today, I would stand before the
Lord and be able to say, in His Holy presence, that I did try with
great passion to teach you the truth.

I am innocent of your blood even though you remain damned to Hell
today. It makes me sad to be sure, but there's nothing I can do.

When a person rejects the truth ... there's nothing anyone can do
for them ... not even God because He honors your decision and your
choice, even if it leads to your own soul's destruction in Hell.

--
Rick C. Hodgin

[Mr Flibble]

On 25/03/2018 03:25, Rick C. Hodgin wrote:
[snip]

> When a person rejects the truth ...

Speed of light mate.

#atheism

[Ian Collins]

On 03/25/2018 03:04 PM, Rick C. Hodgin wrote:
> On Saturday, March 24, 2018 at 9:41:47 PM UTC-4, Ian Collins wrote:
>> On 03/25/2018 12:54 PM, Rick C. Hodgin wrote:
>>> On Saturday, March 24, 2018 at 7:49:52 PM UTC-4, Daniel wrote:
>>>> On Friday, March 23, 2018 at 2:43:49 PM UTC-4, Rick C. Hodgin wrote:
>>>>
>>>>> does anybody have any ideas on how to make
>>>>> Visual Studio 2015 or later go faster in debugging? It has a
>>>>> great IDE, and edit-and-continue is excellent, but single-step
>>>>> speed is slow enough I'm looking for another tool.
>>>>
>>>> I find it curious that you seem to be spending so much time in the debugger.
>>>> I rarely, hardly ever, do. Is there something about how you approach a
>>>> programming problem that requires you to be in the debugger that much?
>>>
>>> I typically use Visual Studio. It has an edit-and-continue ABI. I
>>> am able to write code, begin running it, then make changes or add
>>> code on-the-fly, apply code changes, and keep going. I single-step
>>> through most everything and examine structures and variables as I go.
>>
>> Way slower and less robust than write test, code to pass test, refactor,
>> repeat...
>
> It works for me. It has for a long time. I also have dyslexia and
> despite my best efforts, I still write wrong things. I can even
> think "if not variable_name" intending to code "if (!variable_name)"
> and code "if (variable_name)". I don't know how I do it, but it
> happens regularly.

It would also be caught by tests....

> The edit-and-continue debugger is an absolute essential tool for me.
> As is stepping through my code line-by-line and examining variables.
> It helps me to double-check things to overcome my shortcomings in
> coding.

As do tests faster and with a lot more consistency.

--
Ian.

[Rick C. Hodgin]

Tests are appropriate at times.

> > The edit-and-continue debugger is an absolute essential tool for me.
> > As is stepping through my code line-by-line and examining variables.
> > It helps me to double-check things to overcome my shortcomings in
> > coding.
>
> As do tests faster and with a lot more consistency.

You've mentioned this coding style before. I'm glad it works for
you. It's not my style or need for a lot of the coding I do. Some of
my algorithms could benefit and I've written self-test code before.

Different coding styles for different people.

--
Rick C. Hodgin

[Mr Flibble]

Unit tests aren't a "coding style"; they are an important part of the
software development process; if you never write unit tests then you are
doing it wrong.

[Ian Collins]

The only case I can think of is one off non-production code that is
never going to be changed.

>>> The edit-and-continue debugger is an absolute essential tool for me.
>>> As is stepping through my code line-by-line and examining variables.
>>> It helps me to double-check things to overcome my shortcomings in
>>> coding.
>>
>> As do tests faster and with a lot more consistency.
>
> You've mentioned this coding style before. I'm glad it works for
> you. It's not my style or need for a lot of the coding I do. Some of
> my algorithms could benefit and I've written self-test code before.

So you write code that you will never change and don't need to check for
regressions?

> Different coding styles for different people.

Unit tests aren't a style, they are a vital part of the software
development process!

--
Ian

[Rick C. Hodgin]

On Saturday, March 24, 2018 at 11:37:30 PM UTC-4, Ian Collins wrote:
> On 03/25/2018 04:06 PM, Rick C. Hodgin wrote:
> > On Saturday, March 24, 2018 at 10:55:41 PM UTC-4, Ian Collins wrote:
> >> It would also be caught by tests....
> > Tests are appropriate at times.
>
> The only case I can think of is one off non-production code that is
> never going to be changed.

I worked for a company in the mid-2000s that had six full-time
developers, and three full-time unit test writers. They wrote
test after test after test for the code we would write.

I was never able to justify that degree of labor spent on writing
tests when you, as a developer, are supposed to test the code you
write as you go.

It's kind of the purpose of my single-step debugging in areas
where I have changed something. With Visual Studio, you hover
over a token name and if it's a variable of some kind it pops
up its value or member list, and as you hover over each part
it drops down into the child member contents, and into that
member's children, etc. It all takes a few seconds to navigate.

> >>> The edit-and-continue debugger is an absolute essential tool for me.
> >>> As is stepping through my code line-by-line and examining variables.
> >>> It helps me to double-check things to overcome my shortcomings in
> >>> coding.
> >>
> >> As do tests faster and with a lot more consistency.
> >
> > You've mentioned this coding style before. I'm glad it works for
> > you. It's not my style or need for a lot of the coding I do. Some of
> > my algorithms could benefit and I've written self-test code before.
>
> So you write code that you will never change and don't need to check for
> regressions?

I write code that I test before releasing it to our company's
internal testers. And if there is a regression, I fix it.

I've pushed for adding the type of testing you indicate at our
company, but their view is:

(1) Greatly increases the labor because you have to now:
(1a) Write the new code, or
(1b) Make changes to the existing code,
(1c) Test your new / changed algorithm manually anyway,
(1d) Write the test, or update the test code
(2) The fact that you're writing more than just changes to
your code introduces the potential for errors in your
tests, which then must be tracked down:
(2a) Was the error a real error? Or a test error?
(2b) Changes are made to code
(2c) Possibly some additional changes need to be made
to the tests

It's a great increase in labor to write tests for cases which, in
my experience, rarely are required.

For some complex code it is good to do unit testing. For some
large algorithms it is good to do unit testing. But for the rest,
part of the job of a developer is to test your code and make sure
that the changes you're making haven't broken anything. You can
typically do this just by running your code with a few variables.

In an edit-and-continue debugger environment, you can enter the
function, pause, change runtime values, restart the algorithm,
try again with new settings, etc., much faster than you can write
a unit test to validate it.

Such a methodology would not give aid on the next round of tests
that are required when other changes are made to other parts of
the system, but historically speaking the number of other things
broken like that are very rare, far rarer to fix than to devote
time to trying to catch them in the first place.

Remember also, this is mostly C code written in a C++ compiler
that I do. It's far less prone to error. :-)

> > Different coding styles for different people.
>
> Unit tests aren't a style, they are a vital part of the software
> development process!

In some cases I agree. In others, the labor does not justify
the gain ... in my opinion, and in the opinion of many others.

It's a philosophical viewpoint. And as I get older, I am leaning
more and more toward testing as I'm no longer able to be as fully
comprehensive in my memory and abilities as I was when I was much
younger. I do make mistakes as I get older, and I can see the
value in testing more and more because of it.

--
Rick C. Hodgin

[Rick C. Hodgin]

I do write unit tests on some things, but not on everything.

And it is a large amount of labor to setup and document unit tests
which are able to give a yay/nay result with some degree of diag-
nostic ability. At least that's been my experience.

In my opinion, on most code, that additional amount of labor does
not justify the gains achieved by having the unit tests. On some
types of code it does. It depends on the factors involved.

I have coded this way since I began coding. The number of bugs I've
had which reach production are few, and their impact is typically
minimal as I release new code to trusted "test sites" who are able
to run it knowing there may be problems. They like to use the
software in this way because they have a close relationship with the
developers, and they know they'll be able to get their wants and
wishes added to the code base.

It's a good tradeoff... less labor on our part, wider testing on
their part, before it goes to mass release.

In my experience, it's a fairly common practice to do it this way.
And as I say, to me it's a coding style. The style of coding you
do involves writing unit tests or not.

Just my opinion.

--
Rick C. Hodgin

[Rick C. Hodgin]

On Sunday, March 25, 2018 at 6:37:00 AM UTC-4, Rick C. Hodgin wrote:
> On Saturday, March 24, 2018 at 11:37:30 PM UTC-4, Ian Collins wrote:
> > On 03/25/2018 04:06 PM, Rick C. Hodgin wrote:
> > > On Saturday, March 24, 2018 at 10:55:41 PM UTC-4, Ian Collins wrote:
> > >> It would also be caught by tests....
> > > Tests are appropriate at times.
> >
> > The only case I can think of is one off non-production code that is
> > never going to be changed.
>
> I worked for a company in the mid-2000s that had six full-time
> developers, and three full-time unit test writers. They wrote
> test after test after test for the code we would write.
>
> I was never able to justify that degree of labor spent on writing
> tests when you, as a developer, are supposed to test the code you
> write as you go.

I would go so far as to say that there were cases where it made for
sloppy developers, because they knew "the unit testers will find
any bugs."

When you know the final authority stops with you, you do some extra
double- and triple-checks to make sure. You might also ask another
developer to look it over and see if there's anything obvious. It
helps inter-personal relationships in understanding the hows and
whys of what made a particular thing be designed or altered in that
way, and it puts a second mind on the problem knowing that they may
be thinking of things you haven't pigeonholed your own thinking in
to while working on this isolated component.

I've caught more bugs that way than I've ever caught with unit
testing, and probably even with release-to-testers testing.

> It's kind of the purpose of my single-step debugging in areas
> where I have changed something. With Visual Studio, you hover
> over a token name and if it's a variable of some kind it pops
> up its value or member list, and as you hover over each part
> it drops down into the child member contents, and into that
> member's children, etc. It all takes a few seconds to navigate.

In my experience, everybody codes differently. And for many
people their coding style is a religion and they are relentless
in it. For me, because of my dyslexia, I've had to learn that
different things work for different people. It's based on how
they're wired, what they feel comfortable with, etc. And so long
as they're not causing an issue by their unique quirks, such as
trying to code "if (5 == x)" rather than the obvious and proper
form of "if (x == 5)", then it's all good.

:-)

--
Rick C. Hodgin

[Rick C. Hodgin]

On Sunday, March 25, 2018 at 7:18:41 AM UTC-4, Rick C. Hodgin wrote:
> On Sunday, March 25, 2018 at 6:37:00 AM UTC-4, Rick C. Hodgin wrote:
> > I worked for a company in the mid-2000s that had six full-time
> > developers, and three full-time unit test writers. They wrote
> > test after test after test for the code we would write.
> >
> > I was never able to justify that degree of labor spent on writing
> > tests when you, as a developer, are supposed to test the code you
> > write as you go.
>
> I would go so far as to say that there were cases where it made for
> sloppy developers, because they knew "the unit testers will find
> any bugs."
>
> When you know the final authority stops with you, you do some extra
> double- and triple-checks to make sure. You might also ask another
> developer to look it over and see if there's anything obvious. It
> helps inter-personal relationships in understanding the hows and
> whys of what made a particular thing be designed or altered in that
> way, and it puts a second mind on the problem knowing that they may
> be thinking of things you haven't pigeonholed your own thinking in
> to while working on this isolated component.
>
> I've caught more bugs that way than I've ever caught with unit
> testing, and probably even with release-to-testers testing.

I've also looked at it from a cost factor. If a high-level developer
is paid X, and a unit tester is paid k*X where k < 1, then there is a
labor savings for the unit tester to do some of the labor.

But when you consider the time in testing, the familiarity with the
system being written and developed. the unit tester will approach the
"black box" being given the specs by the developer as to what needs
to be tested and how, which means some additional up-front labor on
behalf of the developer anyway (to document those needs), and now you
have a "blind" unit tester writing code to validate something you had
previously been there intimately with. You had the algorithms open,
the purpose of the program flow was in your mind, you were "in the
zone" in the code ... so why sacrifice that tremendous asset only to
pass on to the unit tester some ability to test your code when you
could test it right there?

And now you're back to paying X for your labor, and for your testing,
rather than X for your labor and k*X where k < 1 for the testing,
but your X labor goes up slightly to document what the tester needs,
which means you're probably back on par with what you would have cost-
wise had you done the testing yourself.

And then there's productivity per developer.

In my experience, it's far more desirable for a developer to spend a
little extra time double- and triple-checking their changes with some
last minute manual testing than it is to release something with a bug
and come back and fix it later. The developer is there in the full
mindset of the code, and is fluid during that last double- and triple-
check time. But when it's released into a build, built, and tested by
someone else (or even something else as a unit test later), the dev-
eloper must re-enter that fluid state, which takes time and increases
the risk of error because it's unlikely the developer will reach the
full fluid state without a protractive effort, and if the bug that's
being examined is non-trivial (something highly likely if a skilled
developer missed it with double- and triple-checks), then it's going
to require a notably longer period of time to fix it than it should.

In the end, I conclude that unit testing has validity in some types
of code, and in other types of code it's a waste of time, material,
and resources.

That being said, I am pushing for more unit testing in my life as I
get older because I am not able to enter that "fluid zone" as easily
or as deeply as I could when I was younger. I can at times, but not
as a matter of course as before. As a result, I would like to have
more testing to validate I haven't forgotten something I previously
fixed through my own aging-related inabilities.

-----
On additional factor, in Visual Studio 2015 there was a new native
tool introduced into the base VS package, which was called "Code
Analysis." It would go through your code and perform smart fuzzy
testing on your algorithms, and perform the "what-if" scenarios.
It would say "Okay, here's a logical test for an if block... what
if it was true, what would happen?" Then it would examine it and
report on its findings. It would then come back and say, "Okay,
now what if it wee false, what would happen?" And it would examine
that condition.

It rigorously iterates through all possible choices and looks for
a wide range of errors in your code, such as uninitialized variables,
use after free, etc.

Using this new tool, on a C/C++ code base about 30K lines long, I
found about 15 places where potential errors existed. In all but
a couple cases, they were conditions that would never exist because
there was some check higher up in the code which precluded the error
condition from ever being a possibility. But in a couple cases,
there were legitimate bugs that it found where, had that particular
scenario happened, it would've errored out or produced invalid
results.

And to this day, on that algorithm, I still have a place somewhere
in my code where it writes beyond the buffer limits on something.
I have spent days trying to find it and cannot. I've downloaded
memory tools to look for buffer overruns, ported it to other com-
pilers to see if they could find any errors. I've written my own
manual memory subsystem (which I reported on in the comp.lang.c
thread a year or two back) so I could walk the heap on each of my
allocations and releases.

I still haven't found it despite all this testing. All I've been
able to do is modify my malloc() algorithms to use my_malloc()
and allocate an extra 16 bytes before and after each requested
memory block, then return a pointer to the 16 bytes after the
start. That has solved it, but it's a hack workaround and not
a true fix.

Every now and again when I get a few spare bit, I go back in and
try to find it. It's been probably four years now and I cannot
find it.

I'm nearly convinced there isn't a problem in my code as per my
understanding of how things work, but that what I'm thinking is
a legal use of a pointer or block is actually illegal, resulting
in undefined behavior at that point. And until I'm able to learn
what it is that's causing the error, the extra buffer around the
allocated memory blocks is a sufficient work-around.

-----
To be honest, those are the areas where I could see having some
type of natural language testing abilities would be of greatest
benefit. To be able to traverse your code looking at all of the
possible code paths rigorously, reporting on things used apart
from initialization, or after releasing, or many other such tests,
coupled to the ability to get a digital map of everything done in
the memory subsystem, and to be able to provide compile-time info
regarding where a pointer should operate only, and to be able to
trap any errors of use beyond that range during this special
compilation mode which adds the checks for such things.

Those kinds of developer tools would help me more than unit test-
ing on my own algorithms as they are fairly easy to test if they're
working with a few manual cases applied during development.

At least that's been my experience.

--
Rick C. Hodgin

[bartc]

On 24/03/2018 23:13, Rick C. Hodgin wrote:
> What alternatives are there to MSVC, and GCC and CLang?
>
> Are there any free compilers that are distinct and unique from
> those code bases? The only one I am aware of is Intel's C++
> compiler, and it's $1600 for the professional version per year,
> which I also think is outrageous.

$1600 in a professional environment is peanuts.

How much is the annual salary of the person doing the programming? How
much are the on-going business costs per employee for premises,
computers, networking and everything else?

If Intel's compiler offers improved code (over thousands of copies of
applications), or even just a faster, more productive development cycle,
then it may pay for itself anyway.

> Intel should give away their
> compilers because it would encourage people to use their CPUs
> instead of other manufacturer CPUs.

I don't think Intel are doing too badly, but I hardly think a $1600 cost
for a tool is a significant factor when designing and manufacturing a
new product.


--
bartc

[Rick C. Hodgin]

On Sunday, March 25, 2018 at 8:48:53 AM UTC-4, bartc wrote:
> I don't think Intel are doing too badly, but I hardly think a $1600 cost
> for a tool is a significant factor when designing and manufacturing a
> new product.

It's outside of my reach for a personal additional expense.

I bought an Intel C++ Compiler 4.5 back in the day, but have lost
it since then. It integrated with Visual Studio 2003 IIRC. I
have downloaded and tried their current compiler on a free trial
basis, but I have not been able to get the developer environment
I need.

I keep looking, but I'm thinking CAlive is still my best bet,
assuming I can ever get it completed. :-)

--
Rick C. Hodgin

[Mr Flibble]

Your opinion is wrong. Writing unit tests is NOT a coding style it is
an essential part of the software development process used when creating
non-toy software.

Your software is obviously toy and of little inherent value beyond it
being a disguised form of proselytization that only has value to you and
your pet fish.

[Chris Ahlstrom]

bartc wrote this copyrighted missive and expects royalties:

> On 24/03/2018 23:13, Rick C. Hodgin wrote:
>> What alternatives are there to MSVC, and GCC and CLang?
>>
>> Are there any free compilers that are distinct and unique from
>> those code bases? The only one I am aware of is Intel's C++
>> compiler, and it's $1600 for the professional version per year,
>> which I also think is outrageous.
>
> $1600 in a professional environment is peanuts.

It's too much if gcc or clang can do the job 98% as well.

> How much is the annual salary of the person doing the programming? How
> much are the on-going business costs per employee for premises,
> computers, networking and everything else?
>
> If Intel's compiler offers improved code (over thousands of copies of
> applications), or even just a faster, more productive development cycle,
> then it may pay for itself anyway.
>
>> Intel should give away their
>> compilers because it would encourage people to use their CPUs
>> instead of other manufacturer CPUs.
>
> I don't think Intel are doing too badly, but I hardly think a $1600 cost
> for a tool is a significant factor when designing and manufacturing a
> new product.

Indeed.

--
The mind is its own place, and in itself
Can make a Heav'n of Hell, a Hell of Heav'n.
-- John Milton

[Rick C. Hodgin]

On Sunday, March 25, 2018 at 10:55:08 AM UTC-4, Mr Flibble wrote:
> On 25/03/2018 11:58, Rick C. Hodgin wrote:
> > In my experience, it's a fairly common practice to do it this way.
> > And as I say, to me it's a coding style. The style of coding you
> > do involves writing unit tests or not.
> >
> > Just my opinion.
>
> Your opinion is wrong. Writing unit tests is NOT a coding style it is
> an essential part of the software development process used when creating
> non-toy software.
>

> Your software is obviously toy and of little inherent value...

There's a wide base of software developers who disagree with you.
There's also a wide base who agree with you. It's an opinion held
by all involved based on their needs.

My last word on the subject.

--
Rick C. Hodgin

[Ian Collins]

On 03/25/2018 11:36 PM, Rick C. Hodgin wrote:
> On Saturday, March 24, 2018 at 11:37:30 PM UTC-4, Ian Collins wrote:
>> On 03/25/2018 04:06 PM, Rick C. Hodgin wrote:
>>> On Saturday, March 24, 2018 at 10:55:41 PM UTC-4, Ian Collins wrote:
>>>> It would also be caught by tests....
>>> Tests are appropriate at times.
>>
>> The only case I can think of is one off non-production code that is
>> never going to be changed.
>
> I worked for a company in the mid-2000s that had six full-time
> developers, and three full-time unit test writers. They wrote
> test after test after test for the code we would write.
>
> I was never able to justify that degree of labor spent on writing
> tests when you, as a developer, are supposed to test the code you
> write as you go.

That's because you were doing it wrong - there shouldn't be unit test
writers, the developers should write their own tests.

> It's kind of the purpose of my single-step debugging in areas
> where I have changed something. With Visual Studio, you hover
> over a token name and if it's a variable of some kind it pops
> up its value or member list, and as you hover over each part
> it drops down into the child member contents, and into that
> member's children, etc. It all takes a few seconds to navigate.

Manually, not something you can do after every change on every build.

>>>>> The edit-and-continue debugger is an absolute essential tool for me.
>>>>> As is stepping through my code line-by-line and examining variables.
>>>>> It helps me to double-check things to overcome my shortcomings in
>>>>> coding.
>>>>
>>>> As do tests faster and with a lot more consistency.
>>>
>>> You've mentioned this coding style before. I'm glad it works for
>>> you. It's not my style or need for a lot of the coding I do. Some of
>>> my algorithms could benefit and I've written self-test code before.
>>
>> So you write code that you will never change and don't need to check for
>> regressions?
>
> I write code that I test before releasing it to our company's
> internal testers. And if there is a regression, I fix it.
>
> I've pushed for adding the type of testing you indicate at our
> company, but their view is:
>
> (1) Greatly increases the labor because you have to now:
> (1a) Write the new code, or
> (1b) Make changes to the existing code,
> (1c) Test your new / changed algorithm manually anyway,
> (1d) Write the test, or update the test code

Done correctly it will reduce the development cost. Developers will
spend more time writing code rather than chasing bugs. You will also
find bugs faster, the closers to its introduction a bug is found, the
cheaper it is to fix.

> (2) The fact that you're writing more than just changes to
> your code introduces the potential for errors in your
> tests, which then must be tracked down:
> (2a) Was the error a real error? Or a test error?
> (2b) Changes are made to code
> (2c) Possibly some additional changes need to be made
> to the tests

Errors in tests are usually the result of misunderstandings of or
ambiguities in the requirements. Both need fixing fast!

<snip>

>>> Different coding styles for different people.
>>
>> Unit tests aren't a style, they are a vital part of the software
>> development process!
>
> In some cases I agree. In others, the labor does not justify
> the gain ... in my opinion, and in the opinion of many others.
>
> It's a philosophical viewpoint. And as I get older, I am leaning
> more and more toward testing as I'm no longer able to be as fully
> comprehensive in my memory and abilities as I was when I was much
> younger. I do make mistakes as I get older, and I can see the
> value in testing more and more because of it.

Good!

--
Ian.

[Jorgen Grahn]

On Sat, 2018-03-24, Daniel wrote:
> On Friday, March 23, 2018 at 2:43:49 PM UTC-4, Rick C. Hodgin wrote:
>
>> does anybody have any ideas on how to make
>> Visual Studio 2015 or later go faster in debugging? It has a
>> great IDE, and edit-and-continue is excellent, but single-step
>> speed is slow enough I'm looking for another tool.
>
> I find it curious that you seem to be spending so much time in the debugger.
> I rarely, hardly ever, do. Is there something about how you approach a
> programming problem that requires you to be in the debugger that much?

There are different schools. There are good programmers (mostly
Windows-oriented ones AFAICT) who use step-wise debugging heavily, and
others who never do. It was discussed here (or in comp.lang.c) at
length a few years ago.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chris M. Thomasson]

Amen.

[David Brown]

Sometimes I find I am doing step-wise debugging quite heavily. But that
is often in connection with hardware issues in my code, running on small
microcontrollers - the kind of thing that is particularly hard to write
tests for. (How do you write good tests for code to run some hardware
that has only minimal documentation?) I could see "edit-and-continue"
programming fixes being occasionally useful in such circumstances, if it
were practical on the targets I use (it isn't). I could not imagine
trying to use it as a main development process, however.

[wyn...@gmail.com]

Rick C. Hodgin於 2018年3月24日星期六 UTC+8上午2時43分49秒寫道：
> Does anybody have any tools they use that are similar in ability
> to compile and debug C++ projects, but do so faster than Visual
> Studio?
>
> I'm waiting about 1 second between single steps in source code.
> I remote connected to a foreign server and it was faster there
> over our LAN than it is here locally when I debug this particular
> process.
>

I rarely use debugger, I use only in cases some codes produce results
not as expected, even for micro-controllers(more rarer).
In situation you mentioned, analyzing symptom and narrowing down to
something verifiable is the general method I would use.
Using debugger for finding issues between computers connected via
LAN, if I might envision, involves filtering lots of 'noises'. So you
would complain and ask for faster debugger tool.

Sorry not a direct answer. But anyway, having seen your discussions,
I decided a try using VS.

> In the alternative, does anybody have any ideas on how to make

> Visual Studio 2015 or later go faster in debugging? It has a
> great IDE, and edit-and-continue is excellent, but single-step

> speed is slow enough I'm looking for another tool. If I can
> correct my setup here so it goes faster, I'll be happy to try
> these tools.
>
> --
> Rick C. Hodgin

[Rick C. Hodgin]

On Monday, March 26, 2018 at 5:21:58 AM UTC-4, wyn...@gmail.com wrote:
> Rick C. Hodgin於 2018年3月24日星期六 UTC+8上午2時43分49秒寫道：
> > Does anybody have any tools they use that are similar in ability
> > to compile and debug C++ projects, but do so faster than Visual
> > Studio?
> >
> > I'm waiting about 1 second between single steps in source code.
> > I remote connected to a foreign server and it was faster there
> > over our LAN than it is here locally when I debug this particular
> > process.
> >
>
> I rarely use debugger, I use only in cases some codes produce results
> not as expected, even for micro-controllers(more rarer).
> In situation you mentioned, analyzing symptom and narrowing down to
> something verifiable is the general method I would use.
> Using debugger for finding issues between computers connected via
> LAN, if I might envision, involves filtering lots of 'noises'. So you
> would complain and ask for faster debugger tool.
>
> Sorry not a direct answer. But anyway, having seen your discussions,
> I decided a try using VS.

I think because the debugger facilities in Visual Studio are so
advanced, many Windows users have had a tool the *nix world with
a GCC/GDB-like toolchain hasn't, so there's an understandable divide.

I made a video a while back showing some of the advantages of the
edit-and-continue debugger:

Length 9:40. Demonstrates VS 2008 debugger. Visual Studio
2015 and later have more advanced debuggers. Not sure about
VS2012, never used it:

http://www.visual-freepro.org/videos/2014_02_13__demonstrate_x86_debugger.ogv

> > In the alternative, does anybody have any ideas on how to make
> > Visual Studio 2015 or later go faster in debugging? It has a
> > great IDE, and edit-and-continue is excellent, but single-step
> > speed is slow enough I'm looking for another tool. If I can
> > correct my setup here so it goes faster, I'll be happy to try
> > these tools.

VS2010 has proven just like I'd expect. I also re-installed VS2008
to see how it will do, but Win10 complained that part of what it
needed to run (for SQL Server 2005) was no longer supported in this
version of Windows... so maybe it will work, maybe it won't. You
never know for sure until you try.

--
Rick C. Hodgin

[David Brown]

On 26/03/18 13:58, Rick C. Hodgin wrote:
> On Monday, March 26, 2018 at 5:21:58 AM UTC-4, wyn...@gmail.com wrote:
>> Rick C. Hodgin於 2018年3月24日星期六 UTC+8上午2時43分49秒寫道：
>>> Does anybody have any tools they use that are similar in ability
>>> to compile and debug C++ projects, but do so faster than Visual
>>> Studio?
>>>
>>> I'm waiting about 1 second between single steps in source code.
>>> I remote connected to a foreign server and it was faster there
>>> over our LAN than it is here locally when I debug this particular
>>> process.
>>>
>>
>> I rarely use debugger, I use only in cases some codes produce results
>> not as expected, even for micro-controllers(more rarer).
>> In situation you mentioned, analyzing symptom and narrowing down to
>> something verifiable is the general method I would use.
>> Using debugger for finding issues between computers connected via
>> LAN, if I might envision, involves filtering lots of 'noises'. So you
>> would complain and ask for faster debugger tool.
>>
>> Sorry not a direct answer. But anyway, having seen your discussions,
>> I decided a try using VS.
>
> I think because the debugger facilities in Visual Studio are so
> advanced, many Windows users have had a tool the *nix world with
> a GCC/GDB-like toolchain hasn't, so there's an understandable divide.
>

Apart from the "edit and continue" support, which is something I don't
see much use of for my C or C++ code (I sometimes modify python code
live, but not C or C++), what does Visual Studio have that is so
"advanced" ? Why should I be interested in it for x86 development? (It
would be useless for my main work, as it does not support embedded
targets, remote debugging, hardware JTAG debugging, simulators, etc.)

[Scott Lurndal]

Chris Ahlstrom <OFee...@teleworm.us> writes:
>bartc wrote this copyrighted missive and expects royalties:
>
>> On 24/03/2018 23:13, Rick C. Hodgin wrote:
>>> What alternatives are there to MSVC, and GCC and CLang?
>>>
>>> Are there any free compilers that are distinct and unique from
>>> those code bases? The only one I am aware of is Intel's C++
>>> compiler, and it's $1600 for the professional version per year,
>>> which I also think is outrageous.
>>
>> $1600 in a professional environment is peanuts.
>
>It's too much if gcc or clang can do the job 98% as well.

The intel compiler does a better job of autovectorization
than the open-source competition, which is one selling point
for ICC, but that is specific to certain workloads (HPC).

[Paavo Helde]

FWIW, Visual Studio supports remote debugging. It also appears to
support cross-compilation to ARM.

Granted, it it is more suited for certain project types and for certain
development styles. To each his own. For example, I like when I can
click open deep container (std::map) hierarchies in a breakpoint and
actually see what data they contain. Not that I would need this every
day (if I needed this every day an automated non-clicking solution would
be preferable).

Cheers
Paavo

[Melzzzzz]

I just installed intel C and C++ compiler . Whooping 13GB on disk.
I guess they have some tools besides compiler ;)
ihttps://software.intel.com/en-us/system-studio/choose-download
It is free now.

--
press any key to continue or any other to quit...

[David Brown]

What about debugging via jtag with ARM microcontrollers? That's a
little different from, say, debugging ARM Linux (or WinRT) processes.

[Rick C. Hodgin]

On Monday, March 26, 2018 at 11:37:06 AM UTC-4, Paavo Helde wrote:
> FWIW, Visual Studio supports remote debugging. It also appears to
> support cross-compilation to ARM.

In Visual Studio 2017 it also supports the full GCC/GDB toolchain:

What's New in Visual Studio 2017?
https://www.youtube.com/watch?v=TYEoJorFn54

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

Linux development with Visual Studio 2017
https://www.youtube.com/watch?v=XIiFuBczd6A

> Granted, it it is more suited for certain project types and for certain
> development styles. To each his own. For example, I like when I can
> click open deep container (std::map) hierarchies in a breakpoint and
> actually see what data they contain. Not that I would need this every
> day (if I needed this every day an automated non-clicking solution would
> be preferable).

There is an add-on for Visual Studio called Visual Assist X by
Whole Tomato that extends its abilities into some really amazing
extensions that I use daily.

https://www.wholetomato.com

It's the best development platform in existence. I've looked for
others. One written called Sun Studio by Sun Systems for the now
"defunct" Sun OS was the second best I've seen, as Oracle has kind
of destroyed that whole platform.

My goals for CAlive are to produce a Visual Studio-like experience,
and to integrate compiler info into the IDE.

--
Rick C. Hodgin

[Scott Lurndal]

DSTREAM is the typical answer, but the external debugger
protocol and capablities are well documented by ARM and thus
could be integrated with existing debuggers.

https://developer.arm.com/products/software-development-tools/debug-probes-and-adapters/dstream

[Paavo Helde]

I do not know anything about jtag, so I have no idea. Googling JTAG MSVC
turns up some third-party add-ons like https://visualgdb.com/ - not sure
if this would be feasible for anything.

[wyn...@gmail.com]

Rick C. Hodgin於 2018年3月26日星期一 UTC+8下午7時58分52秒寫道：

I read again your original post and found I missed a point that you
were trying 'remote debug'. I had such experiences long ago on DOS
(using WATCOM C/C++, IIRC, the so called 'advanced' feature may had
existed for long time). Such things are no longer necessary in
Linux.

From the video link you provided. I noticed something
1: In serious C++ program, a catch-all block is nearly necessary in
main block, IMO. Otherwise some part of throw behavior happened in
some programs (maybe included) may actually be undefined.
The try/catch should not be said(by the standard) and therefore
understood as the 'standard error handling machanism`, by which
the general sense of error handling can not be correctly and nicely
done (try/catch or setjmp were once called the advanced error
handling machanism).
2: In C++, "what you see might not be what you think". This applies to
general C++ programs and 1: as well. Since the behavior of C++
codes depend more havily on what the header files contain, which
are normally invisible to programmers and also suffer changes.

Another thing is about class containing virtual members (because
another topic in this forum mentioned this). There are also things
hidden from average understanding, but I am not going to say more
about this here.

Let's divide bugs into 3 catagories
a) bugs from the logic of solving the problems
b) bugs from implementation of the problem-solving
c) bugs from underlying libraies or the compiler

My hobby is limiting the development tool dependency to essentially
minimum. Using debugger to find bugs is not the primary resort in
general except c). At least, nowadays programs are actually composed
of many concurrently running sub-programs. You can't use debugger.
In time I had to do many 'step's in debuging, I just do it, even 1000
steps, in considering that such a thing won't happen twice.

[Rick C. Hodgin]

On Tuesday, March 27, 2018 at 2:04:00 AM UTC-4, wyn...@gmail.com wrote:
> Let's divide bugs into 3 catagories
> a) bugs from the logic of solving the problems
> b) bugs from implementation of the problem-solving
> c) bugs from underlying libraies or the compiler
>
> My hobby is limiting the development tool dependency to essentially
> minimum. Using debugger to find bugs is not the primary resort in
> general except c). At least, nowadays programs are actually composed
> of many concurrently running sub-programs. You can't use debugger.
> In time I had to do many 'step's in debuging, I just do it, even 1000
> steps, in considering that such a thing won't happen twice.

It's fairly rare any more that I have algorithms which operate in a
manner other than I expect. My developer skills are mature and I do
know how to write the algorithms I intend, both syntactically and
efficiently. So the errors are rarely in my coding skills. I presume
this is true for nearly all mature developers as well.

The things I check are mostly to make sure I typed in everything as I
intended. Despite my best efforts in writing and reviewing what I
wrote, I still have mistakes in coding get past me. I have no idea
how it happens either because in my validation I can even re-read a
thing I wrote as I intended it to be, only to have it mechanically
translated through my fingers into something else. It's like I'm
completely blind to what it really says because I'm remembering it
from my intention in memory, rather than what's really there.

This, of course, happens in the moment. If I come back to something
a day later it's not like that. Then I read what's actually there.

In any event, I typically write a few hundred lines of code, and
then go in and single-step through it and test it all, then go on
and continue on again. The edit-and-continue debugger allows me to
fix the bugs rapidly as I'm sitting there with solid validation or
verification that the code works or doesn't work.

The Visual Studio Debugger is a very powerful tool. It's served as
the model for what I intend to have in CAlive, though with my goal
in CAlive to be a much faster debugger, one like what we saw back
in the days of CodeView on text-based screens.

--
Rick C. Hodgin

[Kenny McCormack]

In article <fa58d0b4-1ae4-41d2...@googlegroups.com>,

Rick C. Hodgin <rick.c...@gmail.com> wrote:
>Does anybody have any tools they use that are similar in ability
>to compile and debug C++ projects, but do so faster than Visual
>Studio?

How about RDC?

Oh, I just remembered. RDC is (and always will be) vaporware.

You want something that actually exists, right?

--
"Unattended children will be given an espresso and a free kitten."

[Kenny McCormack]

In article <8b8ba1fe-2a0c-4ce8...@googlegroups.com>,

Rick C. Hodgin <rick.c...@gmail.com> wrote:

...

>I keep looking, but I'm thinking CAlive is still my best bet,

>assuming I can ever get it started. :-)

FIFY
--
Those on the right constantly remind us that America is not a
democracy; now they claim that Obama is a threat to democracy.

[Rick C. Hodgin]

On 4/16/2018 5:38 PM, Kenny McCormack wrote:
> In article <fa58d0b4-1ae4-41d2...@googlegroups.com>,
> Rick C. Hodgin <rick.c...@gmail.com> wrote:
>> Does anybody have any tools they use that are similar in ability
>> to compile and debug C++ projects, but do so faster than Visual
>> Studio?
>
> How about RDC?

Wouldn't that be great? :-)

> Oh, I just remembered. RDC is (and always will be) vaporware.

My life isn't over yet, Kenny. Your statement is speculation at best.

> You want something that actually exists, right?

Yes. I haven't found anything. I'm still stuck with VS 2015.

--
Rick C. Hodgin