Tuesday, November 29, 2022

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 28 07:29PM -0800

On 11/26/2022 2:23 PM, Mr Flibble wrote:
 
> It is my unhappy task to report that Microsoft Visual Studio 2022 (C++) is
> not fit for purpose (i.e. buggy as hell): I had to downgrade to VS2019
> just to get a working debugger. Also experienced ICEs with VS2022.
 
Ahhh, programming raw opengl is fun! ;^)
 
https://i.ibb.co/JkL25Nj/ct-work.png
 
Yes, this is in msvc:
 
https://i.ibb.co/WpZMSzW/image.png
 
;^)
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 28 10:23PM -0600

On 11/28/2022 9:29 PM, Chris M. Thomasson wrote:
 
> Yes, this is in msvc:
 
> https://i.ibb.co/WpZMSzW/image.png
 
> ;^)
 
So VS 2022 worked ok for you ?
 
Lynn
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 28 08:29PM -0800

On 11/28/2022 8:23 PM, Lynn McGuire wrote:
 
>> https://i.ibb.co/WpZMSzW/image.png
 
>> ;^)
 
> So VS 2022 worked ok for you ?
 
So far, so good... Some odd things occurred. For instance if I hit the
'/' character on the keyboard three times in a row fast, it would insert
some, what looked like meta data. Then I deleted it, and hit the '/' key
three times again. It did not insert anything. For some reason, it kind
of seems as if the IDE is using some AI to do some things, automatic
formatting, and shit like that. I went into settings and turned as much
off as I could.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 28 08:32PM -0800

On 11/28/2022 8:23 PM, Lynn McGuire wrote:
 
>> https://i.ibb.co/WpZMSzW/image.png
 
>> ;^)
 
> So VS 2022 worked ok for you ?
 
Fwiw, I have a long history with MSVC. 6.0 was pretty interesting, C++
not up to par. But I mainly used it for C. Back on Solaris under
ultrasparcs, I remember using NetBeans.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 28 08:40PM -0800

On 11/28/2022 8:23 PM, Lynn McGuire wrote:
 
>> https://i.ibb.co/WpZMSzW/image.png
 
>> ;^)
 
> So VS 2022 worked ok for you ?
 
Another thing that works pretty darn good in MSVC is vcpkg:
 
https://vcpkg.io/
 
I was able to just build everything I needed to get modern OpenGL up and
running.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 29 12:51PM -0600

On 11/28/2022 10:32 PM, Chris M. Thomasson wrote:
 
> Fwiw, I have a long history with MSVC. 6.0 was pretty interesting, C++
> not up to par. But I mainly used it for C. Back on Solaris under
> ultrasparcs, I remember using NetBeans.
 
My first C compiler was Turbo C from Borland in 1987. Version 1.01 was
great. The IDE was awesome since it used the IDE from Turbo Pascal.
 
I started using MSVC in 1992 ??? Don't remember what version it was but
it only produced Dos16 and Win16 EXEs and DLLs. Jumped to MSVC6 in 1993
??? to build 32 bit on Windows 93 XX 94 XX 95 (I was an alpha tester).
Jumped to MSVS 2005 in 2005 and MSVS 2015 in 2015 where we are now.
 
Lynn
Michael S <already5chosen@yahoo.com>: Nov 29 01:39PM -0800

On Tuesday, November 29, 2022 at 8:51:50 PM UTC+2, Lynn McGuire wrote:
> ??? to build 32 bit on Windows 93 XX 94 XX 95 (I was an alpha tester).
> Jumped to MSVS 2005 in 2005 and MSVS 2015 in 2015 where we are now.
 
> Lynn
 
MSVC6 released 1998-09-02
Windows 93 ? Windows 94 ? What are those things?
 
The first 32-bit Microsoft compiler was indeed released in 1993. It was called Visual C++ 1.0.
It generated code for Windows NT and Win32s. The later was a runtime environment running
on top of Windows 3.1 and 3.11.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 29 04:12PM -0600

On 11/29/2022 3:39 PM, Michael S wrote:
 
> The first 32-bit Microsoft compiler was indeed released in 1993. It was called Visual C++ 1.0.
> It generated code for Windows NT and Win32s. The later was a runtime environment running
> on top of Windows 3.1 and 3.11.
 
Windows 93 and 94 were the precursors for Windows 95 which was over two
years late. I got my first diskettes for Windows 93 in 1992.
 
I guess I got MSVC 1.0 in 1993. I remember Win32s very well.
 
Lynn
Juha Nieminen <nospam@thanks.invalid>: Nov 29 07:27AM

> absolutely must be. I don't understand why you'd take away the ability of
> something to access as much of your class data as possible, its not your
> house that needs to be protected against theft, its code providing a service.
 
Because the more you expose the private implementation of a class, the
harder it becomes to refactor without breaking existing code.
 
You might think: "Sure, perhaps refactoring the implementation of this
class might cause me to have to change the five million places where
the class is being used, but so what? The compiler will help me with
that. I'll just use five hours to fix every place and I'll be fine."
 
However, that approach doesn't work if you are making a library that's
used by several projects, even ones you aren't developing yourself.
If you break the API or usage of your class, ie. break backwards
compatibility, you may be causing a lot of work to other people who
are using your class.
 
