Sunday, February 1, 2015

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

Ian Collins <ian-news@hotmail.com>: Jan 28 07:19PM +1300

Stefan Ram wrote:
 
> ::std::string to_hex_string( int const i )
> { ::std::stringstream s; s << ::std::hex << i; return s.str(); }
 
> int main(){ ::std::cout << to_hex_string( 16 )<< '\n'; }
 
Which (minus the superfluous scoping) was what I originally posted!
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Jan 29 07:31AM +1300

ghada glissa wrote:
 
> I'm sorry for any inconvenience but i'm unable to convert each byte and save it independently.
 
What was wrong with the solution I posted? It passed the test case you
posted.
 
--
Ian Collins
Christopher Pisz <nospam@notanaddress.com>: Jan 30 10:27AM -0600

On 1/30/2015 4:04 AM, Rosario193 wrote:
>> You win the ugly code of the week award.
 
>> What's wrong with #include <cstdio> ?
 
> i have one old C++ compiler that allow that
 
Upgrade your compiler to the year 2015. You are posting example code for
someone else to use.
 
 
>> Naming all variables with a single or double letter rather than a
>> meaningful name.
 
> not for the words one always use
 
Every single variable you have in your code is a single or double
letter. No one knows wtf aa=a; means without having to study your entire
listing. employeePay = twoWeekSalary is immediately obvious. You are
writing C++ (supposedly) code for humans to read. You are not working in
matlab.
 
 
>> trying to save keystrokes.
 
> i want sys call "int main(void)"
> and not call "int main()"
 
Why? Are you posting to a C++ newsgroup? Are you programming modern C++?
 
 
>> Statements sometimes on same line with brackets, sometimes not,
>> sometimes no brackets at all. At least be consistent with ugly style.
 
> they call it readability...
 
That's hilarious.
Greg Martin <greg.at.softsprocket@dot.com>: Jan 28 03:03PM


> Dear,
 
> I'm sorry for any inconvenience but i'm unable to convert each byte and save it independently.
 
> Regards.
 
I think the problem, here and in comp.lang.c is how you asked the
question. Is this what you're looking for?
 
 
#include <stdio.h>
#include <stdint.h>
#include <string.h>
 
int main () {
int i = 0x12f5e188;
unsigned char bytes[4];
 
memcpy (bytes, &i, 4);
 
for (int i = 0; i < 4; ++i) {
printf ("%x\n", bytes[i]);
}
 
return 0;
}
 
Note that the order the bytes are printed in will depend on the byte
order of the platform.
 
 
--
http://www.softsprocket.com
Greg Martin <greg.at.softsprocket@dot.com>: Jan 28 04:14PM

>> http://www.softsprocket.com
 
> Thank you for this solution but %x is used to display in hexadecimal or I want a function that returns the conversion of each byte independently.
 
> Regards.
 
Wellthen, you have an array of bytes that you can now convert into an array of
strings using one of suggestions that have been made, or is
this about you avoiding any effort on your part?
 
--
http://www.softsprocket.com
Rosario193 <Rosario@invalid.invalid>: Jan 30 07:21PM +0100

On Fri, 30 Jan 2015 11:05:13 +0100, Rosario193 wrote:
> if(j==0) break;
> }
> }
 
all these swap show that arabs representation for number, or little
endian
is the right way...
and we have only wrong
 
ram@zedat.fu-berlin.de (Stefan Ram): Jan 28 05:29PM

>Which (minus the superfluous scoping) was what I originally posted!
 
Sorry, I had not read all of the thread!
jak <please@nospam.tnx>: Jan 28 06:46PM +0100

Il 27/01/2015 18:04, Christopher Pisz ha scritto:
>> sending error. sorry.
 
> Oh , I thought some fellow named Alessio was the OP. You are using 2
> different accounts then I suppose.
 
 
 
More or less. The question is common and I am the most obstinate among
us. :)
JiiPee <no@notvalid.com>: Feb 01 06:34PM

I know that for virtual call we say that the derived class function is
overriding the base class version, if they have the same function. But
how about in a case where its a non-virtual situation:
 
class A
{
public:
void foo() {}
};
 
class B : public A
{
public:
void foo() {}
};
 
Then we use B object:
B b;
b.foo();
 
In this case are we saying (/can we say) that B::foo is overriding
A::foo? I think we can say A::foo is "hiding" or we are "redefining foo"
but is this also overriding? I am talking about definitions. I have
found many websites where they call this "overriding" (like tutorial web
sites), see:
 
