Saturday, October 11, 2014

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
JiiPee <no@notvalid.com>: Oct 11 05:02PM +0100

On 11/10/2014 16:46, Paavo Helde wrote:
> Then, to obtain deeper understanding how the things work under the hood,
> one should learn some C-specific stuff and assembler + CPU architecture. I
> think assembler would be more relevant than C.
 
Thats how I saw it as well... because that makes sure that at least they
will do good programming first. And use wrong ways to do things.
 
 
> OO and writing of custom classes and class hierarchies can be largely
> postponed to a later stage, it is a somewhat separate and orthogonal topic,
> and not very specific to C++ either (there are lots of OO languages).
 
good point
 
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 11 05:17PM +0100

> - better type system (new/delete, templated casts, bool, enum class, ... )
> - constexpr
> - templates
 
And (though it's maybe a smaller set) C has things that C++ does not:
 
- different rules for const
- compound literals
- designated initialisers
- different implementation of complex numbers
- different implementation of threads
- variable length and variably modified array types
- _Generic expressions
 
and no doubt others...
 
--
Ben.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 09:46AM -0700

JiiPee wrote:
> student is not using wrong C tecnniques when
> doing C++ later? C is in their mind, so they
> start easily coding like that , isnt it?
 
It is "C"++. There is no real requirement to code
using new features and abilities in C++. And I
would argue that maintaining C++ code is often
far more difficult and obtuse compared with
coding some, if not many, parts in std C. The
only true advantages I've seen in C++ are the
class, exceptions, and some std featutes, but all
of those can be simulated in C (in variois ways)
with a small amount of up front work.
 
I look at some of the C++ questions on this group,
and I think to myself ... "Whew! Seriously??"
 
There are other common alternatives for that
very reason ... Objective-C, C#, and my own
intended RDC. C++ is sometimes hideous, rarely
elegant, and requires far more complex compilers
and libraries to support its execution. In addition,
it is often slightly slower in execution, making it
largely undesirable in my experience.
 
I find C by itself to be very close to being elegant,
only lacking a few features to be very elegant. I
pray to add those features to my RDC. But, we'll
see what the Lord's plans are for my life.
 
Best regards,
Rick C. Hodgin
JiiPee <no@notvalid.com>: Oct 11 06:11PM +0100

On 11/10/2014 17:46, Rick C. Hodgin wrote:
> only lacking a few features to be very elegant. I
> pray to add those features to my RDC. But, we'll
> see what the Lord's plans are for my life.
 
are you a christian?
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 10:21AM -0700

On Saturday, October 11, 2014 1:12:03 PM UTC-4, JiiPee wrote:
> > I pray to add those features to my RDC. But, we'll
> > see what the Lord's plans are for my life.
 
> are you a christian?
 
I am.
 
I am a C.
I am a C-H.
I am a C-H-R-I-S-T-I-A-N.
And I have C-H-R-I-S-T in my H-E-A-R-T and I will
L-I-V-E
E-T-E-R-N-A-L-L-Y.
 
:-)
 
https://www.youtube.com/watch?v=yrNM-B_gg4A
 
Best regards,
Rick C. Hodgin
Emanuel Berg <embe8573@student.uu.se>: Oct 12 12:26AM +0200

> possible for them and trying to learn two related
> but different languages is going to increase their
> workload considerably.
 
Good point. In that case, I'd say C is much better
than C++. Because with C++ the newcomer will be all
confused with OO and classes and constructors and all.
 
As a beginner programmer you don't need that, you want
to assign values to variables and echo them on the
screen, and such. Not that C++ can't do that... of
course it can, looking very much like C.
 
So you can either do it C or do it in pretty "base
C++" (not bothering about advanced OO stuff until
later - or never...).
 
--
underground experts united
Emanuel Berg <embe8573@student.uu.se>: Oct 12 12:30AM +0200

> in textbooks, where the first task in successfully
> reading the text is to learn how to translate the
> author's pseudocode.
 
Yeah, why should anyone have to do that? Most
programmers are kind of good at reading C or
C-like-syntax, and not just C or C++ programmers.
(There are lots of places to pick that up, besides
those languages.) I think such C should be used as the
new pseudo code: it'll make it easier for everyone
involved.
 
--
underground experts united
JiiPee <no@notvalid.com>: Oct 11 11:33PM +0100

Can you give an C code example where this would be better with C than C++?
 
For example with C++ you assign a value to a string:
 
string str;
str = "Hello";
 
But with C its:
char str[10];
strcpy(str, "Hello");
 
here the C++ version looks simpler for a beginner, isnt it? Why would
you say its easier here for a beginner the C-way?
 
With C++ they can faster go to other things in programming and still
learning the language.
 
So I think with C++ its easier for them to learn programming and faster.
Plus they do not need to worry about deleting the memories etc which
must be done with C if using dynamic allocation.
 
On 11/10/2014 23:26, Emanuel Berg wrote:
Ian Collins <ian-news@hotmail.com>: Oct 12 11:35AM +1300

Emanuel Berg wrote:
 
> Good point. In that case, I'd say C is much better
> than C++. Because with C++ the newcomer will be all
> confused with OO and classes and constructors and all.
 
Have you ever read Accelerated C++ by Koenig and Moo? It teaches C++
without assuming any knowledge of C or OO. You don't need to learn OO
to learn C++.
 
--
Ian Collins
JiiPee <no@notvalid.com>: Oct 11 11:42PM +0100

On 11/10/2014 23:35, Ian Collins wrote:
 
> Have you ever read Accelerated C++ by Koenig and Moo? It teaches C++
> without assuming any knowledge of C or OO. You don't need to learn OO
> to learn C++.
 
you mean also that using std::string is not doing OO?
Ian Collins <ian-news@hotmail.com>: Oct 12 11:43AM +1300

JiiPee wrote:
>> without assuming any knowledge of C or OO. You don't need to learn OO
>> to learn C++.
 
> you mean also that using std::string is not doing OO?
 
Yes.
 
--
Ian Collins
JiiPee <no@notvalid.com>: Oct 11 11:48PM +0100

On 11/10/2014 23:43, Ian Collins wrote:
>>> to learn C++.
 
>> you mean also that using std::string is not doing OO?
 
> Yes.
 
ok ye you can use string without much talking about OO. But there will
be a bit of OO things still there, like:
 
str.size();
 
so they have to understand that str is an object and it can call its
member functions, but yes its not too much OO there.
Urs Thuermann <urs@isnogud.escape.de>: Oct 11 11:46PM +0200

I want to clone an object through a pointer to its abstract base
class. Say I have the following classes
 
class B {
virtual void foo() = 0; // abstract base class
};
class D1 : public B {
virtual void foo();
};
class D2 : public B {
virtual void foo();
};
 
Then I can clone objects when I know the subclass of B
 
void f1(D1 *d1, D2 *d2) {
B *b1 = new D1(*d1);
B *b2 = new D2(*d2);
}
 
but not if I only have a pointer to the abstract base class
 
void f2(B *b) {
B *b1 = new B(*b); // error: cannot create a B
}
 
With GCC and -std=c++11 I can write
 
void f2(B *b) {
B *b1 = new auto(*b);
}
 
Is this the correct and preferred way in C++11?
 
In C++98 the only way I found is to add a pure virtual function
 
B *B::clone() const
 
and
 
B *D1::close() const { return new D1(*this); }
B *D2::close() const { return new D2(*this); }
 
and then call b->clone() instead of the new operator.
 
Is there a way to do this in C++98 without the need to add a new
function like clone() in each derived class?
 
urs
Richard Damon <Richard@Damon-Family.org>: Oct 11 12:58PM -0400

On 10/9/14, 2:16 PM, Rick C. Hodgin wrote:
> }
 
> Best regards,
> Rick C. Hodgin
 
sizeof(int)*8 should more properly be sizeof(int)*CHAR_BITS (in case it
isn't 8)
 
Even better would be to build the loop using INT_MAX (or UINT_MAX) to
allow for padding bits (but then, if there are padding bits, can you
really "reverse" the bits?)
 
You then have to worry about if N was odd, or negative, the routine will
invoke undefined behavior, you really should move N to an unsigned int
and build in an unsigned int,
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 10:03AM -0700

Richard Damon wrote:
> [snip]
 
I agree. Also, I didn't know CHAR_BITS existed. :-)
 
Best regards,
Rick C. Hodgin
Robert Hutchings <rm.hutchings@gmail.com>: Oct 11 12:03PM -0500

On 10/11/2014 11:58 AM, Richard Damon wrote:
 
> You then have to worry about if N was odd, or negative, the routine will
> invoke undefined behavior, you really should move N to an unsigned int
> and build in an unsigned int,
This was the first example I got from the internet:
 
* Function to reverse bits of num */
unsigned int reverseBits(unsigned int num)
{
unsigned int NO_OF_BITS = sizeof(num) * 8;
unsigned int reverse_num = 0, i, temp;
 
for (i = 0; i < NO_OF_BITS; i++)
{
temp = (num & (1 << i));
if(temp)
reverse_num |= (1 << ((NO_OF_BITS - 1) - i));
}
 
return reverse_num;
}
 
/* Driver function to test above function */
int main()
{
unsigned int x = 2;
printf("%u", reverseBits(x));
getchar();
}
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 11 08:44PM +0100

Robert Hutchings <rm.hutchings@gmail.com> writes:
<snip>
> if(temp)
> reverse_num |= (1 << ((NO_OF_BITS - 1) - i));
> }
 
If you are going to run a loop, it's better to use the type's limit as
Richard said. Personally, I'd run a loop with two bits moving in
opposite directions -- it makes things very clear:
 
