Wednesday, February 11, 2015

Digest for comp.lang.c++@googlegroups.com - 24 updates in 5 topics

David Brown <david.brown@hesbynett.no>: Feb 11 09:58AM +0100

On 10/02/15 17:14, Christopher Pisz wrote:
 
> Ok....so by these statistics, if I were to consider Flibble's comment
> and "reconsider my OS", I would drop a customer base that covers >
> 75-85% of the market ....makes sense to me!
 
If you are selling software to the general public, then Windows is
obviously the most important market - I don't think even Mr. Flibble
/actually/ disagrees with that. But an increasing proportion of
developers find it sensible to write cross-platform code and access the
remaining 15% of the market (and for some niches, the proportion of
non-Windows systems is much higher). And as you should have learned
from this thread, a lot of work towards cross-platform portability is
simply good programming practice rather than continuing DOS/Windows bad
habits.
 
 
> At any rate, I don't know what you are trying to argue.
 
I was arguing against your claim that 99% of XP users will upgrade their
OS, so there is no reason for MS to continue supporting it.
Christopher Pisz <nospam@notanaddress.com>: Feb 11 10:48AM -0600

On 2/11/2015 2:58 AM, David Brown wrote:
> from this thread, a lot of work towards cross-platform portability is
> simply good programming practice rather than continuing DOS/Windows bad
> habits.
 
Then what does "reconsider your OS" mean?
 
 
>> At any rate, I don't know what you are trying to argue.
 
> I was arguing against your claim that 99% of XP users will upgrade their
> OS, so there is no reason for MS to continue supporting it.
 
Ok, lets say your statistics are correct. You want Microsoft to support
a 14 year old OS for 15% of users? and you expect that those 15% are
going to continue to use a 14 year old OS for how long? Even after
hearing "Sorry we can't help you. Your OS is unsupported" in response to
almost every support call they make to anyone?
 
I believe that number to be much lower and I believe it is 1) Companies
penny pinching who will find themselves left with little choice. 2) Joe
use who only surfs the internet in IE 6 and does little else, whom will
also upgrade after his web pages stop loading without error in the near
future.
 
The number of technologies that are not available on XP is a problem.
I believe you can only run .NET framework 4 and lower and DX9 and lower
on XP.
scott@slp53.sl.home (Scott Lurndal): Feb 11 05:30PM


>The number of technologies that are not available on XP is a problem.
>I believe you can only run .NET framework 4 and lower and DX9 and lower
>on XP.
 
And 90% of applications for XP use MFC and could care less about
either .NET or DX9.
Christopher Pisz <nospam@notanaddress.com>: Feb 11 12:53PM -0600

On 2/11/2015 11:30 AM, Scott Lurndal wrote:
> Christopher Pisz <nospam@notanaddress.com> writes:
> And 90% of applications for XP use MFC and could care less about
> either .NET or DX9.
 
and of those applications that use MFC how many are still being
supported by their developers? Have you ever tried your hand at the
nonsensical outdated mess that is MFC? I've convinced every single
project manager I've ever had to drop that mess with ease.
 
This entire off shoot of the thread is tantamount to arguing that some
government agencies still use FORTRAN running on Solaris, so I should
switch to being a FORTRAN programmer and punch my code into cards.
Ian Collins <ian-news@hotmail.com>: Feb 12 08:09AM +1300

Christopher Pisz wrote:
 
> This entire off shoot of the thread is tantamount to arguing that some
> government agencies still use FORTRAN running on Solaris, so I should
> switch to being a FORTRAN programmer and punch my code into cards.
 
Modern Fortran is well supported on Solaris :)
 
--
Ian Collins
scott@slp53.sl.home (Scott Lurndal): Feb 11 07:42PM

>> government agencies still use FORTRAN running on Solaris, so I should
>> switch to being a FORTRAN programmer and punch my code into cards.
 
>Modern Fortran is well supported on Solaris :)
 