Just as a very small and simple example of how a private implementation
is hidden from a public interface: Do you know how std::vector::size()
is implemented? There is, in fact, more than one way to implement it.
For example, the number of elements could be a member variable, or the
function could calculate it as the difference of two pointers.
Which one is it? You don't need nor have to know! The implementation
can choose whichever way it wants. And if it wants to change the
implementation it won't break any code.
 
(And if you think "that's a stupid example, nobody implements it
as the difference of two pointers", you'd be wrong.)
JiiPee <kerrttuPoistaTama11@gmail.com>: Nov 29 05:58PM +0200

On 29/11/2022 09:27, Juha Nieminen wrote:
> Which one is it? You don't need nor have to know! The implementation
> can choose whichever way it wants. And if it wants to change the
> implementation it won't break any code.
 
Ye good points. I have programmed long enough to know that this is real
benefit in a real code. I also think about this when I design a class:
easy to modify and change later. If it was:
 
int m_size;
 
it has many drawback: cant debug so easily, and cant easily change its
logic as you said.
Muttley@dastardlyhq.com: Nov 29 04:34PM

On Mon, 28 Nov 2022 18:10:24 +0000
>> its not your house that needs to be protected against theft, its code
>> providing a service.
 
>You need to learn what "encapsulation" means; only have a minimum of
 
I know what it means thanks.
 
>public methods: the more public methods a class has the less encapsulated
>it is. Any member variables that form part of the class's invarient MUST
>be private.
 
No they don't. Its simply personal choice. Code exists to perform functions and
the more access someone has to it the more power they have. You won't agree
with that, thats your choice.
Muttley@dastardlyhq.com: Nov 29 04:36PM

On Tue, 29 Nov 2022 07:27:09 -0000 (UTC)
>> house that needs to be protected against theft, its code providing a service.
 
>Because the more you expose the private implementation of a class, the
>harder it becomes to refactor without breaking existing code.
 
Thats why you provide a "use at your own risk" clause.
 
>If you break the API or usage of your class, ie. break backwards
>compatibility, you may be causing a lot of work to other people who
>are using your class.
 
You provide a public API but leave unofficial access with the proviso above.
Isn't it amazing how people managed before OO came along?
Mr Flibble <flibble@reddwarf.jmc.corp>: Nov 29 06:38PM

On Tue, 29 Nov 2022 16:34:27 +0000, Muttley wrote:
 
>>> providing a service.
 
>>You need to learn what "encapsulation" means; only have a minimum of
 
> I know what it means thanks.
 
It is obvious that you don't.
 
 
> No they don't. Its simply personal choice. Code exists to perform
> functions and the more access someone has to it the more power they
> have. You won't agree with that, thats your choice.
 
It is only a personal choice if you are a team of ONE. Do you even have a
day job? I would hate to work where you work if you do and they allow
such egregious behaviour.
 
/Flibble
Mr Flibble <flibble@reddwarf.jmc.corp>: Nov 29 06:40PM

On Tue, 29 Nov 2022 16:36:56 +0000, Muttley wrote:
 
 
>>Because the more you expose the private implementation of a class, the
>>harder it becomes to refactor without breaking existing code.
 
> Thats why you provide a "use at your own risk" clause.
 
It isn't just your own risk, it is *everyone* who either uses or depends
on the code's risk.
 
 
> You provide a public API but leave unofficial access with the proviso
> above.
> Isn't it amazing how people managed before OO came along?
 
"unofficial"? you must really crank out bags of shite on a daily basis.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 29 04:55PM +0100

On 27 Nov 2022 11:16, Mr Flibble wrote:
> return base_type::size_policy();
> }
> };
 
Example of a mixin I slightly revised today. All the functionality it
provides, for an UTF-8 sequence, depends only on an iterator/pointer to
the first byte of the sequence. So it is the same for a sequence
reference and a sequence value, which can just inherit in the functions:
 
template< class > struct Unit_iterator_of_t_;
template< class Type > using Unit_iterator_of_ = typename
Unit_iterator_of_t_<Type>::T;
 
template< class tp_Derived >
class Sequence_inspectors_mixin_
{
public:
using Unit_iterator = typename Unit_iterator_of_<tp_Derived>;
using Unit = typename
iterator_traits<Unit_iterator>::value_type;
 
private:
auto self() const
-> const tp_Derived&
{ return static_cast<const tp_Derived&>( *this ); }
 
auto it_start() const -> Unit_iterator { return
self().unit_iterator(); }
 
public:
auto first_unit() const -> Unit { return *it_start(); }
 
auto n_bytes() const -> int { return
lead_byte::sequence_length_of( first_unit() ); }
auto begin() const -> Unit_iterator { return it_start(); }
auto end() const -> Unit_iterator { return it_start()
+ n_bytes(); }
 
auto unit_pointer() const -> const Unit* { return
&*it_start(); }
auto char_pointer() const -> const char* { return
reinterpret_cast<const char*>( unit_pointer() ); }
 
auto codepoint() const -> char32_t { return
to_codepoint( it_start() ); }
auto sv() const -> string_view { return
string_view( char_pointer(), n_bytes() ); }
auto str() const -> string { return string(
char_pointer(), n_bytes() ); }
};
 
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 29 05:01PM +0100

On 29 Nov 2022 16:55, Alf P. Steinbach wrote:
>         using Unit_iterator     = typename Unit_iterator_of_<tp_Derived>;
 
Oh, sorry about the extraneous `typename` there, something from the
previous version.
 
- Alf
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)