http://www.programiz.com/cpp-programming/function-overriding
http://www.techopedia.com/definition/24010/overriding
http://www.sciencehq.com/computing-technology/overriding-member-function-in-c.html
http://en.wikipedia.org/wiki/Method_overriding
http://xytang.blogspot.co.uk/2007/05/comparisons-of-c-and-java-iii-method.html
 
 
Also on wikipedia it says: "*Method overriding*, in object oriented
programming <http://en.wikipedia.org/wiki/Object_oriented_programming>,
is a language feature that allows a subclass
<http://en.wikipedia.org/wiki/Subclass_%28computer_science%29> or child
class to provide a specific implementation of a method
<http://en.wikipedia.org/wiki/Method_%28computer_science%29> that is
already provided by one of its superclasses
<http://en.wikipedia.org/wiki/Superclass_%28computer_science%29> or
parent classes. ... The version of a method that is executed will be
determined by the object
<http://en.wikipedia.org/wiki/Object_%28computer_science%29> that is
used to invoke it. "
So it does not speak anything about polymorphism there... meaning
that my example is "overriding" according to wikipedias definition for
that word. Or am I missing something?
 
Where can I find the official definition for the word "overriding" in
programming? I tried to google but did not find really, only this wikipedia.
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 01:33PM -0600


> I know that for virtual call we say that the derived class function is
> overriding the base class version, if they have the same function. But
> how about in a case where its a non-virtual situation:
[...]
> Where can I find the official definition for the word "overriding" in
> programming? I tried to google but did not find really, only this
> wikipedia.
 
I doubt there is any "official definition" of any word in "programming".
But for C++ it is easier, we have an official C++ standard. It appears it
is using term "hiding" for non-virtual functions and reserves "overriding"
for virtual functions (see esp 10.2):
 
"A member name f in one subobject B hides a member name f in a sub-object A
if A is a base class sub-object of B."
 
The word "hides" is typed in italic, meaning this sentence defines the
meaning of "hiding".
 
Also note that virtual function overriding requires exact match of the
virtual function signatures, but hiding has broader sweep and hides all
base class members with the same name, regardless of signatures (though one
can unhide other signatures by a using-declaration).
 
hth
Paavo
scott@slp53.sl.home (Scott Lurndal): Jan 28 05:24PM

>hardware and embedded projects is more viable than ever before.
 
>But the use of C++ for such embedded projects will be quite different from =
>a "normal desktop program".
 
C or C++, it doesn't really matter. When programming for embedded
projects, whatever language you use, the constraints are the same.
 
Typically the constraints include a footprint size that precludes
using much of the standard template library. Often the constraints
also include avoiding C++ exceptions. There may or may not be
run-time facilities to support RTTI or C++ exceptions available
on the platform; there may not even be an operating system.
 
C++ works just fine given those constraints, assuming one avoids
the bits that aren't supported on the target platform; and the
application can still benefit from the data-hiding and encapsulation
provided by the C++ classes.
DSF <notavalid@address.here>: Jan 31 08:29PM -0500

On Sat, 31 Jan 2015 12:07:27 -0800, Geoff <geoff@invalid.invalid>
wrote:
 
 
>If undoing the changes makes no difference it means you didn't
>"recompile the entire project", which means you didn't clean
>everything before the recompilation and re-link.
 
I don't see where you infer that from what I said. Compiled with or
without the functions marked virtual makes no difference in the linker
errors. I'm sure I did an entire rebuild, but just to be sure, I just
did an entire rebuild both ways. Same errors either way. Besides,
since FAList is a template, it is contained entirely in a header file.
All files including it would have to be automatically recompiled
anyway.
 
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
DSF <notavalid@address.here>: Jan 31 08:39PM -0500

On Sun, 01 Feb 2015 09:50:58 +1300, Ian Collins <ian-news@hotmail.com>
wrote:
 
 
>Are the member functions of FAList defined inline, or in a separate
>file? If the latter, the file will probably have to be included in each
>compilation unit that uses FAList.
 
To answer your question, yes. I hate it when someone answers a "or"
question with yes or no. :o)
 
But in this case, yes is appropriate because some functions are
inline and some are not. Reading again, I have to say no to the
separate file section. It's a template so they are all in the same
header file. (They have to be.) They are just not all defined within
the template declaration. And the header file is included in any TU
that uses FAList.
 
Whatever I've done, I seem to have lost the "Illegal structure
operation" error from my previous post. I hope the fix to this does
not bring it back!
 
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
Geoff <geoff@invalid.invalid>: Jan 31 05:50PM -0800

On Sat, 31 Jan 2015 20:29:33 -0500, DSF <notavalid@address.here>
wrote:
 
>>> This project used to compile with no errors. The only change I made
>>>is removing "virtual" from two of the template functions
 
