Tuesday, October 14, 2014

Digest for comp.lang.c++@googlegroups.com - 25 updates in 9 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.
Robert Hutchings <rm.hutchings@gmail.com>: Oct 14 09:30AM -0500

Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
vi/gcc/g++ on Linux/UNIX?
 
What about testing and debugging? Favorite tools?
Wouter van Ooijen <wouter@voti.nl>: Oct 14 04:51PM +0200

Robert Hutchings schreef op 14-Oct-14 4:30 PM:
> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?
 
> What about testing and debugging? Favorite tools?
 
GCC
makescript
any editor that can shell out to make and interpret a compiler error
debugging: operator<<
 
Wouter van Ooijen
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 14 08:00AM -0700

On Tuesday, October 14, 2014 10:31:11 AM UTC-4, Robert Hutchings wrote:
> Do you use an IDE like Code::Blocks or Eclipse? Or just Emacs or
> vi/gcc/g++ on Linux/UNIX?
 
> What about testing and debugging? Favorite tools?
 
Windows: Visual Studio 2003, Visual Studio 2008. You cannot beat
edit-and-continue. There is no other ability to write code which is
better suited to debugging. I also use the Visual Assist X plugin
for Visual Studio, which adds a lot of refactoring abilities which
make development so much nicer.
 
Linux: CodeLite IDE with GCC and GDB, though I find GDB to be hideous
and awful compared to Visual Studio's debugger. The IDE is close
enough, and GCC has vastly superior warnings and error catching. In
fact, in the Windows development I also use MinGW and GCC to help me
catch issues the Microsoft compilers do not. GCC does also give
several false positives, however.
 
Best regards,
Rick C. Hodgin
Luca Risolia <luca.risolia@linux-projects.org>: Oct 14 05:16PM +0200

Il 14/10/2014 17:00, Rick C. Hodgin ha scritto:
> On Tuesday, October 14, 2014 10:31:11 AM UTC-4, Robert Hutchings wrote:
> GCC does also give
> several false positives, however.
 
hm..false positives? for example?
"Charles T. Smith" <cts.private.yahoo@gmail.com>: Oct 14 12:20PM

Hi,
 
I have a class with an inner class as an attribute. The inner class's
constructor takes an argument, an address to its owner:
 
class o {
class i o(this);
}
 
I get these errors: error:
error: expected identifier before 'this'
error: expected ',' or '...' before 'this'
 
Is it not possible to have a class as an attibute and pass the
constructor parameters? After all, at instantiation time, at least
"this" and the outer class's parameters are all knowable.
 
What is the explicit prohibition here, does anyone know?
 
cts
Juha Nieminen <nospam@thanks.invalid>: Oct 14 07:30AM

> Herb Sutter's new "Unified Call Syntax"
> (https://isocpp.org/files/papers/N4165.pdf) looks convincing (the
> initial idea gave me a mental rash though).
 
I didn't understand how it's supposed to work with functions in
namespace.
 
