From: Leslie Milburn on

"David Schwartz" <davids(a)webmaster.com> wrote in message
news:aaf00582-79f0-4dce-aeab-24fc0da3e4c4(a)l11g2000pro.googlegroups.com...

> If your code depends on evaluation behavior that is not guaranteed by
> the language, you had better fix it. The next version of the same
> compiler might break it. And if it is guaranteed by the language, then
> you can rely on that guarantee. That's what such guarantees are for.

Thats my point. All code makes assumptions and in the commercial world
spending time to protect code from problems which do not yet exist, is
deemed to be a waste of money. So yes your purist attitude is an
overreaction, many of us deal in the real world. The only time any company I
worked for had to do major code changes due to the compiler change was going
from Microsoft C for DOS to the IBM CII compiler. Since that time
continuously upgrading Microsoft C, (aka Visual C/C++) there has been no
significant problems.

If you change to a completely different compiler, then you will have to do a
full evaluation of all code - worring bout trivial things like the order of
binary data is *easily* solved.

BTW: Left to right and right to left are not "guaranteed by the language" -
at least not every language.

> Please let me know what software you have developed according to this
> philosophy so I can avoid it like the plague. I don't want to have to
> audit every line of code, and possibly rewrite huge chunks, just to
> upgrade my compiler.

Again another overreaction. To give an example, what do you think happens to
database contents across versions of products. Data is moved, table
structures altered, stored procedures changed. So are you now going to NOT
use every product because Heaven forbid things get changed. This is the norm
and storing binary data is no different.

> And god help me if I don't have the source code! This same philosophy
> leads to code that breaks on OS upgrades, CPU upgrades, library bugfix
> updates, and the like. If you're not around to (or willing to) rewrite
> all the code that broke, I won't even be able to do it myself.

I agree and thats why I am not a fan of MFC .NET or 3rd Party libraries. Of
course you realise we are talking custom build - the problem with this is
that programmers of today are simply not up to the job if they were thrown
back into the world of 640K memory requiring overlays etc.


From: David Schwartz on
On Mar 25, 3:49 pm, "Leslie Milburn" <CD...(a)NOSPAM.bigpond.com> wrote:

> "David Schwartz" <dav...(a)webmaster.com> wrote in message

> news:aaf00582-79f0-4dce-aeab-24fc0da3e4c4(a)l11g2000pro.googlegroups.com...

> > If your code depends on evaluation behavior that is not guaranteed by
> > the language, you had better fix it. The next version of the same
> > compiler might break it. And if it is guaranteed by the language, then
> > you can rely on that guarantee. That's what such guarantees are for.

> Thats my point.

What's your point?

> All code makes assumptions

Please do not confuse guarantees with assumptions.

> and in the commercial world
> spending time to protect code from problems which do not yet exist, is
> deemed to be a waste of money.

The problem does exist now. That your code relies on something that is
not guaranteed is a failure -- and it's a failure *right* *now*.

> So yes your purist attitude is an
> overreaction, many of us deal in the real world.

I've been a professional software developer for 24 years. I develop
real world software, I'm not an academic.

> The only time any company I
> worked for had to do major code changes due to the compiler change was going
> from Microsoft C for DOS to the IBM CII compiler. Since that time
> continuously upgrading Microsoft C, (aka Visual C/C++) there has been no
> significant problems.

That's because most professionals are smart enough *not* to follow bad
advice like yours.

> > Please let me know what software you have developed according to this
> > philosophy so I can avoid it like the plague. I don't want to have to
> > audit every line of code, and possibly rewrite huge chunks, just to
> > upgrade my compiler.

> Again another overreaction. To give an example, what do you think happens to
> database contents across versions of products. Data is moved, table
> structures altered, stored procedures changed. So are you now going to NOT
> use every product because Heaven forbid things get changed. This is the norm
> and storing binary data is no different.

This is such a non sequiter, it doesn't deserve any response.
Conscious decisions to make changes to data structures are in no way
comparable to failing to consciously design data structures.

