Tuesday, January 19, 2016

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

JiiPee <no@notvalid.com>: Jan 18 11:29PM

On 18/01/2016 21:08, Cholo Lennon wrote:
> platform server programming. After that I've never touched MFC code
> again.
 
> Regards
 
Well its the main way to make windows programs in VS2015
legalize+jeeves@mail.xmission.com (Richard): Jan 19 12:01AM

[Please do not mail me a copy of your followup]
 
no@notvalid.com spake the secret code
 
>Well its the main way to make windows programs in VS2015
 
Wrong.
 
It is *a* way to make Windows programs in VS2015.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
seeplus <gizmomaker@bigpond.com>: Jan 18 04:01PM -0800

On Tuesday, January 19, 2016 at 7:19:22 AM UTC+11, Richard wrote:
> Microsoft pretty well. The Visual Studio team and their products are
> not considered a revenue producing product like Office, SQL Server or
> Windows 10.
 
Thanks for the insights.
That is indeed the way this MS business model seems to be organized.
 
I use MFC a lot and I am pleasantly surprised to see that in VS2015 UG1 they have done some work on some long standing niggling MFC problems.
 
Somebody at MS must still be working on it.
Christopher Pisz <nospam@notanaddress.com>: Jan 18 06:29PM -0600

On 1/18/2016 5:29 PM, JiiPee wrote:
>> again.
 
>> Regards
 
> Well its the main way to make windows programs in VS2015
 
Not even close.
 
I've been a programming Windows for 20 years without ever having to deal
with MFC and have been employed more than twice with the specific task
of completely removing it from existing code, in an effort to make the
software more maintainable. MFC is garbage IMO and I've thought it was
garbage since I made it through my third book on MFC, back when I was
learning to "program windows." It's got piss poor interfaces on classes
that are inherited from 20 other classes that have nothing to do with
the object you are after. I vomit every time I see the MFC icon.
 
I wish they'd differentiate somehow between C++ Windows Programmers and
C Programmers on Windows who use Hungarian notation and the 25 different
types that represent a string that MS made up along the way, the 5000
macros, and love to pass around void pointers and c-style cast them all
day long, on job postings.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Christopher Pisz <nospam@notanaddress.com>: Jan 18 06:34PM -0600

On 1/18/2016 1:06 PM, JiiPee wrote:
> But seems to me that GCC compiler is better... maybe need to google if
> its possible to nicely use VS with GCC compiler, hopefully its possible,
> then could do DOS type of programs with GCC and windows with MFC.
 
What does using Visual Studio have to do with being locked into using
MFC? Some editions of Visual Studio might have had some half-assed
visual editor tools included for silly dialogs and stuff, but you by no
means need to use MFC because you like Visual Studio. You can use any
GUI library you like.
 
and why does it seem to you that GCC is "better" and what metrics are
you using to come up with the adjective? I'm not sure how you even
compare the two when Visual Studio is an IDE and GCC is a compiler.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
legalize+jeeves@mail.xmission.com (Richard): Jan 19 06:06PM

[Please do not mail me a copy of your followup]
 
Christopher Pisz <nospam@notanaddress.com> spake the secret code
 
>[...] MFC is garbage IMO and I've thought it was
>garbage since I made it through my third book on MFC, [...]
 
Egads, am I actually defending MFC? No, but understanding why MFC is
the way it is takes a bit of historical perspective. Personally I
like WTL for a pure Windows-only GUI. For cross-platform, I prefer
wxWidgets although I've been paid to do lots of Qt development.
 
MFC is a product of it's time -- 1992[1] -- and it shows. This was a time
when it was thought that "good class design" mean that all relationships
were expressed through inheritance with everything deriving from some
base CObject. The book "Design Patterns" <http://amzn.to/1V5GTiJ>
wouldn't be published for 2 more years. It was a very different time
for C++ when the full power of templates and how they manifest themselves
in a design wasn't well understood. It was a time when the C++ language
was newer and the standard library wasn't even a stable target.
 