Did it or did it not "compile without errors" until you made the
change? I inferred you fixed a working project that compiles without
errors and when you compiled it you got link errors. Then, when you
undid the changes you made it continued to compile with errors. This
told me either the project didn't re-build cleanly or the undo's
weren't exactly correct. I went with bad build process but this was
probably a mistake to assume you did a proper undo.
DSF <notavalid@address.here>: Jan 31 09:00PM -0500

On Sat, 31 Jan 2015 22:14:58 +0000, Chris Vine
>non-static function of a template class, which can be virtual, and a
>function template, which cannot.
 
>Chris
 
I'm trying to digest this. To start with, I never said I had a
destructor function template, but rather a destructor template
function.
 
I also see where my research led me astray. I went back to the page
I read and they were not talking about template member functions, but
rather member template functions.
 
Just to be doubly sure.
 
-----------------------------------------
Virtual template member functions:
 
template <class T> : class Foo
{
public:
Foo();
virtual ~Foo();
...
virtual int GetFoo();
};
 
----------------------------------------
Virtual member function template:
 
template <class T> : class Foo
{
...
};
 
class Bar
{
...
};
 
class FooBar
{
public:
virtual Foo<Bar> bar; // Illegal
};
 
Is my understanding correct?
 
Thanks,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
seeplus <gizmomaker@bigpond.com>: Jan 31 08:49PM -0800

On Sunday, February 1, 2015 at 6:34:37 AM UTC+11, DSF wrote:
 
> I know I'm not giving much information here, but posting all of the
> code is impractical. I am hoping someone knows the general conditions
> that might make the following happen.
 
Are you sure that you haven't changed something and forgotten?
 
I have just spent 2 weeks debugging a nasty error in a large program
containing a very complicated math function which I wrote 4 (four) years ago,
and I thought that I had made no changes to this function since.
 
Luckily I had littered it with huge comments, one of which mentioned
Cppcheck, and it has taken this long to twig to just this little buried comment.
 
I had forgotten that I ran Cppcheck a long time ago on this file.
This large module was messy and it threw up lotsa problems during the checks,
which I flipped through and fixed up.
The thing still compiled OK after each cleanup, everything worked and
there was no reason to double check functions, mainly because there are 100s of them :(
It was only when I recently noticed small errors in testing that this showed up.
 
I dug out a backup of the module from before doing that Cppcheck
run, and found the problem I had created with those fixes.
DSF <notavalid@address.here>: Feb 01 01:54AM -0500

On Sat, 31 Jan 2015 17:50:17 -0800, Geoff <geoff@invalid.invalid>
wrote:
 
>told me either the project didn't re-build cleanly or the undo's
>weren't exactly correct. I went with bad build process but this was
>probably a mistake to assume you did a proper undo.
 
My bad. I think I was trying to say that the TU compiled with no
errors even though it contained a template with virtual functions. I
thought maybe they were causing the linker errors stated in this
thread. Taking them out made no change. I don't know why I stated
putting them back made no difference. That's obvious. (It WAS 2:34
in the morning.)
 
This all started with the error in my post "Debugging a template.
I'm stuck!" posted on the 25th of January. I made changes to the
project. I have no recollection of what I did or what files I
changed. But the results went from the main CPP file to stop the
compile because an object was being used with FAList without the
object having an overloaded == to the compile completing with the
linker errors listed in this thread.
 
Sorry for the misunderstanding,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
DSF <notavalid@address.here>: Feb 01 02:17AM -0500

On Sat, 31 Jan 2015 14:34:18 -0500, DSF <notavalid@address.here>
wrote:
 
Hello! (Update)
>of the template's functions than Add and Find. The map file shows the
>other template functions used by HashIndex but, as expected, does not
>show Add or Find.
 
I discovered that only Add and Find are not inlined. The other
functions called by hindex are inlined and require no generation of
template code. (I'm guessing here about inlining and no template
code. Based on the fact that a template function called GetNextItem
is translated to a call to XLateCI followed by GetItem. GetNextItem
does not show up in the error list because there is no call to it, but
this explains XLateCI and GetItem being on the error list.)
 