Although card readers never were supported on Solaris :-)
drew@furrfu.invalid (Drew Lawson): Feb 11 08:46PM

In article <mbg14m$5ie$1@dont-email.me>
>> simply good programming practice rather than continuing DOS/Windows bad
>> habits.
 
>Then what does "reconsider your OS" mean?
 
Why do you expect every poster to explain what F[l]ibble meant?
Seems pretty needy.
 
>> OS, so there is no reason for MS to continue supporting it.
 
>Ok, lets say your statistics are correct. You want Microsoft to support
>a 14 year old OS for 15% of users?
 
Bug-fix subscriptions would be a lot of money.
 
>going to continue to use a 14 year old OS for how long? Even after
>hearing "Sorry we can't help you. Your OS is unsupported" in response to
>almost every support call they make to anyone?
 
[Pst, it would no longer be "unsupported" if they supported it.]
 
My previous job dealt with a custom system for the US Navy,
written/expanded over 25 years, and running on XP. That project
alone, between the dev systems and the several installation sites,
was several hundred PCs, with several hundred individual XP licenses.
 
The Navy would have been thrilled to pay maintenance rather than
deal with the incompatibilities between XP and Win7, and the down
time from bugs caused by slapping another layer over a library
written by a defunct company.
 
That system was far from unique. The potential revenue -- for
little actual work -- from the US Government alone was huge.
 
The government doesn't just pour out money for rewriting something
just because it is old (even when that would be a good idea).
Maintenance is standing funding. Development is discretionary.
 
In fact, that is my previous job because the sequester stuff blocked
the development work that I was supposed to be doing.
 
--
In Dr. Johnson's famous dictionary patriotism is defined as the
last resort of the scoundrel. With all due respect to an enlightened
but inferior lexicographer I beg to submit that it is the first.
-- Ambrose Bierce
Vir Campestris <vir.campestris@invalid.invalid>: Feb 11 09:46PM

On 11/02/2015 08:58, David Brown wrote:
> from this thread, a lot of work towards cross-platform portability is
> simply good programming practice rather than continuing DOS/Windows bad
> habits.
 
I think Android is a pretty important market too. The trouble is there
are a variety of CPUs, so you really need to stick to Java.
 
Andy
Ian Collins <ian-news@hotmail.com>: Feb 12 11:00AM +1300

Drew Lawson wrote:
> deal with the incompatibilities between XP and Win7, and the down
> time from bugs caused by slapping another layer over a library
> written by a defunct company.
 
Oh how I enjoy working on a platform with a binary compatibility guarantee!
 
--
Ian Collins
Christopher Pisz <nospam@notanaddress.com>: Feb 11 04:15PM -0600

On 2/11/2015 2:46 PM, Drew Lawson wrote:
 
>> Then what does "reconsider your OS" mean?
 
> Why do you expect every poster to explain what F[l]ibble meant?
> Seems pretty needy.
 
Human speech patterns.
If I argue against a premise and you argue against that, then one would
naturally think you are for the premise....unless these posters just
like to argue pointlessly for lack of anything better to do, which is my
conclusion.
 
 
 
>> hearing "Sorry we can't help you. Your OS is unsupported" in response to
>> almost every support call they make to anyone?
 
> [Pst, it would no longer be "unsupported" if they supported it.]
 
Just because Microsoft fictionally supported it would not mean that
developers whom had needs of technology that doesn't run on it, would
also. Unless you assume MS would magically make .NET 4.5 and DX11+ work
on it, which would be a feat.
 
Doesn't matter. 10 year lifetime.
 
 
> Maintenance is standing funding. Development is discretionary.
 
> In fact, that is my previous job because the sequester stuff blocked
> the development work that I was supposed to be doing.
 
Instead, the government wastes trillions in tax dollars, because they
don't want to follow the 10 year rule. I've worked DOD, seen it first
hand. The waste was atrocious and criminal.
Melzzzzz <mel@zzzzz.com>: Feb 12 12:12AM +0100