ATL/WTL are an example of more modern C++ design, leveraging templates
so that you can obtain the benefits of abstraction without imposing a
giant class framework overhead. The motivation behind ATL was to
create a library for C++ that allowed you to create COM objects that
were minimal in size and it achieves that goal. WTL has been open
sourced by Microsoft and continues to evolve, although I'm surprised
they're still on sourceforge and haven't moved to github yet.
<http://wtl.sourceforge.net/>
 
The book "ATL Internals" <http://amzn.to/1n806VS> does a really good
job of explaining how the power of C++ and templates was used to create
this library. It is a stark contrast to the design philosophy present
in MFC. (Note: I read the 1st edition; the 2nd edition covers ATL 8.)
 
[1] <https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Jan 19 06:11PM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
>> some catch here?? It sounds too good to be true.
 
>The catch is your apps will only run on Windows, and you'll have learnt
>to become a Windows programmer.
 
Nonsense.
 
You might as well say that using Eclipse CDT means your apps will only
run on linux and you'll have become a linux programmer.
 
Where your apps will run depends entirely on what kind of
code you write. If you care about portability, nothing in VS is
preventing you from embracing portability. But you know what? It's
your choice to embrace multi-platform or not.
 
If you think that platform myopia is unique to Windows programmers,
you've never attempted to take C++ software written in other environments
and bring it to Windows. Doing that enlightens you to the fact that
people who only use linux write just as much platform-specific (or
compiler-specific) code as anyone else.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Ian Collins <ian-news@hotmail.com>: Jan 20 09:49AM +1300

Richard wrote:
> and bring it to Windows. Doing that enlightens you to the fact that
> people who only use linux write just as much platform-specific (or
> compiler-specific) code as anyone else.
 
Which is why I develop my embedded Linux (and occasional Windows) C++
code on Solaris :)
 
--
Ian Collins
Vir Campestris <vir.campestris@invalid.invalid>: Jan 19 09:31PM

On 19/01/2016 18:11, Richard wrote:
> code you write. If you care about portability, nothing in VS is
> preventing you from embracing portability. But you know what? It's
> your choice to embrace multi-platform or not.
 
These days I do use Eclipse, and my apps are cross compiled to Android.
 
Mostly. I do miss the ease of use of Visual Studio, and it's a curse
that the Android build system really doesn't work well with Eclipse.
Though I suppose there aren't enough of us for anyone to care... And
yes, I do know I could fix it - given enough time.
 
> and bring it to Windows. Doing that enlightens you to the fact that
> people who only use linux write just as much platform-specific (or
> compiler-specific) code as anyone else.
 
I suspect that myopia is the reason why STL files can (or is it could)
only be opened with a narrow char name. Doesn't map at all well to
Windows, but it's fine for Linux/Unix...
 
Andy
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 19 10:40PM +0100

On 1/19/2016 10:31 PM, Vir Campestris wrote:
 
> I suspect that myopia is the reason why STL files can (or is it could)
> only be opened with a narrow char name. Doesn't map at all well to
> Windows, but it's fine for Linux/Unix...
 
When Boost Filesystem becomes part of the standard library in C++17
(assuming it does), that's solved. Essentially, this part requires
*Windows* compilers to implement additional wide character support. IMHO
it's a disgrace to have such OS-specific requirements in the standard,
but still positive: something is better than nothing, surely.
 
At the moment, to e.g. make a Unixland-oriented library like OpenCV, or
the C++ standard library, open an arbitrary existing file in Windows,
one can use short 8+3 names: by default every Windows file has one.
 
Unfortunately Windows' support for short names can in principle be
turned off by the user, but one can simply not support systems where
that support is turned off.
 
 
Cheers,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 19 08:34PM +0100

The following piece of code smells ungood to me, even though I wrote it
myself:
 
