Sunday, March 15, 2015

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

BGB <cr88192@hotmail.com>: Mar 15 09:00AM -0500

On 3/12/2015 8:20 PM, JiiPee wrote:
> options, like embedded). Why use a language with less options? :) So its
> kind of interesting to see some saying C is better than C++....the way
> they think is so different.
 
because, not everyone needs so many options...
 
 
even with C, there are features that hardly anyone ever uses anymore:
trigraphs; old K&R style declarations; ...
 
features which are simply rarely used, such as bitfields...
 
features which were added later, but still rarely used:
digraphs (why were these even added?);
variable-length-arrays, _Complex and _Imaginary, ...
...
 
 
but, on the other side, there are some very frequently used features in
C which are painful in some other languages:
function pointers;
walking arrays using pointers, offsetting via arithmetic, ...;
...
 
where, for example, these few items make coding in many Java-like
languages considerably more painful than doing so in C.
 
 
now, for C++ vs C, main things one most often feels are lacking in C:
 
classes, but most use-cases can be done (slightly less prettily) with
structs (including rudimentary single-inheritance and doing things
similar to Java-style interfaces). (actually, if someone understands how
something like COM+ works, or what the C++ compilers do internally, they
are a good part of the way there...).
 
 
operator overloading, but the usual C solution is static-inlines with
reasonably terse names, ex:
static inline vec3d v3dAdd(vec3d a, vec3d b) { ... }
then, if C++ is used, the overloaded operators can be shorthands:
"c=a+b;" vs "c=v3dAdd(a, b);"
 
in other cases, a header can be used to optionally collapse longer
(fully qualified) names to shorter names via macros (yes, not quite
namespaces, but often "good enough").
 
templates, but these can often be loosely approximated via macros.
 
 
other cases, like overloaded functions, are usually handled with
type-suffixes on the function names.
likewise, references typically become explicit pointers, ...
 
 
so, in general, most of the same basic stuff can be done in either language.
 
 
though, C and C++ have differences in terms of idiom, so the way
something would be done in one language will often be "bad style" in the
other.
 
 
while a person could bemoan the lack of nice syntax for doing things, in
many of these cases it usually isn't really that huge of an issue.
 
in other cases, the typically more stable ABIs or further reaching
compiler support (on esoteric targets), or relative ease of plugging
custom code generators into compiled C vs compiled C++ machine code,
..., may outweigh the costs of doing things in straight C.
 
 
though, yes, C++ is also a lot nicer for doing general application
development type stuff.
 
 
and, on the extreme other end, when doing something one-off, there may
be cases where one debates whether to write some code in C... or forego
the use of an MCU entirely and just do all this crap with analog and/or
discrete logic, and whether to do things "properly" and with more
expensive parts (and/or needing parts one doesn't have on-hand), or just
being like "screw it" and generating hundreds of watts in waste heat and
needing to cool the thing via having it be submerged in water and
insulated via silicone caulk (say, because it is all analog electronics
operating the transistors in linear range, rather than digital
electronics doing stuff via PWM signals).
 
well, and optimally needing 10 or 12 AWG wire but being like "well, 14
will probably work"...
BGB <cr88192@hotmail.com>: Mar 15 09:51AM -0500

On 3/12/2015 2:27 PM, Bo Persson wrote:
>> do just fine.
 
> And I guess your car doesn't have an automatic gearbox, cruise control,
> electric window openers, or a GPS?
 
main car here:
is an automatic (but it is via a CVT rather than a gearbox), and has
electric windows, but no cruise control or GPS.
 
my brothers' cars have none of these (generally manual transmission and
hand-crank windows and similar).
 
one of them did come with an ECU, but this was removed when switching
over to a different engine with a high-performance carburetor.
JiiPee <no@notvalid.com>: Mar 15 05:49PM

On 15/03/2015 14:00, BGB wrote:
> static inline vec3d v3dAdd(vec3d a, vec3d b) { ... }
> then, if C++ is used, the overloaded operators can be shorthands:
> "c=a+b;" vs "c=v3dAdd(a, b);"
 
ok, here already I prefer much more "c=a+b; over c=v3dAdd(a, b);". It
would be difficult for me to do v3dAdd(a, b). maybe because am so used
to do a+b. but yes, this can be a personal preference
BGB <cr88192@hotmail.com>: Mar 15 01:13PM -0500

On 3/15/2015 12:49 PM, JiiPee wrote:
 
> ok, here already I prefer much more "c=a+b; over c=v3dAdd(a, b);". It
> would be difficult for me to do v3dAdd(a, b). maybe because am so used
> to do a+b. but yes, this can be a personal preference
 