On Wed, 11 Feb 2015 21:46:38 +0000
> > rather than continuing DOS/Windows bad habits.
 
> I think Android is a pretty important market too. The trouble is
> there are a variety of CPUs, so you really need to stick to Java.
 
You can stick anything with Java...
 
DSF <notavalid@address.here>: Feb 11 12:40AM -0500

On Tue, 10 Feb 2015 09:54:14 +0100, David Brown
>> case alone.
 
>NTFS does not mangle case - it is a case-preserving filesystem. If you
>save a file as "GetVolumeInfo.c", that's what you get on the disk.
 
I was not blaming NTFS. I know it's the compiler that's doing the
case mangling.
 
 
>Okay, so this is not an issue here. But aim for consistency and /try/
>to save your C files as ".c". Maybe one day you will be using a serious
>compiler and working on a serious OS.
 
I was only trying to capitalize C as the name of the language,
somehow I wound up typing .C as well. I don't normally (if ever) use
caps for extensions.
 
 
>(I am not a fan of upgrading just for the sake of getting the latest and
>greatest, and I fully understand the benefits of sticking to an old but
>known tool - but there are limits!)
 
Yes, I know. I don't consider getting used to a new compiler to be
as big a problem as the code rewriting and (sigh) subsequent bug
chasing. When I sit down at the computer to code (or almost anything
else), it's like I've stepped into a time machine stuck on fast
forward. I'll do something that felt like it took ten minutes only to
look at the clock and see two hours have passed. In other words: Few
weeks? Try several months!
 
>problem yourself in this process - the exercise of "finding a minimal
>compilable sample that demonstrates the problem" is as important to the
>person with the problem as to those trying to help.
 
I don't even remember what my last paragraph was referring to.
(Another problem impeding coding.) I did at least figure out why the
compiler's code is the way it is. (See my latest post to the original
post.) Unfortunately, fixing the problem involves memory corruption
debugging: Perhaps the only thing in coding I can see referring to as
"EVIL" and not consider it overkill! :o)
 
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
DSF <notavalid@address.here>: Feb 11 03:34AM -0500

On Mon, 09 Feb 2015 19:26:42 +1300, Ian Collins <ian-news@hotmail.com>
wrote:
 
>DSF wrote:
 
>> Explained in my updated post to my post.
 
>Which updated post?
 
In my reply to your first reply to "Strange structure initialization
problem." I typed:
 
I replied to this last night, but I don't see it in the group.
Apologies if a second shows up!
 
Evidentially, it somehow got titled "off". Probably because my F
key repeats sometimes and I do a search of the post for "off" in case
it was supposed to be "of." Somehow, instead of searching, I posted.
 
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
David Brown <david.brown@hesbynett.no>: Feb 11 10:05AM +0100

On 11/02/15 06:40, DSF wrote:
>> save a file as "GetVolumeInfo.c", that's what you get on the disk.
 
> I was not blaming NTFS. I know it's the compiler that's doing the
> case mangling.
 
Compilers don't mangle the case of filenames for source code, since they
don't write source code files. It's the IDE or editor that can do the
mangling. Keep a clear idea of the difference between an IDE and a
compiler - it will help when you change tools.
 
> forward. I'll do something that felt like it took ten minutes only to
> look at the clock and see two hours have passed. In other words: Few
> weeks? Try several months!
 
The sooner you invest that time, the sooner you will get a return on
your investment - and the less code you will have to check using a new tool.
 
> post.) Unfortunately, fixing the problem involves memory corruption
> debugging: Perhaps the only thing in coding I can see referring to as
> "EVIL" and not consider it overkill! :o)
 
I wasn't referring to a specific post in this thread, just a general
rule of asking for help in a newsgroup like this.
DSF <notavalid@address.here>: Feb 11 04:54PM -0500

On Tue, 10 Feb 2015 10:11:41 +0100, Marcel Mueller
 
>Turn global register optimizations on (or however this was called at
>Borland) and it will likely look more pretty. But your debugger will
>dislike the result.
 