The advice you are giving is *terrible*. It has *no* upside -- it
doesn't even make things any easier. And the downside is huge --
subsequent platform changes may cause the code to fail in subtle and
unpredictable ways. It is indefensible. That you would suggest it,
without caveats, to someone looking for help is inexcusable.

Yes, I have very strong feelings about software quality. We are
getting to the point where software is controlling more and more of
our world and being given more and more responsibility. People in the
field need to start acting like responsible professionals rather than
toying kids.

DS
From: Leslie Milburn on

"David Schwartz" <davids(a)webmaster.com> wrote in message
news:faf4f807-0f07-440c-941b-731dacc06b51(a)s2g2000prd.googlegroups.com...

> Please do not confuse guarantees with assumptions.

Never said I did.

> The problem does exist now. That your code relies on something that is
> not guaranteed is a failure -- and it's a failure *right* *now*.

No the problem will *NOT* exist *UNLESS* they change compilers - your words
not mine. So right now to follow a fixed data format for binary data is NOT
a problem.

> I've been a professional software developer for 24 years. I develop
> real world software, I'm not an academic.

Good for you, I've been programming commercially for just under 30 years. I
am surprised you have been around for so long and still hold such a purist
viewpoint. Look up Pragmatic in the dictionary and take a chill pill.

> That's because most professionals are smart enough *not* to follow bad
> advice like yours.

Bad advice, you really make me laugh - see above. My god what an
over-reaction.

> This is such a non sequiter, it doesn't deserve any response.
> Conscious decisions to make changes to data structures are in no way
> comparable to failing to consciously design data structures.

Obviously no response because you know I am correct. But you are missing the
point, It is not a design decision it is a data format.

Look at the OP and you will see that it is about storing binary data in a
cfg file or similar. There is no code structure per se other than it would
be in a fixed format which you suddenly panic about because the bytes might
get reversed in 2, 3 or more years *if* you change compilers - your
assumption, not even a guarantee !!!. Gee you really are over-reacting and
do sound like an academic, I am afraid to say. In the real world pragmatic
coding always comes first - the 100% solution does not exist.

> The advice you are giving is *terrible*. It has *no* upside -- it
> doesn't even make things any easier.

The upside is that it would take very little time to produce the file, I
would expect 1/2 a day even for a beginner C programmer. Spending any more
time on it than that is wasting the project's budget.

> And the downside is huge --
> subsequent platform changes may cause the code to fail in subtle and
> unpredictable ways. It is indefensible. That you would suggest it,
> without caveats, to someone looking for help is inexcusable.

Even if they change to a Pascal compiler they could still read the binary
data because it is in a known format. The coding side of it is
irrelevant/trivial.

> Yes, I have very strong feelings about software quality.

So do I, but I think you are talking about code quality versus project
quality. Time and Budget are equally as important as the tasks themselves.
Hopefully you work somewhere which has an open cheque book and time to
spare - I never have.

> We are
> getting to the point where software is controlling more and more of
> our world and being given more and more responsibility. People in the
> field need to start acting like responsible professionals rather than
> toying kids.

Wow, how mighty you are. How much better than everyone else you sound - I
have never heard of you though.


From: David Schwartz on
On Mar 26, 12:01 am, "Leslie Milburn" <CD...(a)NOSPAM.bigpond.com>
wrote:

> "David Schwartz" <dav...(a)webmaster.com> wrote in message
>
> news:faf4f807-0f07-440c-941b-731dacc06b51(a)s2g2000prd.googlegroups.com...
>
> > Please do not confuse guarantees with assumptions.
>
> Never said I did.

No, I said you did. You equated relying on guarantees in the language
with relying on things that specifically not guaranteed.

> > The problem does exist now. That your code relies on something that is
> > not guaranteed is a failure -- and it's a failure *right* *now*.

> No the problem will *NOT* exist *UNLESS* they change compilers - your words
> not mine. So right now to follow a fixed data format for binary data is NOT
> a problem.

How do you know the OP isn't about to change compilers? You gave him
this advice with *no* warnings whatsoever.

> > I've been a professional software developer for 24 years. I develop
> > real world software, I'm not an academic.

> Good for you, I've been programming commercially for just under 30 years. I
> am surprised you have been around for so long and still hold such a purist
> viewpoint. Look up Pragmatic in the dictionary and take a chill pill.

I am being pragmatic. There is *no* advantage to your suggested method
and huge disadvantages. Suggesting it is as pragmatic as giving a
chainsaw to 7 year old.

> > That's because most professionals are smart enough *not* to follow bad
> > advice like yours.

> Bad advice, you really make me laugh - see above. My god what an
> over-reaction.

I really hope the people who build bridges and design buildings take
their job responsibilities more seriously than you do.

> > This is such a non sequiter, it doesn't deserve any response.
> > Conscious decisions to make changes to data structures are in no way
> > comparable to failing to consciously design data structures.

> Obviously no response because you know I am correct. But you are missing the
> point, It is not a design decision it is a data format.

> Look at the OP and you will see that it is about storing binary data in a
> cfg file or similar. There is no code structure per se other than it would
> be in a fixed format which you suddenly panic about because the bytes might
> get reversed in 2, 3 or more years *if* you change compilers - your
> assumption, not even a guarantee !!!. Gee you really are over-reacting and
> do sound like an academic, I am afraid to say. In the real world pragmatic
> coding always comes first - the 100% solution does not exist.

Obviously, you will continue to write sucky software and give bad
advice no matter what I say. So long as you continue to do so, I'll
continue to warn people not to listen to you.

> > The advice you are giving is *terrible*. It has *no* upside -- it
> > doesn't even make things any easier.

> The upside is that it would take very little time to produce the file, I
> would expect 1/2 a day even for a beginner C programmer. Spending any more
> time on it than that is wasting the project's budget.

And it would take the same amount of time to do it in text or lift a
good configuration library.

> > Yes, I have very strong feelings about software quality.

> So do I, but I think you are talking about code quality versus project
> quality. Time and Budget are equally as important as the tasks themselves..
> Hopefully you work somewhere which has an open cheque book and time to
> spare - I never have.

It doesn't take any longer or cost any more to do it the right way.
All it takes is the good sense to realize that what you are saying is
simply *wrong*. It is wrong to rely on behavior that is not guaranteed
-- we do it where we have no other reasonable choice and we *document*
that decision *every* *place* we make it.

> > We are
> > getting to the point where software is controlling more and more of
> > our world and being given more and more responsibility. People in the
> > field need to start acting like responsible professionals rather than
> > toying kids.

> Wow, how mighty you are. How much better than everyone else you sound - I
> have never heard of you though.

And even if you had, you wouldn't have listed to what I said anyway.

DS
From: Alf P. Steinbach on
* David Schwartz:
> On Mar 24, 10:00 am, "ScottMcP [MVP]" <scott...(a)mvps.org> wrote:
>
>> You can create a struct or class that contains all of the data members
>> to be saved. Something like
>>
>> struct config
>> {
>> int structlength;
>> int x,y,dx,dy;
>> char text[50];
>> ...
>>
>> } theconfig;
>
> No, you can't do that. Files are arrays of bytes and to have a file
> format, it must have a defined structure for each byte. If the next
> version of his compiler stores 'int's a different way, he won't be
> able to read back the files he wrote out.

Sorry, no, that's incorrect (in context): basic data representation is not a
problem for a given OS such as Windows, which is what this group is about.

It's the OS' API that determines int representation etc., not the language.
That's because a language that doesn't support the OS' API is a dead fish. So to
speak.

What *can* be a problem is padding of the struct. A simple compile time assert
deals effectively with that.

And what *is* a problem is that binary is not especially editable. The OP talked
about [.ini] files. Binary doesn't improve on the OP's base 64 encoding in that
respect, i.e., it's more like a non-solution.

A simple solution for that is Unicode, storing the [.ini] files as UTF-8, say.


Cheers & hth.,

- Alf