yes, but if one is using C, they are basically stuck with v3dAdd or
similar, and the slight annoyances of things like this isn't usually
really enough to mandate using C++...
 
but, if they are using C++ already, then the use of an overloaded
operator can be available as a convenience...
BGB <cr88192@hotmail.com>: Mar 15 01:26PM -0500

On 3/15/2015 12:59 PM, Stefan Ram wrote:
>> even with C, there are features that hardly anyone ever uses anymore:
>> trigraphs; old K&R style declarations; ...
 
> BTW: »trigraphs are expected to be removed from C++17«
 
maybe they will be formally removed from C at some point as well...
 
 
in the case of my compiler, I saw little reason to support some of this
stuff, and as such, dropped support for it (old K&R style declarations
were also partly dropped because they were problematic for the parsing
strategy in use).
 
 
a counter example is things like "goto", which while still infrequently
used, and commonly hated on, is still useful in enough cases to justify
its inclusion.
 
 
then there is wackiness like "Duff's device", for which I am not
entirely certain whether or not it will work correctly in my compiler,
but it is obscure enough that I don't really care either way...
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 15 07:00PM

On Sat, 2015-03-14, Stefan Ram wrote:
> | |
> ostringstream ofstream
 
> ?
 
Nothing wrong, and I really like that I can output to a string
whenever I want. But I was just saying I /personally/, with the kind
of problems I solve, rarely (not never) find a reason to use
(= implement) inheritance.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
JiiPee <no@notvalid.com>: Mar 15 10:33PM

On 15/03/2015 18:26, BGB wrote:
 
> a counter example is things like "goto", which while still
> infrequently used, and commonly hated on, is still useful in enough
> cases to justify its inclusion.
 
yes definitely leave goto, its cool to have it there... good old basic
language feature. rarely needed but sometimes needed.
 
Christian Gollwitzer <auriocus@gmx.de>: Mar 15 01:49PM +0100

> to represent songs in an Artists catalog. Songs at te lowest level. Then Discs
> becasue each song is contained on a disc within a particular release by the
> artist. And there are multiple releases. And multiple artists.
 
It seems to me that you are having only data, no code. Unless it is a
music simulator, where the artist can be triggered to play a song or the
like, the data would be best stored in a relational database. Retrieving
all songs from a given artist etc. would be almost trivial SQL queries.
OO doesn't fit it well IMHO - OO is about subjects, SQL about objects.
 
Christian
Richard Damon <Richard@Damon-Family.org>: Mar 15 09:22AM -0400

As others have said, Derivation isn't really the right tool for these
relationships.
 