* It's just called Register Variables. Choices: None, Register
Keyword, and Automatic. It's set to automatic and I know it uses
them. Both from looking at assembler code and the fact that variables
can become inaccessible to the watch debugger (Variable 'c' has been
optimized and is not available.) when they go out of their real scope
in a function. Real scope meaning even though the variable has the
scope of the function from the source code side, it was stored in a
register and is no longer used, freeing the register for other use.
 
>> only one exit point.
 
>The code in between usually need the registers for something else or
>calls functions that do not guarantee to preserver their values.
 
With: ret = GetVolumeInfoW(path, &vi), the stack contains:
pointer to vi
pointer to path
pointer to ret
return address.
 
In the assembly code I write, I just have retval be the first value
on the parameter line:
PROCSTART Div64By64, retval:DWORD, a:int64, b:int64
and access the return value through retval. I don't see the need to
create a local retval at start and then copy it to the stack 'pointer
to ret' before exit. A function could avoid changing the contents of
retval under certain conditions by using a temp. But I don't think
anyone expects a variable left of the = to be left unmodified.
(Unless, of course, there is something in the standard specifying that
a LHS might not change.)
 
 
>Furthermore the debugger cannot access variable values that have no
>memory representation. So using a register is not an option as long as
>you have debugging enabled.
 
Mine seems to. (See above.*) But only for the time the variable
exists.
1 void Foo(void)
2 {
3 int c;
4 ...
5 for(c = 0; c < 10; c++)
6 {
7 ...
8 }
9 ...
}
Variable 'c' is "optimized and is not available" until line 6. In
source line 5 of the executable code EBX is XOR'd with itself (c=0;).
'c', in the form of EBX, is "watchable" until line 9, where EBX is
used for something else.
 
>the value of this constant. That is the reason why they are normally
>placed in the DATA segment rather than TEXT. This behavior is no longer
>valid, but your compiler might still be compatible to that.
 
That's why I explicitly used char[] = for the example. This would
require a copy.
 
>first symbol in the data segment of your compilation unit (.obj) and the
>debugger uses the last symbol from the previous compilation unit,
>unaware of compilation units.
 
Makes sense.
 
>Activate the assembler output of the compiler and you will see a
>reasonable reference.
 
In a stand-alone compilation of GetVolumeInfo, there are three
functions that return an IOERRORS structure. All three of them have
their own separate 8 byte data segment allocation with names like
"$eiabhgka" that are not exported or provided in the debugger
information.
 
 
>Normally I would recommend to run your program with a memory analyzer
>like valgrind. But with that old platform you may not have any option
>like this.
 
I asked here or clc a while back and they confirmed my search
results. Valgrind is Linux only.
 
It comes with CodeGuard. But CodeGuard depends on replacing the RTL
with its own version. Replacing many RTL functions with those of my
own seems to give CodeGuard problems. It has a penchant for finding
memory overruns that I cannot find in the code.
 
>> above and changed the last to jmp @8!
 
>This is the common sub expression optimization. It has to be turned on
>and the code has to fit into the analysis window.
 
Enabling common sub expression optimization resulted in the address
referenced by the FBaseString... to be placed in ESI. Other than
that, the code was repeated at each return followed by a jump to the
register POPs.
 
 
>As rule of thumb: do not use the type char* anywhere in your C++ code.
>Use your string class or const char* only. This will prevent you from
>many problems.
 
That's a given. Unlike char[] or char[30], char * is a pointer to a
static string; no copying involved.
 
>I did not take care of wchar_t in my post. Everything which applies to
>char applies to wchar_t as well.
 
>Marcel
 
Thanks again,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
woodbrian77@gmail.com: Feb 10 10:53PM -0800

On Friday, February 6, 2015 at 2:07:27 PM UTC-6, Mr Flibble wrote:
> >> Why do people keep calling me "Fibble"? I am Flibble.
 
> > Lack of sausages.
 
> Perhaps.
 