for (unsigned bit = 1, mask = UINT_MAX/2 + 1; mask; mask >>= 1, bit <<= 1)
reverse_num |= n & mask ? bit : 0;
 
The code you found just looks way too fussy for my taste.
 
> printf("%u", reverseBits(x));
> getchar();
> }
 
And that's a pretty bad driver. For what it's worth, the one I used to
test my version is
 
int main(int argc, char **argv)
{
if (argc == 2) {
unsigned int n = strtoul(argv[1], 0, 0);
std::cout << Bits(n) << "\n" << Bits(reverse_bits(n)) << "\n";
}
return 0;
}
 
(the Bits class has a << operator to output a sequence of zeros and ones).
 
--
Ben.
Robert Hutchings <rm.hutchings@gmail.com>: Oct 11 03:50PM -0500

On 10/11/2014 2:44 PM, Ben Bacarisse wrote:
> return 0;
> }
 
> (the Bits class has a << operator to output a sequence of zeros and ones).
 
Very nice and clean! Thanks for the input Ben.
Richard Damon <Richard@Damon-Family.org>: Oct 11 05:45PM -0400

On 10/11/14, 1:03 PM, Rick C. Hodgin wrote:
 
> I agree. Also, I didn't know CHAR_BITS existed. :-)
 
> Best regards,
> Rick C. Hodgin
 
I suppose that sort of information gotten out of a test might be useful.
 
Of course the real feedback to get from giving this sort of question on
test is what questions does the applicant give back! I would much prefer
working with someone who asks the right questions back then blindly
plows ahead even though they have some questions.
Richard Damon <Richard@Damon-Family.org>: Oct 11 12:44PM -0400

On 10/8/14, 1:37 AM, Wouter van Ooijen wrote:
 
> BTW are you aware of any existing library for small chips that takes
> this approach?
 
> Wouter
 
One comment, in one sense the 1st example tries to stack the deck
against C++ by making the program be "more capable" than the C program,
in that the C program knows exactly what type of pin it is toggling,
while the C++ program can toggle ANY sort of I/O bit with a suitable
class defined.
 
IF the example had been closer:
 
int main(){
lpc1114_gpio pin( 1, 0 );
for(;;){
pin.set( 1 );
delay();
pin.set( 0 );
delay();
}
}
 
I.E., directly using the pin object in the code, and not through a
pointer to a generic base class, the code generated by the compiler can
much closer to the original since the compiler can bypass the virtual
call mechanism as it knows the real type of the object.
 
I find, at least in my own code, that by far most of the actual
references to I/O devices are done with known type objects or in
non-virtual functions that are part of the device definition, and thus
are no less efficient than the equivalent C code.
Wouter van Ooijen <wouter@voti.nl>: Oct 11 08:14PM +0200

Richard Damon schreef op 11-Oct-14 6:44 PM:
> pointer to a generic base class, the code generated by the compiler can
> much closer to the original since the compiler can bypass the virtual
> call mechanism as it knows the real type of the object.
 
Of course, but IMO that approach has little or no advantage over C in
abstraction power.
 
> references to I/O devices are done with known type objects or in
> non-virtual functions that are part of the device definition, and thus
> are no less efficient than the equivalent C code.
 
That is not my experience: a GPIO point can be pin of the
microcontroller, but it can also be a pin of an I/O extender chip, or
either of such pins, but inverted, etc.
 
What I wanted to prove in the article is that using C++ templates you
can have your cake and eat it: compile-time polymorphism, without the
run-time costs.
 
Wouter
Richard Damon <Richard@Damon-Family.org>: Oct 11 05:40PM -0400

On 10/11/14, 2:14 PM, Wouter van Ooijen wrote:
> can have your cake and eat it: compile-time polymorphism, without the
> run-time costs.
 
> Wouter
 
Where the advantage comes is now move the declaration of the pin to a
header file that defines your system hardware configuration (or even to
be a member of a class defining a higher level device). By using
preprocessor "magic" or just editing the file, you can define the pins
operation. When accessing the pin, the programmer there doesn't need to
know the type of I/O pin being used, he can just use the generic
interface and operate on it. (The key here is that the compiler DOES
know based on the declaration what type of port it is, so can generate
the efficient code).
 
I suppose the difference may be that I tend to write things that do
specific things to specific signals under specific signals, and don't
have many cases of writing a program to toggle an arbitrary signal under
some condition.
DSF <notavalid@address.here>: Oct 11 03:09PM -0400

Hello group!
 
So far, my string template class has been working well. It's based
on this code to select 8-bit or 16-bit strings:
 
template <class CH> class FString
{
...
}
 
typedef FString<char> FStringA;
typedef FString<wchar_t> FStringW;
 
#ifdef UNICODE
#define FString FStringW
#else
#define FString FStringA
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)