A Disc isn't a special type of song, but is a collection of them
(actually, shouldn't it be a collection of releases?)
 
A Disc would should have a container of releases (this would need to be
a many-many container, as a given release might exist on several discs),
and those releases need a corresponding "other side" of the container to
have the list of discs they are on.
 
A Song would have a container of the releases that have been made of it,
and that release would need to have a back pointer to the song (I am
assuming that a release is only of a particular song).
 
Similarly Artist and Release will have some form of container to relate
them together (the type depends on if a release is allowed multiple
artists).
 
As was pointed out, a database will tend to naturally represent this
sort of interrelationships. If you really want to build this in memory
(or a piece of it in memory), you are really just building an in-memory
database representation, with inter-object relationships.
 
Glen Stark <mail@glenstark.net>: Mar 15 08:37PM

On Sun, 15 Mar 2015 09:22:02 -0400, Richard Damon wrote:
 
>> What I fdon't like about the above design is that there's not any
>> OO'ness about it.
 
Others are doing a fine job of helping you with your design question, I'd
just like talk a little about good C++ design.
 
Object-orientation is *tool*, not a *goal*. Important goals in software
design are correctness and clarity (always first and foremost),
simplicity, and suitability of purpose. In my lexicon, suitability of
purpose is how well does the code do its current and future job. If
code needs to be able to rapidly adapt to rapidly changing requirements,
flexibility is important. If it's in a performance-critical application
and performance has been measured to be a problem, efficiency becomes
important. Otherwise, what counts is does it do what it's supposed to?
If code isn't correct, it won't be suitable for it's purpose, regardless
of how efficient or flexible it is. If your code is sufficiently
efficient for its purpose, you should put it efficiency aside as
unimportant -- at least until you you have mastered writing code which is
good from these other, more important criteria. Same rule applies to
flexibility. With time you'll get a feel for what flexibility you need
to plan in in advance. Usually, you ain't gonna need it (YAGNI).
 
In my experience working with novice developers, if you focus on
correctness, simplicity and clarity, you typically wind up with more
flexible and efficient code than if you focus on efficiency and
flexibility in advance. Sad but true.
 
C++ supports generic, procedural, OO and functional programming. The
best C++ design makes good use of all three of these paradigms. My
impression is your goal is to improve your OO skills with this project,
which is laudable. So it's okay if you focus on OO for the sake of this,
or some other project. If however you see an area where using one of the
other paradigms seems simpler, that's what you should use. Here simpler
means simpler code, simpler design -- which usually means less code, less
multiplication of entities (classes, functions, lines of code). If you
make the decision to do something that isn't very OO, but produces
simpler, easier to read and maintain code, you have just practiced a
*very* useful skill: the wisdom of when *not* to use a language feature.
 
If on the other hand, using a class hierarchy seems to flow naturally
from the problem you are investigating you should do so. If in doubt,
sketch out an alternative (even a less OO one), and compare the
complexity of the two solutions. Which one more simply solves the
problems you will concretely have to face. Don't speculate too much
about possible, 'maybe we'll need' scenarios. That way lie dragons. A
good question to ask yourself before implementing a hierarchy is: will I
use these sub-classes as base-class? If the answer is no, inheritance is
probably the wrong way to accomplish what you are trying to accomplish.
 
Good luck
 
Glen
Paavo Helde <myfirstname@osa.pri.ee>: Mar 15 04:19PM -0500

Glen Stark <mail@glenstark.net> wrote in
 
> Object-orientation is *tool*, not a *goal*. Important goals in
> software design are correctness and clarity (always first and
> foremost), simplicity, and suitability of purpose.
 
Strictly speaking, clarity and simplicity are also tools, not goals. It's
just that in most cases there are no known alternatives which would work
better. In some cases, like in the obfuscated C contest, there are.
 
In the future, AI may take over most of the tasks of programmers, and it
might be that its operation will bear no resemblance to what humans would
consider simple or clear.
 
Cheers
Paavo
MikeCopeland <mrc2323@cox.net>: Mar 14 11:42PM -0700

I have the following structures and declarations:
struct ResultStruct // Individual Event Finisher
{
int eventYear; // Year of result info
int eventOAll; // OverAll Finish position
int eventD_P; // Division Place
long eventTime; // Finish Time
string resEvent;
} resultWork;
typedef list<ResultStruct> ResultList;
ResultList resultList;
ResultList::iterator resIter;
 
struct FinisherStruct // Individual Finisher data
char finGender; // gender
int finCount; // # Finishes
long finLink; // unique Finisher (link) Id
string finName; // Finisher Name (Last, First)
string finDoB; // (derived) DoB via Age/Year
ResultList resList; // Finisher's events details
} finisherWork;
vector<FinisherStruct> finVect;
vector<FinisherStruct>::iterator flIter;
 
I populate the data like this:
 
finisherWork.finName = "Washington, George";
finisherWork.finDoB = 1940;
finisherWork.finLink = 17;
finisherWork.finCount = 0;
finisherWork.resList.clear(); // !!! Problem on reuse!!!
...
resultWork.eventTime = 3456;
resultWork.eventD_P = 3;
resultWork.eventOAll = 27;
resultWork.eventYear = 2010;
resultWork.resEvent = "Boston Marathon";
finisherWork.finCount++;
finisherWork.resList.push_back(resultWork);
 
I have discovered that the data in "resList" is incorrect when I
populate the object with different data...because reusing this data
value, even though I "clear()" it, is using the same memory address over
and over. I realize that I must use a pointer here and reallocate it,
but I don't know how to do it (e.g. "new something" and a redefinition
of "resList").
IOW, I must define the "ResultList resList" so that I can allocate
new memory data each time I populate the data object. Please advise.
TIA

 
 
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Paavo Helde <myfirstname@osa.pri.ee>: Mar 15 02:36AM -0500

MikeCopeland <mrc2323@cox.net> wrote in
 
> I have discovered that the data in "resList" is incorrect when I
> populate the object with different data...because reusing this data
> value, even though I "clear()" it, is using the same memory address
over
> of "resList").
> IOW, I must define the "ResultList resList" so that I can allocate
> new memory data each time I populate the data object. Please advise.
 
It looks like in your program you have only a single FinisherStruct
object (finisherWork) and thus there is only a single
finisherWork.resList object as well. When you modify this object, of
course it is modifying the same object in place. If you want multiple
objects, you need to create multiple objects.
 
I suggest first ditch the confusing C-style object definitions with
struct definitions, i.e., just have declarations:
 