Perhaps we can use this thread for programmy nominations. How about
nominating me for best on line code generator?
 
Brian
Ebenezer Enterprises
Christian Gollwitzer <auriocus@gmx.de>: Feb 11 09:33AM +0100


>> Perhaps.
 
> Perhaps we can use this thread for programmy nominations. How about
> nominating me for best on line code generator?
 
Then I'm a code generator generator.
 
Christia
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 11 06:08PM


>> Perhaps.
 
> Perhaps we can use this thread for programmy nominations. How about
> nominating me for best on line code generator?
 
Only dorks nominate themselves for awards your dork.
 
/Flibble
Daniel <danielaparker@gmail.com>: Feb 11 10:28AM -0800

On Friday, February 6, 2015 at 2:23:47 PM UTC-5, Mr Flibble wrote:
> Why do people keep calling me "Fibble"? I am Flibble.
 
Oh come on, that's nothing to qibble about.
 
Daniel
scott@slp53.sl.home (Scott Lurndal): Feb 11 07:03PM

>On Friday, February 6, 2015 at 2:23:47 PM UTC-5, Mr Flibble wrote:
>> Why do people keep calling me "Fibble"? I am Flibble.
 
>Oh come on, that's nothing to qibble about.
 
Shirley that would be qlibble?
Vir Campestris <vir.campestris@invalid.invalid>: Feb 11 09:47PM

On 11/02/2015 18:08, Mr Flibble wrote:
> Only dorks nominate themselves for awards your dork.
 
I've hear "your highness" but "your dork" is a new one!
Boris Kolpackov <boris@codesynthesis.com>: Feb 11 06:44AM -0600

I am pleased to announce the release of ODB 2.4.0.
 
ODB is an open source object-relational mapping (ORM) system for C++. It
allows you to persist C++ objects to a relational database without having
to deal with tables, columns, or SQL and without manually writing any of
the mapping code.
 
Major new features in this release:
 
* Support for bulk operations in Oracle and SQL Server. Bulk operations
can be used to persist, update, or erase a range of objects using a
single database statement execution which often translates to a
significantly better performance.
 
* Ability to join and load one or more complete objects instead of, or
in addition to, a subset of their data members with a single SELECT
statement execution (object loading views).
 
* Support for specifying object and table join types in views (LEFT,
RIGHT, FULL, INNER, or CROSS).
 
* Support for calling MySQL and SQL Server stored procedures.
 
* Support for defining persistent objects as instantiations of C++ class
templates.
 
A more detailed discussion of these features can be found in the following
blog post:
 
http://www.codesynthesis.com/~boris/blog/2015/02/11/odb-2-4-0-released/
 
For the complete list of new features in this version see the official
release announcement:
 
http://codesynthesis.com/pipermail/odb-announcements/2015/000041.html
 
ODB is written in portable C++ (both C++98/03 and C++11 are supported) and
you should be able to use it with any modern C++ compiler. In particular, we
have tested this release on GNU/Linux (x86/x86-64/ARM), Windows (x86/x86-64),
Mac OS X (x86/x86_64), and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-5.x,
MS Visual C++ 2005, 2008, 2010, 2012, and 2013, Sun Studio 12u2, and Clang 3.x.
 
The currently supported database systems are MySQL, SQLite, PostgreSQL,
Oracle, and SQL Server. ODB also provides optional profiles for Boost and
Qt, which allow you to seamlessly use value types, containers, and smart
pointers from these libraries in your persistent classes.
 
More information, documentation, source code, and pre-compiled binaries are
available from:
 
http://www.codesynthesis.com/products/odb/
 
Enjoy,
Boris
"Lőrinczy Zsigmond" <nospam@for.me>: Feb 11 07:05AM +0100

> You know what feature I would love? A preprocessor statement
> that keeps a block of text unparsed until a certain other file is
included.
> When that other file is included, the unparsed block of memory is
inserted
> std::ostream& operator<<(std::ostream& in, myclass& data)
> {return in>>data.name;}
>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)