switch( buffer[n_chars-1] )
{
case Syschar( Ascii::lf ):
--n_chars; // LF.
if( n_chars > 0 ) { --n_chars; } // CR.
buffer[n_chars++] = Syschar( '\n' );
break;
case Syschar( Ascii::cr ):
--n_chars;
break;
default: {}
}
 
I probably need much more coffee in order to clean that up, but then I
wouldn't sleep tonight. So, asking.
 
Full context:
 
inline auto read( In_<Array_part_ref_<Syschar>> buffer )
-> Size
{
CPPX_ASSERT( n_items( buffer ) > 0 );
Size n_chars = [&]() -> Size
{
namespace raw_winapi = winapi::raw;
 
raw_winapi::Doubleword unsigned_n_chars = 0;
raw_winapi::ReadConsoleW(
raw_winapi::handle_of<raw_winapi::Stream_id::std_input>(),
cast::as_ptr_to<wchar_t>( p_first( buffer ) ),
n_items( buffer ),
&unsigned_n_chars
) || fail( "cppx::winapi::console::read_line:
ReadConsoleW failed" );
return unsigned_n_chars;
}();
 
if( n_chars == 0 )
{
return 0; // End of file. Should not happen with
console i/o.
}
 
switch( buffer[n_chars-1] )
{
case Syschar( Ascii::lf ):
--n_chars; // LF.
if( n_chars > 0 ) { --n_chars; } // CR.
buffer[n_chars++] = Syschar( '\n' );
break;
case Syschar( Ascii::cr ):
--n_chars;
break;
default: {}
}
 
return n_chars;
}
 
Cheers,
 
- Alf
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jan 19 09:52PM +0100

On 19.01.16 20.34, Alf P. Steinbach wrote:
> break;
> default: {}
> }
 
Will not work with old MAC format (CR only).
 
> I probably need much more coffee in order to clean that up, but then I
> wouldn't sleep tonight. So, asking.
 
So what is your question?
 
> return 0; // End of file. Should not happen with
> console i/o.
 
EOF might not be that uncommon with console i/o if i/o redirection takes
place.
 
 
Marcel
Yang Luo <youngluoyang@gmail.com>: Jan 19 04:09AM -0800

在 2016年1月18日星期一 UTC+8下午9:54:04，Alf P. Steinbach写道：
> There is a little bit of C++ relevance in the question, e.g. it mentions
> C++. But mostly and primarily this is about Windows, independent of
> programming language, i.e. OFF TOPIC in this group.
 
Thanks,Akf.
Yang Luo <youngluoyang@gmail.com>: Jan 19 04:13AM -0800

在 2016年1月18日星期一 UTC+8下午9:54:04，Alf P. Steinbach写道：
> There is a little bit of C++ relevance in the question, e.g. it mentions
> C++. But mostly and primarily this is about Windows, independent of
> programming language, i.e. OFF TOPIC in this group.
 
Thanks,Alf.
Nobody <nobody@nowhere.invalid>: Jan 19 03:58AM

On Wed, 13 Jan 2016 14:59:12 +0100, Alf P. Steinbach wrote:
 
> level `setlocale` does not accept UTF-8, that it will fail at any
> attempt to set an UTF-8 locale. So UTF-8 is not a practical proposition
> for narrow (`char`-based) strings in Windows.
 
UTF-8 is a perfectly practical proposition for internal storage or stream
I/O. Just don't try to pass it to "ANSI"-mode OS functions (which you
probably shouldn't be using anyhow; Windows 95/98/ME is extinct now).
 
Wide strings have the advantage that you can just pass a pointer to the
data to most OS functions without needing any data conversion.
 
Byte strings have the advantage that you can read/write them to files,
sockets, pipes, etc (as well as many third-party APIs) without needing any
data conversion.
Ian Collins <ian-news@hotmail.com>: Jan 19 02:08PM +1300

red floyd wrote:
 
> Wind River VxWorks 6 could actually debug code at the UML level.
> It was a pain in the ass, and you had to use their toolset, but
> it was doable.
 
Just, for several 10s of $K per seat...
 
--
Ian Collins
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)