struct ResultStruct // Individual Event Finisher
{
int eventYear; // Year of result info
int eventOAll; // OverAll Finish position
int eventD_P; // Division Place
long eventTime; // Finish Time
string resEvent;
};
typedef list<ResultStruct> ResultList;
struct FinisherStruct // Individual Finisher data
char finGender; // gender
int finCount; // # Finishes
long finLink; // unique Finisher (link) Id
string finName; // Finisher Name (Last, First)
string finDoB; // (derived) DoB via Age/Year
ResultList resList; // Finisher's events details
};
 
Now when you have got rid of the idea that there must be single "master"
object of each struct type, you can easily construct as many of them as
you need and wherever you need:
 
FinisherStruct finisherWork1, finisherWork2, finisherWork3;
 
or
 
size_t N = 100;
std::vector<FinisherStruct> finisherWorkList(N);
 
// as a demo, add some objects to the lists
ResultStruct a, b;
 
a.eventTime = 3456;
a.eventD_P = 3;
a.eventOAll = 27;
a.eventYear = 2010;
a.resEvent = "Boston Marathon";
 
b.eventTime = 3457;
b.eventD_P = 4;
b.eventOAll = 28;
b.eventYear = 2011;
b.resEvent = "Shanghai Marathon";
 
finisherWorkList[0].resList.push_back(a);
finisherWorkList[1].resList.push_back(b);
 
// etc...
 
Probably I misunderstood your actual problem, but getting rid of the C-
style struct variable definitions together with the struct declarations
will make your code better nevertheless.
 
hth
Paavo
MikeCopeland <mrc2323@cox.net>: Mar 15 05:39AM -0700

In article <XnsA45E61C9B889Emyfirstnameosapriee@216.196.109.131>,
myfirstname@osa.pri.ee says...
 
> or
 
> size_t N = 100;
> std::vector<FinisherStruct> finisherWorkList(N);
 
I don't know how large "N" is. That's why I chose a vector to hold
as many as I might encounter.
> a.eventOAll = 27;
> a.eventYear = 2010;
> a.resEvent = "Boston Marathon";
 
Yes, I see that. (And I apologize for the convoluted example code -
I should have developed a simpler problem statement....)
However, I can't do what you suggest, because I don't know how many
objects I need to manage. I have a large set of input data (in a file)
that has an unknown number of data objects I must present for a user's
selection. It could be 5, 12, or more than 50 sets of information, and
I must "hold" the data sets somewhere before processing.
I realize I should change the idea of the "master set", and that's
why I want to (somehow) allocate what I need with a "new" and pointers.
I just can't figure out how to write the C++ code that does that:
e.g. ResultList *resList;
How do I allocate and use such a thing (since I can't declare how many
objects I may actually need? 8<{{
 
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Paavo Helde <myfirstname@osa.pri.ee>: Mar 15 03:54PM -0500

MikeCopeland <mrc2323@cox.net> wrote in
> user's selection. It could be 5, 12, or more than 50 sets of
> information, and I must "hold" the data sets somewhere before
> processing.
 
All STL containers like std::vector and std::list can hold a changing
number of objects (they have push_back() member functions for example). My
suggestions do not have anything to do with fixed number of objects, I just
used a vector of some non-zero initial size to simplify the example. If you
are thinking my proposal was somehow related to use a container of a fixed
size, then I'm afraid you did not understand my post at all.
 
hth
Paavo
ram@zedat.fu-berlin.de (Stefan Ram): Mar 15 05:59PM

>even with C, there are features that hardly anyone ever uses anymore:
> trigraphs; old K&R style declarations; ...
 
BTW: »trigraphs are expected to be removed from C++17«
Pallav singh <singh.pallav@gmail.com>: Mar 14 11:10PM -0700

On Sunday, March 15, 2015 at 4:06:32 AM UTC+5:30, Victor Bazarov wrote:
 
> V
> --
> I do not respond to top-posted replies, please don't ask
 
Hi Victor,
 
i am using g++ as compiler and its X86 platform. its looks wizard as asm is not allowing textual substitution . please do let me know is i am missing something.
 
Thanks
Pallav singh
Bo Persson <bop@gmb.dk>: Mar 15 12:39PM +0100

On 2015-03-15 07:10, Pallav singh wrote:
>> I do not respond to top-posted replies, please don't ask
 
> Hi Victor,
 
> i am using g++ as compiler and its X86 platform. its looks wizard as asm is not allowing textual substitution . please do let me know is i am missing something.
 
I think you have got the cause.
 
The message "error: expected string-literal" seems to indicate that the
asm keyword doesn't support constexpr members of struct templates.
 
I very much doubt that this limitation is explicitly documented.
 
 
Bo Persson
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)