The upshot of this is I learned the above by compiling
CopyDirectory.CPP to assembler and studying the code. Templates are
created in the assembly source for *every instance* of FAList *except*
for FAList<HashIndex>. It may be coincidence that FAList was also the
star of the last mysterious error (see "Debugging a template. I'm
stuck!" posted on Jan 25th), but I suspect not.
 
Are there any conditions where a compiler cannot create a template
instance and produces no error? (CopyDirectory.CPP compiles
error/warning free.)
 
Thanks,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 01:38AM -0600

DSF <notavalid@address.here> wrote in
> project. I have no recollection of what I did or what files I
> changed. But the results went from the main CPP file to stop the
> compile [...]
 
Suggesting to install and use some version control software even if you
work alone. Cannot imagine living without one any more. On Windows,
subversion+TortoiseSVN is an easy to use combo for example.
 
Cheers
Paavo
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 02:06AM -0600

DSF <notavalid@address.here> wrote in
 
> Are there any conditions where a compiler cannot create a template
> instance and produces no error? (CopyDirectory.CPP compiles
> error/warning free.)
 
Some stuff is generated only in a TU which contains the definition of the
first non-inlined virtual member function. If this function is not defined
anywhere, mysterious linker errors may result.
 
hth
Paavo
Ian Collins <ian-news@hotmail.com>: Feb 01 09:51PM +1300

seeplus wrote:
> It was only when I recently noticed small errors in testing that this showed up.
 
> I dug out a backup of the module from before doing that Cppcheck
> run, and found the problem I had created with those fixes.
 
Version control is a wonderful thing....
 
--
Ian Collins
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 01 10:07AM

On Sat, 31 Jan 2015 21:00:02 -0500
> <chris@cvine--nospam--.freeserve.co.uk> wrote:
 
> >On Sat, 31 Jan 2015 14:34:18 -0500
> >DSF <notavalid@address.here> wrote:
[snip]
> I'm trying to digest this. To start with, I never said I had a
> destructor function template, but rather a destructor template
> function.
 
You said you thought there were circumstances in which you could not
have a virtual destructor, so you made it none-virtual. Since
destructors cannot be function templates, you were wrong.
 
> I read and they were not talking about template member functions, but
> rather member template functions.
 
> Just to be doubly sure.
 
[snip examples]
 
No, your examples are not right.
 
class template:
 
template <class T>
class X {
public:
virtual void do_it(T t) {} // fine
virtual ~X(){} // fine
};
 
function template:
 
class Y {
public:
template <class T>
void do_it(T t) {} // can't be virtual
};
 
Class templates cannot do type deduction, whereas function templates
can. Class templates can have virtual member functions, whereas
function templates cannot be virtual. Function templates can be
free-standing functions, or (non-virtual) member functions.
 
Chris
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Feb 01 03:41AM -0700

On Sat, 31 Jan 2015 14:34:18 -0500, DSF <notavalid@address.here>
wrote:
 
 
> I know I'm not giving much information here, but posting all of the
>code is impractical. I am hoping someone knows the general conditions
>that might make the following happen.
<snip>
 
Part of debugging things like this involves coming up with something
that reproduces the problem and which you *can* post. It sounds
tedious, but my guess is that in the long run, it might get you a
solution faster than speculating on which construct might have done
what.
 
A code sample -- even if it consists of more than one file -- gives
the people who know their stuff more to work with. It gives people
like me, with less expertise and experience, a chance to have a shot
at it.
 
And since you probably know your code better than anyone, the process
of cutting it down to something manageable is likely to help *you*
figure it out.
 
Louis
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 01 10:58AM

On Sat, 31 Jan 2015 20:39:56 -0500
DSF <notavalid@address.here> wrote:
[snip]
> header file. (They have to be.) They are just not all defined within
> the template declaration. And the header file is included in any TU
> that uses FAList.
 
If you have some member functions defined within the class template
definition, and some defined outside the class template definition,
check your syntax carefully. The syntax for member functions of class
templates which are defined outside the class definition can be quite
difficult to get right, and doubly so for a function template member of
a class template defined outside the class definition (if you have any
of them).
 
If you provide some member function definitions within the class
template definition and some outside it, they do not all have to be
within the same header file. However (with the limited exception of
the few compilers that implemented the export keyword), if they are not
all in the same header file, the definitions must still all be visible
to every translation unit which tries to instantiate the class or use
objects of the class. You cannot tuck away the member function
definitions which are provided outside the class template definition in
a ".cc" or ".cpp" file. Separate files which contain such things are
conventionally suffixed with ".tcc" or ".tpp" and to save the sanity of
the user are usually #include'd at the end of the header file. (To the
limited extent that you would usually so #include them in the header
file, you are right that they all "have to be" within the same header
file.)
 
Chris
Geoff <geoff@invalid.invalid>: Feb 01 10:33AM -0800

On Sun, 01 Feb 2015 01:38:17 -0600, Paavo Helde
 
>Suggesting to install and use some version control software even if you
>work alone. Cannot imagine living without one any more. On Windows,
>subversion+TortoiseSVN is an easy to use combo for example.
 
Coupled with frequent commits and sensible commit messages.
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)