comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* C++ hardware library for (small) 32-bit micro-controllers - 14 messages, 7
authors
http://groups.google.com/group/comp.lang.c++/t/3d9629ba2d70a94c?hl=en
* Native Aspect-oriented programming in C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
* How to represent a SPACE and a BLANK in HEX in C++? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/77c1ee750808197f?hl=en
* Want to debug this? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
* Strange C++ compiling error - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/554ffaa20d74ff66?hl=en
* What's wrong with a class with only private functions? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/8e5f965aefa90e67?hl=en
* My two string classes could be "templatized" into one, but for one problem...
- 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
* Somone's SO question: "Is there an existing library for dynamically-
determined dimensional array in c++?" - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0afed0992d4bc4c2?hl=en
==============================================================================
TOPIC: C++ hardware library for (small) 32-bit micro-controllers
http://groups.google.com/group/comp.lang.c++/t/3d9629ba2d70a94c?hl=en
==============================================================================
== 1 of 14 ==
Date: Sat, Dec 7 2013 10:35 pm
From: Clifford Heath
On 08/12/13 16:33, Vladimir Vassilevsky wrote:
> QT 5.x has ~100M runtime. And it is slow, too. This is price of GUI
> portability.
In the late 80's I designed OpenUI, a cross-platform UI toolkit with
interpreter for an embedded language, and asynchronous rich messaging IO
both internally and across the Internet. It ran the new international
trading system of NASDAQ for ten years, initially on 486/66 PCs with 8MB
ram, with Windows 3.11. Equivalent versions ran the exact same apps on
character terminals, X11/Motif, Macs, OS/2, Windows NT, etc, on large
enterprises around the world, including some of the first Internet (pre
web-browser) banking and share trading apps.
The entire engine fit in 1MB, even though it was written in C++.
Not looking so smart now, are you Vladimir?
A tool is only as good as the people who use it. Especially a sharp tool.
== 2 of 14 ==
Date: Sat, Dec 7 2013 11:09 pm
From: Vladimir Vassilevsky
On 12/8/2013 12:35 AM, Clifford Heath wrote:
> On 08/12/13 16:33, Vladimir Vassilevsky wrote:
>> QT 5.x has ~100M runtime. And it is slow, too. This is price of GUI
>> portability.
>
> In the late 80's I designed OpenUI, a cross-platform UI toolkit with
Good for you. So what?
[...boast snipped...]
>
> The entire engine fit in 1MB, even though it was written in C++.
> Not looking so smart now, are you Vladimir?
> A tool is only as good as the people who use it. Especially a sharp tool.
What are you arguing to?
What point are you trying to make?
VLV
== 3 of 14 ==
Date: Sun, Dec 8 2013 12:56 am
From: Wouter van Ooijen
>> I am working on a portable C++ hardware library
>
> 1. Portable hardware is myth.
I have a lot of hardware that I can carry if I want to :)
Seriously (I am not sure you are, but I'll be), a lot of
hardware-related code can be portable, except for the frustrating aspect
of accessing the I/O pins (and dealing with timing).
> 2. Universal solutions and modular designs don't work.
I don't think any comment is needed.
> 3. Trying to cover everything instead of doing particular task is waste
> of time and effort.
First part is true, second part is nonsense, otherwise no libraries
would exist or be used. Library design is the art of balancing between
doing everything and doing a specific task well.
>> So far I have found nice and efficient abstractions for I/O pins and I/O
>> ports
>
> Useless. Abstract not I/O operation but function that it does.
>
> #define RED_LED_ON SETBIT(PORTA, 7)
I've been there, check for instance http://www.voti.nl/rfm73/. It works
up to a point. It runs into problems
- when setting a pin involves more than a simple operation (BTW, PORTA
hints that you use a PIC, in which case this is plain wrong due to the
RMW problem!)
- when you need more than one instance of your library (like interfacing
to two identical radio modules)
- it uses macro's, which are evil (according to some they are THE evil)
> How about life without C++ ?
Been there, ran up against the limitations of an assembler, even wrote a
compiler. Happy with C++ now. A pity concepts did not make it (yet).
> QT 5.x has ~100M runtime. And it is slow, too. This is price of GUI
> portability.
That's not the kind of GUI I am targeting. I'm mainly into
microcontrollers, the thingies that count their memory in kilobytes, not
megabytes.
>> One very stupid but basic problem is naming:
>> a template and a class can't have te same name, so when the natural name
>> would for instance be 'subframe', who gets that name, the template, the
>> class, or neither?
>
> Accept whatever style and stick to it. It doesn't matter as long as you
> are consistently following your design rules.
The two styles I mention (static class templates and (traditional)
classes with virtual functions) are both needed to get a balance between
(code and data) size and run-time flexibility.
(to the rest of the word: sorry if I am feeding a troll)
Wouter
== 4 of 14 ==
Date: Sun, Dec 8 2013 12:56 am
From: Wouter van Ooijen
>> I am working on a portable C++ hardware library
>
> 1. Portable hardware is myth.
I have a lot of hardware that I can carry if I want to :)
Seriously (I am not sure you are, but I'll be), a lot of
hardware-related code can be portable, except for the frustrating aspect
of accessing the I/O pins (and dealing with timing).
> 2. Universal solutions and modular designs don't work.
I don't think any comment is needed.
> 3. Trying to cover everything instead of doing particular task is waste
> of time and effort.
First part is true, second part is nonsense, otherwise no libraries
would exist or be used. Library design is the art of balancing between
doing everything and doing a specific task well.
>> So far I have found nice and efficient abstractions for I/O pins and I/O
>> ports
>
> Useless. Abstract not I/O operation but function that it does.
>
> #define RED_LED_ON SETBIT(PORTA, 7)
I've been there, check for instance http://www.voti.nl/rfm73/. It works
up to a point. It runs into problems
- when setting a pin involves more than a simple operation (BTW, PORTA
hints that you use a PIC, in which case this is plain wrong due to the
RMW problem!)
- when you need more than one instance of your library (like interfacing
to two identical radio modules)
- it uses macro's, which are evil (according to some they are THE evil)
> How about life without C++ ?
Been there, ran up against the limitations of an assembler, even wrote a
compiler. Happy with C++ now. A pity concepts did not make it (yet).
> QT 5.x has ~100M runtime. And it is slow, too. This is price of GUI
> portability.
That's not the kind of GUI I am targeting. I'm mainly into
microcontrollers, the thingies that count their memory in kilobytes, not
megabytes.
>> One very stupid but basic problem is naming:
>> a template and a class can't have te same name, so when the natural name
>> would for instance be 'subframe', who gets that name, the template, the
>> class, or neither?
>
> Accept whatever style and stick to it. It doesn't matter as long as you
> are consistently following your design rules.
The two styles I mention (static class templates and (traditional)
classes with virtual functions) are both needed to get a balance between
(code and data) size and run-time flexibility.
(to the rest of the word: sorry if I am feeding a troll)
Wouter
== 5 of 14 ==
Date: Sun, Dec 8 2013 3:05 am
From: Jorgen Grahn
["Followup-To:" header set to comp.lang.c++.]
On Sun, 2013-12-08, Wouter van Ooijen wrote:
(attributions lost, not my fault)
>>> I am working on a portable C++ hardware library
>>
>> 1. Portable hardware is myth.
>
> I have a lot of hardware that I can carry if I want to :)
>
> Seriously (I am not sure you are, but I'll be), a lot of
> hardware-related code can be portable, except for the frustrating aspect
> of accessing the I/O pins (and dealing with timing).
>
>> 2. Universal solutions and modular designs don't work.
>
> I don't think any comment is needed.
>
>> 3. Trying to cover everything instead of doing particular task is waste
>> of time and effort.
>
> First part is true, second part is nonsense, otherwise no libraries
> would exist or be used. Library design is the art of balancing between
> doing everything and doing a specific task well.
Yes, but it's a difficult art, and too many people do it badly. I hope
that was what Vladimir(?) tried to say.
I used to do it -- badly -- but nowadays I try to fit my code to the
design I'm working on, in an elegant way if possible. When I've done
similar things in two or three different projects, I stop to see if it
makes sense to split it out into a library. At that point I have real
world experience.
How this applies to you I cannot tell. Perhaps you've seen enough
different hardware already so you can tell what's the common metaphor
for most of it.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 6 of 14 ==
Date: Sun, Dec 8 2013 4:13 am
From: Clifford Heath
On 08/12/13 18:09, Vladimir Vassilevsky wrote:
> On 12/8/2013 12:35 AM, Clifford Heath wrote:
>> On 08/12/13 16:33, Vladimir Vassilevsky wrote:
>>> QT 5.x has ~100M runtime. And it is slow, too. This is price of GUI
>>> portability.
> What are you arguing to?
> What point are you trying to make?
Problems reading your own words?
You wrote: "This is the price of GUI portability".
You were wrong. Your example showed the price of using Qt,
a price which, incidentally, is incredibly damaging and
may explain why Nokia is in decline - so I agree.
It is however not the fault of either C++ or of GUI portability, but of
bad design.
== 7 of 14 ==
Date: Sun, Dec 8 2013 4:57 am
From: John Devereux
Wouter van Ooijen <wouter@voti.nl> writes:
>>> I am working on a portable C++ hardware library
>>
>> 1. Portable hardware is myth.
>
> I have a lot of hardware that I can carry if I want to :)
>
> Seriously (I am not sure you are, but I'll be), a lot of
> hardware-related code can be portable, except for the frustrating
> aspect of accessing the I/O pins (and dealing with timing).
>
>> 2. Universal solutions and modular designs don't work.
>
> I don't think any comment is needed.
>
>> 3. Trying to cover everything instead of doing particular task is waste
>> of time and effort.
>
> First part is true, second part is nonsense, otherwise no libraries
> would exist or be used. Library design is the art of balancing between
> doing everything and doing a specific task well.
>
>>> So far I have found nice and efficient abstractions for I/O pins and I/O
>>> ports
>>
>> Useless. Abstract not I/O operation but function that it does.
>>
>> #define RED_LED_ON SETBIT(PORTA, 7)
>
> I've been there, check for instance http://www.voti.nl/rfm73/. It
> works up to a point. It runs into problems
>
> - when setting a pin involves more than a simple operation (BTW, PORTA
> hints that you use a PIC, in which case this is plain wrong due to the
> RMW problem!)
>
> - when you need more than one instance of your library (like
> interfacing to two identical radio modules)
>
> - it uses macro's, which are evil (according to some they are THE
> evil)
So far I have indeed done this using C macros. I can define them using
standardized names so I can end up doing
/* this header specific to each target architecture */
#include "pio.h"
/* now can use generic versions of commands */
#define RED_LED PIO(A,1)
#define SERIAL_DATA PIO(A,2)
pio_out(RED_LED, 1);
pio_dd(SERIAL_DATA, 0); /* bidirectional data pin */
...And so forth.
When it involves more than a simple operation, I find you end up having
to do things in an application-specific way anyway. So to take your
example of an SPI driven I/O expander, usually I would update this
periodically rather than every time the application writes a bit. Yes,
your mileage may vary but that is the point, you are likely to end up
having to rewrite it each time in reality.
[...]
> The two styles I mention (static class templates and (traditional)
> classes with virtual functions) are both needed to get a balance
> between (code and data) size and run-time flexibility.
I found it an interesting idea, and thanks for posting it.
But a bit daunting to comprehend unless one is very well versed in c++
template metaprogramming, which I am not. I am reading the latest "The
c++ programming language" (c++11 based). So I will look again after
that.
--
John Devereux
== 8 of 14 ==
Date: Sun, Dec 8 2013 8:56 am
From: Öö Tiib
On Wednesday, 4 December 2013 20:45:34 UTC+2, Wouter van Ooijen wrote:
> However, I am now working on graphics for small LCD screens. At the
> lowest level (configuring an LCD driver for the size of the LCD and the
> pins used) the static-class-template approach is fine.
Yes it is fine for lot of cases and not only for embedded systems.
> But at some level
> the higher abstractions using the screen (for instance a subscreen,
> button, etc.) must be more dynamic and created ad-hoc. So somewhere
> (probably at multiple levels in the abstraction tree) I must make a
> transition from static class templates to the classic objects in an
> inheritance tree with virtual functions. Does anyone have any experience
> with such a dual hierarchy?
The virtual functions are nothing magical. If there is a long switch-case
of if-else-if chain in code then that is typically indicating missing
dynamic polymorphism. The compilers implement it quite efficiently so
usually virtual functions outperform such chains. There are several
patterns how to mix the static polymorphism (templates/overloads) and
dynamic polymorphism (virtuals/callbacks).
> One very stupid but basic problem is naming:
> a template and a class can't have te same name, so when the natural name
> would for instance be 'subframe', who gets that name, the template, the
> class, or neither?
Hard to understand what is asked here. The name should fit with what the
thing does. So if it is base class that contains only virtual function
'move' then it is 'movable', not 'subframe'.
== 9 of 14 ==
Date: Sun, Dec 8 2013 10:17 am
From: Wouter van Ooijen
>> The two styles I mention (static class templates and (traditional)
>> classes with virtual functions) are both needed to get a balance
>> between (code and data) size and run-time flexibility.
>
> I found it an interesting idea, and thanks for posting it.
>
> But a bit daunting to comprehend unless one is very well versed in c++
> template metaprogramming, which I am not. I am reading the latest "The
> c++ programming language" (c++11 based). So I will look again after
> that.
There is very little metaprogramming involved in th basics. My interface
for an open-collector/drain input/output pin is (leaving out
initialization and type identifification) just
struct pin_out {
static void set( bool );
static bool get();
};
Again leaving out some details, the template for a PCF8574 (8-bit I2C
I/O expander) takes 2 such pins (SCL and SDA) and provides 8 such pins.
template< class scl, class sda >
struct pcf8574 {
typedef ... pin0;
...
typedef ... pin7;
};
So if I want to connect one PCF8574 to two pins of the micro-controller,
and and a second one to two pins of the first one, I declare
typedef pcf8574< target::pin_0_4, target::pin_0_5 > chip1;
typedef pcf8574< chip1::pin0, chip1::pin1 > chip2;
now I can use the pins on chip2 ( eg. chip::pin0::set(1) ) and each use
will be written to the pin via the cascaded I2C busses.
No metaprogramming, just straightforward templates.
Wouter
== 10 of 14 ==
Date: Sun, Dec 8 2013 10:21 am
From: Wouter van Ooijen
> There are several
> patterns how to mix the static polymorphism (templates/overloads) and
> dynamic polymorphism (virtuals/callbacks).
Can you name a few? It is difficult to google if one doesn't know the terms.
>> One very stupid but basic problem is naming:
>> a template and a class can't have te same name, so when the natural name
>> would for instance be 'subframe', who gets that name, the template, the
>> class, or neither?
>
> Hard to understand what is asked here. The name should fit with what the
> thing does. So if it is base class that contains only virtual function
> 'move' then it is 'movable', not 'subframe'.
That's understood, but when I have both a template and a normal class
that fulfill the same takes (but using complite time versus run time
mechanisms) how should each be named?
Wouter
== 11 of 14 ==
Date: Sun, Dec 8 2013 11:53 am
From: Stefan Reuther
Hi,
Wouter van Ooijen wrote:
> I am working on a portable C++ hardware library for real-time
> applications on small (but still 32-bit) micro-controllers. My typical
> (and current only) target is the Cortex M0 LPC1114FN28 (4k RAM, 32K
> Flash) using GCC. Efficiency is very important, in run-time, RAM use,
> and ROM use. The typical restrictions for small microcontrollers apply:
> no RTTI, no exceptions, and no heap (or at most just an allocate-only
> heap).
I've been using an implementation using classes with virtual functions
for that, in programs from bootloaders to application programs (well,
actually I did a little template magic to implement vtbls "by hand", so
I can control when and how things are constructed). But effectively, I
have classes
class InputPin { virtual int get() = 0; };
class OutputPin { virtual void set(int) = 0; };
and their descendants.
Your fully template-based approach looks neat and appropriate for things
with as little "meat" as an I/O pin, but for more complicated things
like "SPI transaction", "parallel NOR flash", "NAND flash" I'd like to
know where in the object files my code ends up.
Plus, an I/O pin may end up to be more than just read-bit-from-register:
for applications that occasionally read a pin, I've got an
implementation of the InputPin interface that performs a remote
procedure call into the driver, saving the application from having to
map physical memory.
> If this is all too abstract, I have a more concrete question, mainly for
> C++ architects. For I/O pins and ports I use class templates with (only)
> static functions. This matches well with reality (the hardware circuit
> is generally fixed), and is much more efficient than using inheritance
> and virtual functions.
"The hardware circuit is generally fixed" is one of the biggest lies of
embedded software development :-)
At least I didn't yet encounter a project where hardware assignments
didn't change over time. Pins get moved, get inverted, new flash chip,
etc. So it's good I'm able to adapt by changing a (runtime) initialisation.
I'm paying one virtual dispatch per access. So, I wouldn't want do to
bit-banged SPI or IIC with my drivers. Thank god I don't have to :-)
It's probably not appropriate for 8-bitters, but it's efficient enough
to be useful in production bootloaders with a few k code.
Stefan
== 12 of 14 ==
Date: Sun, Dec 8 2013 12:16 pm
From: Öö Tiib
On Sunday, 8 December 2013 20:21:02 UTC+2, Wouter van Ooijen wrote:
> > There are several
> > patterns how to mix the static polymorphism (templates/overloads) and
> > dynamic polymorphism (virtuals/callbacks).
>
> Can you name a few? It is difficult to google if one doesn't know the terms.
Terms feel often self-coined. More often I have seen used "manifest
contracts", "hybrid types" and "gradual types".
> >> One very stupid but basic problem is naming:
> >> a template and a class can't have te same name, so when the natural name
> >> would for instance be 'subframe', who gets that name, the template, the
> >> class, or neither?
> >
> > Hard to understand what is asked here. The name should fit with what the
> > thing does. So if it is base class that contains only virtual function
> > 'move' then it is 'movable', not 'subframe'.
>
> That's understood, but when I have both a template and a normal class
> that fulfill the same takes (but using complite time versus run time
> mechanisms) how should each be named?
I do not understand how these are needed both side by side in conditions
where any overhead is expensive (like embedded system). If the
compiler knows type of object then it does not generate virtual calls
but ordinary calls (despite function is declared 'virtual'). Perhaps
you should give example.
== 13 of 14 ==
Date: Sun, Dec 8 2013 1:36 pm
From: Wouter van Ooijen
> Your fully template-based approach looks neat and appropriate for things
> with as little "meat" as an I/O pin, but for more complicated things
> like "SPI transaction", "parallel NOR flash", "NAND flash" I'd like to
> know where in the object files my code ends up.
You mean that it is a problem that you can't see which parts use how
much ROM?
> Plus, an I/O pin may end up to be more than just read-bit-from-register:
> for applications that occasionally read a pin, I've got an
> implementation of the InputPin interface that performs a remote
> procedure call into the driver, saving the application from having to
> map physical memory.
I don't see why a templatetized implementation could not do that too?
> "The hardware circuit is generally fixed" is one of the biggest lies of
> embedded software development :-)
>
> At least I didn't yet encounter a project where hardware assignments
> didn't change over time. Pins get moved, get inverted, new flash chip,
> etc. So it's good I'm able to adapt by changing a (runtime) initialisation.
Would it be a problem to re-compile?
> I'm paying one virtual dispatch per access. So, I wouldn't want do to
> bit-banged SPI or IIC with my drivers. Thank god I don't have to :-)
> It's probably not appropriate for 8-bitters, but it's efficient enough
> to be useful in production bootloaders with a few k code.
I started on such a class/object/vtable approach 2 years ago, but found
a number of problems:
- it is slow for very simple operations
- it hinders optimization
- it requires an object, which takes RAM, of which there is preciously
little on small micro-controllers
- compilers seem to be bad at eliminating virtual functions that are
never used
About optimization and speed: suppose I have a LED on a certain pin:
typedef gpio_1_0 LED;
LED::set( 0 ); // LED off
OOPs, the LED is connected to Vcc, not to ground! So I change this to
typedef invert< gpio_1_0 > LED;
LED::set( 0 ); // LED off
With the template approach the second version generates exactly the same
amount of code, and is exactly as fast, as the first version.
Wouter
== 14 of 14 ==
Date: Sun, Dec 8 2013 2:08 pm
From: Vladimir Vassilevsky
Hey gasbag
Which functions are thread safe?
How about interrupt safe?
On 12/8/2013 3:36 PM, Wouter van Ooijen wrote:
>> Your fully template-based approach looks neat and appropriate for things
>> with as little "meat" as an I/O pin, but for more complicated things
>> like "SPI transaction", "parallel NOR flash", "NAND flash" I'd like to
>> know where in the object files my code ends up.
>
> You mean that it is a problem that you can't see which parts use how
> much ROM?
>
>> Plus, an I/O pin may end up to be more than just read-bit-from-register:
>> for applications that occasionally read a pin, I've got an
>> implementation of the InputPin interface that performs a remote
>> procedure call into the driver, saving the application from having to
>> map physical memory.
>
> I don't see why a templatetized implementation could not do that too?
>
>> "The hardware circuit is generally fixed" is one of the biggest lies of
>> embedded software development :-)
>>
>> At least I didn't yet encounter a project where hardware assignments
>> didn't change over time. Pins get moved, get inverted, new flash chip,
>> etc. So it's good I'm able to adapt by changing a (runtime)
>> initialisation.
>
> Would it be a problem to re-compile?
>
>> I'm paying one virtual dispatch per access. So, I wouldn't want do to
>> bit-banged SPI or IIC with my drivers. Thank god I don't have to :-)
>> It's probably not appropriate for 8-bitters, but it's efficient enough
>> to be useful in production bootloaders with a few k code.
>
> I started on such a class/object/vtable approach 2 years ago, but found
> a number of problems:
>
> - it is slow for very simple operations
> - it hinders optimization
> - it requires an object, which takes RAM, of which there is preciously
> little on small micro-controllers
> - compilers seem to be bad at eliminating virtual functions that are
> never used
>
> About optimization and speed: suppose I have a LED on a certain pin:
>
> typedef gpio_1_0 LED;
> LED::set( 0 ); // LED off
>
> OOPs, the LED is connected to Vcc, not to ground! So I change this to
>
> typedef invert< gpio_1_0 > LED;
> LED::set( 0 ); // LED off
>
> With the template approach the second version generates exactly the same
> amount of code, and is exactly as fast, as the first version.
>
> Wouter
>
>
==============================================================================
TOPIC: Native Aspect-oriented programming in C++
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 8 2013 1:21 am
From: Paavo Helde
C?me David <davidbrcz@gmail.com> wrote in news:l801dv$ce$1
@talisker.lacave.net:
> Hello everyone.
>
> I've been wondering why there have never been any proposal to a native
> support for Aspect-oriented programming in the C++ core.
The Wikipedia article for aspect-oriented programming lists a couple of
aspect-oriented extensions to C++, like AspectC++ and FeatureC++. These
both work as preprocessors, converting the input language into real C++.
It appears in general the aspect-oriented programming requires injection
of code all over the place in unrelated code, probably breaking either
the separate compilation model or the zero-overhead principle of C++, not
to speak about introducing hidden control flow.
A bit of googling turns up some negative sentiment (see e.g.
http://developers.slashdot.org/story/05/04/24/0343224/aspect-oriented-
programming-considered-harmful):
"Aspect-oriented programming (AOP) is intended to address common problems
that object-oriented programming (OOP) doesn't address well, plus some
problems that OOP itself created. However, AOP is a risky solution: It is
a very generic mechanism for solving some very specific concerns and has
been likened to a kind of "GOTO" statement for OOP. Like GOTO, it can
cause more harm than good."
> I think this tool would be a nice improvement and could be used for
> instance to :
> * ensure classes' invariant
> * logging purpose
> * etc ..
The current take on such features in C++ is covered by the "private
virtual functions" idiom. In essence, this involves declaring virtual
functions private; there is a dedicated non-virtual public member
function in the base class which is calling the virtual function. This
single public member function can do the logging, checking invariants
before and after, etc. Probably a bit more tedious to set up than in
aspect-oriented languages, but does not break the class encapsulation
rules and is already working in current C++.
> Does anyone has an explanation ?
I would guess this is because it would encourage writing more fragile
code, plus there is already a working idiom (private virtuals) present
which can achieve similar things.
Cheers
Paavo
==============================================================================
TOPIC: How to represent a SPACE and a BLANK in HEX in C++?
http://groups.google.com/group/comp.lang.c++/t/77c1ee750808197f?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 8 2013 7:01 am
From: nick_keighley_nospam@hotmail.com
On Thursday, 21 November 2013 17:39:35 UTC, James Moe wrote:
> On 11/20/2013 06:04 PM, ssmile03@gmail.com wrote:
>
> > How to represent a SPACE and a BLANK in HEX in C++?
> > I am using '0x20' for SPACE and '0x00' for BLANK in hex in C++. Am I
> > correct?
probably not. 0x20 is ASCII for space. C++ is obliged to use ASCII (though in these latter days its becoming increasingly unlikely to be anything except ASCII or unicode). C++ doesn't have a concept of <blank>. What is <blank>?
In Fortran (if memory serves me right) a <blank> was a <space>.
On paper tape (and cards?) it was an unpunched section, so I assume that would code as 0x00. I suppose some ancient file format uses <blank>
You need to work out or explain to us what a <blank> is and why you wish to use one. This might enable you to work out how to encode it. You may need to distinguish its internal representation from its external representation.
> What is the context of your question?
> As others have noted, space and blank are synonyms in C/C++
really? Is blank mentioned in the standard? <pause> nope it doesn't appear in the index to my copy of the C++ Standard. is this a C++11 thingy?
> for the
> space character, 0x20/32/040. 0x00/0/000 is the C string NUL terminator.
>
> Perhaps you are thinking of whitespace in general? isspace() returns
> true for space, htab, vtab, formfeed, carriage return and linefeed.
> isblank() is more restrictive by only considering space or htab.
> I could drone on about the marvels of space but without a sense of
> your application it would be silly.
== 2 of 2 ==
Date: Sun, Dec 8 2013 7:12 am
From: Jorgen Grahn
On Sun, 2013-12-08, nick_keighley_nospam@hotmail.com wrote:
> On Thursday, 21 November 2013 17:39:35 UTC, James Moe wrote:
>> On 11/20/2013 06:04 PM, ssmile03@gmail.com wrote:
>>
>> > How to represent a SPACE and a BLANK in HEX in C++?
>> > I am using '0x20' for SPACE and '0x00' for BLANK in hex in C++. Am I
>> > correct?
> probably not. 0x20 is ASCII for space. C++ is obliged to use ASCII
> (though in these latter days its becoming increasingly unlikely to be
> anything except ASCII or unicode).
Clearly you meant to write "... is not obliged to ...".
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Want to debug this?
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 8 2013 7:15 am
From: Leigh Johnston
On 08/12/2013 02:28, Qu0ll wrote:
> "Leigh Johnston" wrote in message
> news:2MudnXGQtvSiXD7PnZ2dnUVZ7vqdnZ2d@giganews.com...
>
>> You are the moron; obviously I am calling him that based on PREVIOUS
>> posts he has made in this Usenet group.
>
> Before you call me a moron again (and note that I never actually called
> you one), would you like to consider that perhaps my reference to
> "moron" was based on PREVIOUS posts of yours too?
>
> Anyone for a bit of "gloy gum" or "Slartibartfast"? Perhaps "Sausages"
> are more to your liking? ROFL.
ROFL? That is the correct response to those posts which are meant to be
humorous unlike Brian's posts which are bigoted and homophobic.
Get a fucking clue mate.
/Leigh
== 2 of 2 ==
Date: Sun, Dec 8 2013 7:22 am
From: "Qu0ll"
"Leigh Johnston" wrote in message
news:8o-dnUjhnvyAEDnPnZ2dnUVZ8nGdnZ2d@giganews.com...
> ROFL? That is the correct response to those posts which are meant to be
> humorous unlike Brian's posts which are bigoted and homophobic.
> Get a fucking clue mate.
ROFL!
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]
==============================================================================
TOPIC: Strange C++ compiling error
http://groups.google.com/group/comp.lang.c++/t/554ffaa20d74ff66?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 8 2013 3:23 pm
From: Jun W
I encounter a "no matching function for call" error. My code is like this:
f1.h
class A
{
public:
A(){}
static void func(unsigned int a1, int a2, unsigned int & a3);
};
f1.cpp
#include "f1.h"
void A::func(unsigned int a1, int a2, unsigned int & a3)
{
//body of the function.
}
f2.h
class B
{
public:
B();
void init();
private:
unsigned int b_1;
int b_2;
unsigned int b_3;
};
f2.cpp
#include "f1.h"
#include "f2.h"
B::B()
{
A::func(b_1, b_2, b_3); //LINE1
}
B::init()
{
A::func(b_1, b_2, b_3); //LINE2
}
When compile the code, the error at both LINE1 and LINE2 are:
f2.cpp:error: no matching function for call to 'A::func(unsigned int&, int&, unsigned int&)' f1.h: note: candidates are: static void A::func(unsigned int a1, int a2, unsigned int & a3)
If I change the signature of A::func() in f1.h and f1.cpp to:
void func(unsigned int& a1, int& a2, unsigned int & a3)
The error is still:
f2.cpp:error: no matching function for call to 'A::func(unsigned int&, int&, unsigned int&)' f1.h: note: candidates are: static void A::func(unsigned int& a1, int& a2, unsigned int & a3)
How can the compiler decide that LINE1 and LINE2 need "pass by reference" for the three arguments?
== 2 of 3 ==
Date: Sun, Dec 8 2013 3:39 pm
From: Öö Tiib
On Monday, 9 December 2013 01:23:40 UTC+2, Jun W wrote:
> I encounter a "no matching function for call" error. My code is like this:
Seems mostly valid code.
> B::init()
> {
> A::func(b_1, b_2, b_3); //LINE2
> }
Here must be 'void B::init()'.
Either you did not post actual code or you are using some strange
C++ compiler (or both of course). Can you copy paste actual code
what you tried and tell what compiler it is?
== 3 of 3 ==
Date: Sun, Dec 8 2013 4:04 pm
From: Marcel Müller
On 09.12.13 00.23, Jun W wrote:
Either a compiler bug or it is not your code.
> B::init()
> {
> A::func(b_1, b_2, b_3); //LINE2
> }
At least this does not compile. The return type void is missing.
However, with this fix it compiles fine, even with very old compilers
like IBM VisualAge C++.
Marcel
==============================================================================
TOPIC: What's wrong with a class with only private functions?
http://groups.google.com/group/comp.lang.c++/t/8e5f965aefa90e67?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 8 2013 3:54 pm
From: Marcel Müller
I have a code snippet that crates a warning with gcc (older version):
template <class Element,
class Key,
int(*Comparer)(const Key& key, const Element& elem)>
class sorted_vector_own
{ // ...
};
class File
{ // ...
};
struct Parameters
{private:
static int CompareMeasurement(const char*const& key, const File& data);
public:
typedef sorted_vector_own<File,
const char*,
&Parameters::CompareMeasurement>
MeasurementSet;
MeasurementSet Measurements;
double FreqLow, FreqHigh;
// ...
};
test3.cpp:11: warning: all member functions in class `Parameters' are
private
OK, a compiler could warn about everything it likes. But what could be
the idea of this warning? What is wrong with a class with only private
functions?
Marcel
== 2 of 2 ==
Date: Sun, Dec 8 2013 6:15 pm
From: "Alf P. Steinbach"
On 09.12.2013 00:54, Marcel M�ller wrote:
>
> OK, a compiler could warn about everything it likes. But what could be
> the idea of this warning?
The compiler didn't notice that the address of the private function is
exposed, or else the logic of the warning doesn't include such
considerations at all.
> What is wrong with a class with only private functions?
If that's *all* that the class has, then they're useless baggage.
For such a class a compilation warning would be appropriate.
But in the presented code the class also has a public typedef that
exposes one of the private functions, which presumably is why you
reacted to the warning. ;-)
* * *
Here's a demo of how such a typedef allows a function to be called by
any code, illustrating that in spite of the "private:" the function is
publicly accessible with just a *little* more work than usual:
[code]
template< auto()->int > struct Whatever {};
class Not_quite_useless
{
private:
static auto foo() -> int { return 666; }
public:
typedef Whatever<&foo> Access;
};
//----------------------------------------------
#include <iostream>
using namespace std;
template< auto exposed_func() -> int >
void foo( Whatever<exposed_func> )
{ cout << exposed_func() << endl; }
auto main()
-> int
{ foo( Not_quite_useless::Access() ); }
[/code]
By the way, neither Visual C++ 12.0 nor MinGW g++ 4.7.2 warned about the
Not_quite_useless class above.
Cheers & hth.,
- Alf
==============================================================================
TOPIC: My two string classes could be "templatized" into one, but for one
problem...
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 8 2013 9:52 pm
From: DSF
Hello group!
Under Windows, I have two string classes: FStringA and FStringW, as
per Windows' naming convention. I have done a lot of work recently on
the Wide version and decided to update the ANSI version. As I sat
there with two windows synchronized, looking for updates from W to
apply to A, it occurred to me that these lengthy classes are identical
save for two differences, and would be ideal as a template. That way
only one code set to update!
The first difference is simple: FStringA uses char whilst FStringW
uses wchar_t. If that were the only difference, it would be a piece
of cake. But it's never that simple, is it?
The second difference is the plethora of C sting calls these classes
use. I've rewritten the parts of the string RTL that I use, both for
a speed increase and to handle wide strings. I preface a 'd' to the
front since 'str' is reserved for the RTL. This leaves me with many
'dstringsomethingA' and 'dstringsomethingW' calls.
But how do I get the compiler to determine which call to make when
building the template into code? I could put preprocessor if/else
around all the d...A/Ws. That is actually built-in to them (based on
the definition of UNICODE), but the implementation seems sloppy. I
would have to preface each creation with preprocessor code such as:
// This is off the top of my head and I'm not even sure it would work,
// but it's clumsy anyway.
// FStr being the template class
typedef FStr<char> FStringA;
typedef FStr<wchar_t> FStringW;
#ifdef UNICODE
#define UCFLAG
#undef UNICODE
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment