Re: Bit Swizzling (c++ versus c)

[olcott]

On 9/8/2020 11:17 AM, Rick C. Hodgin wrote:
> On 9/8/20 6:21 AM, Bonita Montero wrote:
>>> I had a job interview one time with someone who asserted something like
>>> what you're saying right now. ...
>>
>> You never had such an interview.
>> You're just lying to define a better standpoint.
>
> It was for a company called Hurco in Indianapolis, IN back in 2006
> probably.  I made it passed every interviewer and the last guy was
> a C++ developer.  They manufactured heavy equipment for machining
> and computer-controlled welding.
>
> I've always been weak on C++ because it's so big and complex and I
> have preferred C code 10:1 over C++ code for general coding styles.

I focused on learning the subset of c++ the most directly enabled me to
write much better code.

I learned "c" on the basis of K&R because it was the only standard
available at the time and met Bjarne Stroustrup we he came to Omaha to
promote his new C++ language. He is a tee-shirt and blue jeans kind of guy.

If you only learn the c++ classes of the object oriented programming
model and two items of the standard template library you will know all
the c++ that you ever really need to make the same programs you make in
"c" much easier to understand and maintain.

I mostly only use the std::vector and the std::string aspect of the
standard template library. In my whole life the only dynamic memory
allocation that I ever used in any of my programs is std::vector.

The key advantage of the oriented programming model when used
effectively is that it totally eliminates data dependencies. Another
advantage based on the same idea is the cognitive leverage that this
extra degrees of modularity provides. All of the functionality and data
is in the same place.

[Rick C. Hodgin]

On 9/8/20 3:59 PM, olcott wrote:
> On 9/8/2020 11:17 AM, Rick C. Hodgin wrote:
>> I've always been weak on C++ because it's so big and complex and I
>> have preferred C code 10:1 over C++ code for general coding styles.
>
> I focused on learning the subset of c++ the most directly enabled me to
> write much better code.

Same with me. C++ is an absolutely brilliant extension of C in the
number and types of abilities it opens up to coding, but it goes way
too far with its number of library functions it tries to bring forward
IMO.

I think those features should be shared public open source libraries
that people can choose to add to their product, and not something the
language itself requires to be compliant.

--
Rick C. Hodgin

[olcott]

I only use its OOP classes and std::vector, std::string and sometimes
std::map. Inheritance might be good for class libraries but I have never
written one of those. I still (after decades of C++) mostly use
<stdio.h> for IO. The C++ formatted output is simply too tedious.

--
Copyright 2020 Pete Olcott

[Chris M. Thomasson]

Agreed.

[Juha Nieminen]

In comp.lang.c++ olcott <No...@nowhere.com> wrote:
> I still (after decades of C++) mostly use
> <stdio.h> for IO. The C++ formatted output is simply too tedious.

One advantage of the C++ style streams is that they are easily extensible
to support custom types while retaining the same usage syntax. I find this
very handy especially for things like debug output and such.

In other words, if I have something like:

class MyClass { ... };

I can then implement an std::ostream operator<< overload that allows me to
write things like:

MyClass obj = whatever;
std::cout << "a=" << a << ", b=" << b << ", obj=" << obj << "\n";

Sometimes I prefer implementing a separate debug printing function as a
variadic template, which I can call like:

dPrint("a=", a, ", b=", b, ", obj=", obj, "\n");

but even then the extensibility of std::ostream becomes handy because it
simplifies the implementation of that dPrint() function (because its
implementation can simply pass the parameters to std::ostream::operator<<).

Doing either one of those two things using <cstdio> only, instead of using
<iostream>, would be a lot more difficult. That's because of the lack of
overloads (and type safety) in <cstdio>.

That being said, there are other situations where std::printf() is a lot
handier than std::cout. For example, compare:

std::printf("%08X", value);

to the equivalent:

// Need this because some flag changes are persistent:
std::ios_base::fmtflags f = std::cout.flags();
std::cout << std::hex << std::uppercase << std::setw(8)
<< std::setfill('0') << value;
std::cout.flags(f);

which is, admittedly, a bit ridiculous.

[Melzzzzz]

You can't have everything, that is why use printf when more convenient
:P


--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[David Brown]

It is also, IMO, unpleasant that the streams are stateful (with these
flags), and even more unpleasant that you don't at least have a push/pop
interface to those flags.

It would be a lot nicer, simple to implement, and safer and easier to
use, to have some functions (perhaps in their own namespace) for
formatting outputs. So "std::formating::hex(x)" would be a (template)
function that took an integer type and returned a dedicated type that
has an << operator for printing out its value in hex. (And there would
be a Hex version for capitals, functions for floating point data, etc.)

> You can't have everything, that is why use printf when more convenient
> :P
>

In C++, you /can/ have everything. You just have to wait for a new
standard. The disadvantage, of course, is that you get /everything/,
including old stuff that with hindsight was not a good idea in the first
place.

[olcott]

Exactly!