He gives as example "file->fseek(9, SEEK_SET)", but fseek() is
in the std namespace. How exactly is it supposed to work? (What
if there are several functions named 'fseek' in several different
namespaces? Or are you supposed to do "file->std::fseek(...)"?
In the latter case, what's the advantage?)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
peter koch <peter.koch.larsen@gmail.com>: Oct 14 02:01AM -0700

Den mandag den 13. oktober 2014 23.56.35 UTC+2 skrev Mr Flibble:
> (https://isocpp.org/files/papers/N4165.pdf) looks convincing (the
> initial idea gave me a mental rash though).
 
> /Flibble
 
Also look at N4174. Have not had the time to study them yet.
 
/Peter
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 14 12:37PM +0100

> in the std namespace. How exactly is it supposed to work? (What
> if there are several functions named 'fseek' in several different
> namespaces? Or are you supposed to do "file->std::fseek(...)"?
 
Ruling out the case where file points to something with an fseek method
(which is tried first) I understood his suggestion to mean that the
compiler treats the call exactly as if it were written
 
fseek(file, 9, SEEK_SET);
 
and, if that fails and the extended version of the idea is being used,
the compiler tries
 
fseek(9, file, SEEK_SET);
 
and then
 
fseek(9, SEEK_SET, file);
 
I.e. the new syntax is just sugar for one or more function calls that
are tired in succession by applying the existing rules for name and
overloading resolution.
 
> In the latter case, what's the advantage?)
 
Pass.
 
--
Ben.
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.
"Öö Tiib" <ootiib@hot.ee>: Oct 13 09:15PM -0700

On Sunday, 12 October 2014 17:41:26 UTC+3, Emanuel Berg wrote:
> without learning C as well as C is a huge subset of
> C++. (At least formally so, in reality it is probably
> more correct to say that C++ is an extention of C.)
 
C++ and C are two different languages that have common
subset. It is possible to write programs in that common
subset (and some people do it) but I do not know of good
book that teaches it.
 
Writing in the common subset you can not use some useful
features of C and lot of useful features of C++.
 
The common subset program has to contain some idioms
that are considered bad by experts of both languages.
For example you need to cast the 'void *' returned by
'malloc' in common subset. Most C experts suggest that
such cast is unneeded bloat in C. Most C++ experts
suggest to use 'new' or 'std::vector' instead of that
'malloc'.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 13 11:57PM -0700

Öö Tiib wrote:
> Most C experts suggest that such
> cast is unneeded bloat in C.
 
I have found that casting malloc() is a good idea, and
typically correlates to the malloc() input in some way,
which helps reduce bugs, and aids in long term maintenance.
 
// myptr may be declared off-screen
myptr = (Sxyz*)malloc(sizeof(Sxyz) * count);
 
If the cast wasn't there, and wasn't required, you'd only have
one cue as to the true purpose of the malloc(). If you meant
Sabc, but used Sxyz, it would silently introduce the bug. With
the cast, and the cast requirement, it is more difficult
to introduce accidental bugs on malloc(), and it helps in
identifying myptr's usage should its naming convention
not explicitly convey something.
 
Best regards,
Rick C. Hodgin
"Öö Tiib" <ootiib@hot.ee>: Oct 14 12:40AM -0700

On Tuesday, 14 October 2014 09:57:21 UTC+3, Rick C. Hodgin wrote:
> to introduce accidental bugs on malloc(), and it helps in
> identifying myptr's usage should its naming convention
> not explicitly convey something.
 
Yes, but that is not the idiom typically used in C. Typical
C malloc-usage idiom is that:
 
myptr = malloc(sizeof(*myptr) * n);
 
So "I want things that myptr points at, allocate me room for
n of those". There's no need to state any types here.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 14 12:57AM -0700

Öö Tiib wrote:
 
> at, allocate me room for n of
> those". There's no need to state
> any types here.
 
I've never seen or used this. It looks
dangerous to use to me, as there is
no reference to what myptr is. It must
then be sought after elsewhere to
understand the goal of that source
code line.
 
I do see it removing the potential bug
in the Sxyz/Sabc confusion, but it comes
at the high cost of removing the infor-
mation otherwise conveyed. For me, that
cost is too high.
 
Best regards,
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Oct 14 10:11PM +1300

嘱 Tiib wrote:
 
> myptr = malloc(sizeof(*myptr) * n);
 
> So "I want things that myptr points at, allocate me room for
> n of those". There's no need to state any types here.
 
Yes, that is the idiomatic form in C.
 
Some consider casting the return of malloc to be wrong because it could
cause bizarre run time errors if no prototype was available and an int
return was assumed by the compiler. While possible, I doubt this would
happen in practice, but the cast is still unnecessary clutter in C.
 
The reason for sizeof(*ptr) rather than sizeof(T) is clearer: T (and
therefore sizeof(T)) may change, but sizeof(*ptr) will always yield the
correct size.
 
--
Ian Collins
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 14 12:30PM +0100

>> Most C experts suggest that such
>> cast is unneeded bloat in C.
 
> I have found that casting malloc() is a good idea,
 
In C++ you have to, and in most of the posting you've made to
comp.lang.c you've been actually writing C++ not C. It not surprising
that you've got used to the "wrong" idiom since you don't write much (or
any?) C code. (I put "wrong" in quote because I know it's a much
debated point.)
 
<snip>
--
Ben.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 14 12:20AM -0500

Paul N <gw7rib@aol.com> wrote in
>> >SCROLLINFO
> si;" in Scroller.cpp, this also works OK. I don't understand why
> having it in one .cpp file works and having it in the other doesn't.
 
This seems like some confusion with 'static' and/or namespaces. Or it
might even be somehow related to the the global initialization fiasco
(though it does not look likely).
 
Most probably you have two definitions of 'si', one in global namespace
and one in your namespace, or one declared static and another not. Please
make sure you have only one definition of 'si' and that this definition
and all 'extern' declarations appear in the same namespace. Or maybe only
MSVC thinks you have two definitions - rebuild the project once (instead
of just building), just to make sure MSVC is not messing something up by
itself.
 
In another post you worried about IntelliSense, this is an independent
feature which does not really work 100% reliably. Do not turn too much
attention to it.
 
Cheers
Paavo
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 14 01:16AM -0700

Try passing parameters to a function and using
a local variable. Or include a pointer and
populate the thing being pointed to so it is
never a question.
 
Best regards,
Rick C. Hodgin
Wouter van Ooijen <wouter@voti.nl>: Oct 14 10:25AM +0200

Paul N schreef op 10-Oct-14 12:14 AM:
 
> It worked fine, setting a scroll bar.
 
> I wanted to put the scroll bar stuff in a separate file, so that I could use it with other programs. So I copied it to Scroller.cpp, and put the function (but not the definition of si) between lines "namespace Scroller {" and "}". (I admit I'm fairly new to namespaces.) Unfortunately the first call to this function does not work - si is loaded up OK but the scroll bar is not set, it stays at a range of 0 to 100. Later calls seem to work OK so if I do the first one again later everything works, but I can't understand why the first one goes wrong.
 
> If I put "SCROLLINFO si;" in the main .cpp file and "extern SCROLLINFO si;" in Scroller.cpp, this also works OK. I don't understand why having it in one .cpp file works and having it in the other doesn't.
 
Juk, ultra-long lines :(
 
Is that first call that does not work started by main() or by some
global constructor? If the last, you have been hit by the 'undefined
order of ininitialization of global objects' bug/problem/feature: the
order in which the global objects of different compilation units are
initialized is undefined. Within a single compilation unit it is
top-down, so your one-file version did not suffer from this problem.
 
Wouter
"Öö Tiib" <ootiib@hot.ee>: Oct 13 08:40PM -0700

On Sunday, 12 October 2014 20:26:54 UTC+3, arnuld wrote:
 
> const wchar_t* alpha = L"first line"
> "Second Line";
 
...
 
> alpha (5th variable) has its initialization spread across 2 lines. I
> need to give L only on first line and not on 2nd line. Is this assumption
> correct ?
 
It is correct if you have C++11 compiler.
 
In C++98 and C++03 it was undefined behavior [lex.string]:
"If a narrow string literal token is adjacent to a wide string
literal token, the behavior is undefined."
 
That changed in C++11:
"If one string literal has no encoding-prefix, it is treated as
a string literal of the same encoding-prefix as the other operand."
 
It is perhaps worth mentioning since some people sometimes post here that
they keep using very old compilers.
Mel <mel@zzzzz.com>: Oct 14 05:25AM +0200

On Sun, 12 Oct 2014 13:13:02 -0500, Robert Hutchings
> Some people strongly prefer Slackware....
 
I have Manjaro and Ubuntu installed at home but I compile and deploy
on Centos5/6
 
--
Press any key to continue or any other to quit
Mel <mel@zzzzz.com>: Oct 14 05:34AM +0200

> On Sunday, October 12, 2014 1:13:25 PM UTC-5, Robert Hutchings
wrote:
> by switching to BSD. I was reluctant to switch because
> I'd been using Linux for quite a while, but now wish I
> had switched earlier. Better late than never.
 
I have tried several BSD's and found them remarcably crude. For
server they are ok, but gui really lags behind... And hardware
support is nowhere near Linux.
 
--
Press any key to continue or any other to quit
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
Ike Naar <ike@iceland.freeshell.org>: Oct 10 07:33PM

> I would like to have the program sleep for a fixed
> amount of milliseconds each time a loop iterates.
 
Don't sleep till some time has elapsed.
Do sleep till an intersting event has happened.
Ian Collins <ian-news@hotmail.com>: Oct 11 04:10PM +1300

Emanuel Berg wrote:
> I would like to have the program sleep for a fixed
> amount of milliseconds each time a loop iterates.
 
Did you try the obvious (for Unix/Linux): usleep()?
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Oct 11 04:27PM +1300

Emanuel Berg wrote:
>>> amount of milliseconds each time a loop iterates.
 
>> Did you try the obvious (for Unix/Linux): usleep()?
 
> No. Why, is that better than sleep_for?
 
It's a lot less typing!
 
I must admit I've been using usleep() and nanosleep() for so long I
haven't looked at the C++ thread alternatives.
 
--
Ian Collins
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)