Tuesday, April 7, 2015

Digest for comp.lang.c++@googlegroups.com - 20 updates in 9 topics

Christian Gollwitzer <auriocus@gmx.de>: Apr 07 05:48PM +0200

Am 04.04.15 um 13:31 schrieb Öö Tiib:
> printf( "variable is %s\n", to_string(variable).c_str() );
 
> It is matter of taste definitely but not exactly total and
> miserable failure. May be I do not see some aspect of it clearly?
 
The printf version can be translated into foreign languages, while the
cout can't. Imagine a langugage that requires to say "%s is the
variable". Impossible with your first line by just changing the string.
 
Modern printf-like engines support syntax for positional arguments. So
 
%1$s has %2$d bytes
 
can be translated to
 
%2$d bytes are contained in %1$d.
 
How would you do this with iostreams? I'm all-in for a typesafe
printf-like engine using variadic templates.
 
Christian
Christopher Pisz <nospam@notanaddress.com>: Apr 07 12:03PM -0500

On 4/7/2015 10:48 AM, Christian Gollwitzer wrote:
 
> How would you do this with iostreams? I'm all-in for a typesafe
> printf-like engine using variadic templates.
 
> Christian
 
 
http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
scott@slp53.sl.home (Scott Lurndal): Apr 07 05:22PM

>> printf-like engine using variadic templates.
 
>> Christian
 
>http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
 
Doesn't matter how you pretty it up, it's still a pig :-)
Christopher Pisz <nospam@notanaddress.com>: Apr 07 01:38PM -0500

On 4/7/2015 12:22 PM, Scott Lurndal wrote:
 
>> http://www.amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/0321585585
 
> Doesn't matter how you pretty it up, it's still a pig :-)
 
I think the same of sprintf and its ilk, but we've been over all that
already.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
"Öö Tiib" <ootiib@hot.ee>: Apr 07 02:18PM -0700

On Tuesday, 7 April 2015 18:48:35 UTC+3, Christian Gollwitzer wrote:
 
> %2$d bytes are contained in %1$d.
 
> How would you do this with iostreams? I'm all-in for a typesafe
> printf-like engine using variadic templates.
 
Serializing to machine-readable text-based formats and
command line tools do typically ignore locale. So the
i18n means GUI. There are no standard GUI frameworks.
GUI frameworks typically contain some i18n facility.
GUIs do not use printf or iostreams.
"Öö Tiib" <ootiib@hot.ee>: Apr 07 06:22AM -0700

On Tuesday, 7 April 2015 00:53:30 UTC+3, David Brown wrote:
> > function by non-const reference or pointer.
 
> Just because compilers can't check /everything/, does not mean you
> should ignore the checks they /can/ do!
 
I don't suggest to ignore any opportunities. As next thing I
mentioned the tools (like valgrind and clang memory sanitizer)
that can do the runtime checks (when compiler can't detect
compile-time problem).
 
I was trying to say that leaving variables uninitialized is not
good *general* suggestion because the compile-time warnings are
situation-specific and tools that track such meta-information
run-time are platform-specific. Not *all* use those so not
*all* can gain from following of that advice. IOW it depends.
 
Other similar things are variables containing dangling pointers,
"moved from" variables and variables with contents from "dirty"
sources. We either use special tools that analyze usage of such
variables or use idioms that make it more likely that defects
manifest themselves without special tools instrumented.
 
> But I agree that sometimes using an "unavailable" or known-bad value is
> a good choice for initialisation when you don't have a real valid value.
 
I see the cons very well. My experiences show that the benefits
outweigh those on general case. Most of us like to fail ASAP
and use most terse syntax but C++ does not support us with that
choice.
 
Similarly assigning null to variable that contains dangling
pointer and does not leave scope anytime soon is widely accepted
idiom (and lot of coding standards require it) despite compilers
warn about potential (and tools detect actual) dangling pointer dereferencing / passing / returning / deleting. It is because the
code can use the null value in meaning of absence of value *and*
when it ignores it then null value manifests defects lot more
likely.
 
"Öö Tiib" <ootiib@hot.ee>: Apr 07 02:02PM -0700

On Tuesday, 7 April 2015 20:03:09 UTC+3, Stefan Ram wrote:
 
> in the sense that »const« above means: write accesses to i
> are allowed only in the for-parentheses (as in ++i above)
> (and similarly for other loops).
 
what is wrong with:
 
for( int i = 0; i < 10; ++i ) { /* code */ }
 
Plus static code analysis tool that can be configured to warn
about magic number '10' used and when 'i' is modified
instead of '/* code */' ?
These are very common warnings from static code analysis tools.
jomarbueyes@hotmail.com: Apr 07 09:45AM -0700

Hi,
 
I'm not sure this is the right forum for these questions. It it is not, could someone point me to the right forum?
 
I'm trying to install the GNU compiler collection version 4.9.2(gcc-4.9.2) on an Intel Mac running 10.7.5 (Lion). I would like to first install not in the usual /usr/bin/... hierarchy. I've been reading the configuration instructions in https://gcc.gnu.org/install/configure.html but there are a few optional directories that I don't fully understand. These are:
 
--with-local-prefix
--with-native-system-header
--with-gnu-as
--with-as
--with-gnu-ld
--with-ld
--with-libiconv-prefix
 
The description under --with-local-prefix reads:
 
"Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include."
 
The description for other directories in the list above is similar.
 
What is not clear to me is whether after installation the new compiler will search this directory or the compiler that is compiling the new gcc will look for files there to build the updated compilers.
 
As I mentioned above, if this is not the right forum for this question, could someone point me to a better suited forum?
 
Thank you in advance for any help,
 
Jomar
Victor Bazarov <v.bazarov@comcast.invalid>: Apr 07 12:54PM -0400

> I'm not sure this is the right forum for these questions. It it is not, could someone point me to the right forum?
> [..]
 
I don't really know where you'd ask about installations, but how about
'gnu.*' hierarchy? Or an online (web) forum for the target OS...
 
This is a *language* newsgroup.
 
V
--
I do not respond to top-posted replies, please don't ask
jomarbueyes@hotmail.com: Apr 07 10:52AM -0700

On Tuesday, April 7, 2015 at 12:54:11 PM UTC-4, Victor Bazarov wrote:
 
> V
> --
> I do not respond to top-posted replies, please don't ask
 
Hi Victor,
 
Thank you for your response. I'll try the GNU hierarchy as you suggested.
 
Thanks again,
 
Jomar
Melzzzzz <mel@zzzzz.com>: Apr 07 08:18PM +0200

On Tue, 7 Apr 2015 09:45:18 -0700 (PDT)
 
> What is not clear to me is whether after installation the new
> compiler will search this directory or the compiler that is compiling
> the new gcc will look for files there to build the updated compilers.
 
Former. Just use --prefix
jomarbueyes@hotmail.com: Apr 07 01:13PM -0700

On Tuesday, April 7, 2015 at 2:18:38 PM UTC-4, Melzzzzz wrote:
> > compiler will search this directory or the compiler that is compiling
> > the new gcc will look for files there to build the updated compilers.
 
> Former. Just use --prefix
 
Hi Melz,
 
Thank you very much for your response. It really helps.
 
Thanks again,
 
Jomar
Melzzzzz <mel@zzzzz.com>: Apr 07 07:35PM +0200

http://archive.computerhistory.org/resources/access/text/2015/03/102740024-05-01-acc.pdf
ram@zedat.fu-berlin.de (Stefan Ram): Apr 06 11:32PM

MikeCopeland <mrc2323@cox.net> writes: My concern is that with such
>a large key (as string type), would the map processing be significantly
>more efficient if the type for the key is declared as "unsigned
>long"...or does it not matter?
 
Hide the decision behind a concrete class. If you need to
know, measure with a profiler or a similar tool.
 
And separate ads in Usenet posts with a signature separator.
ram@zedat.fu-berlin.de (Stefan Ram): Apr 07 05:02PM

>char answer = 0; cin >> answer;
 
In C# 6.0, it seems to be possible to write,
 
int.TryParse(value, out int convertedValue)
 
now. This feature applied to the above C++ code would be,
 
cin >> out char answer;
 
. I'd also like to see (not from C# but from my mind):
 
for( int const i = 0; i < 10; ++i )...
 
in the sense that »const« above means: write accesses to i
are allowed only in the for-parentheses (as in ++i above)
(and similarly for other loops).
Juha Nieminen <nospam@thanks.invalid>: Apr 07 08:36AM

> // stuff
> }
> }
 
Wouldn't it be better to use "auto&" (or "const auto&" if you don't need
to modify the elements)? Else you'll be getting copies of the elements
(which might be expensive).
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 07 01:04PM

On Tue, 2015-04-07, Juha Nieminen wrote:
 
> Wouldn't it be better to use "auto&" (or "const auto&" if you don't need
> to modify the elements)? Else you'll be getting copies of the elements
> (which might be expensive).
 
I was going to complain about that, but he was only emulating what was
already there. Perhaps "// stuff" needs to mutate longLine or threadId?
Although it seems very unlikely.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen <nospam@thanks.invalid>: Apr 07 08:34AM

> std::string key = "abc";
> std::vector<string> * empty = new std::vector<string>;
> map[key]=*empty;
 
Why are you doing it like that (leaking memory to boot)? What exactly
is the problem with:
 
std::vector<std::string> empty;
map["abc"] = empty;
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
eao197@gmail.com: Apr 06 11:22PM -0700

SObjectizer is a small tool for simplification of development of concurrent and event-driven applications in C++. SObjectizer is strongly influenced by agent-oriented approach. It allows to build a concurrent application as a set of agent-objects which interact with each other only by means of asynchronous messages. SObjectizer takes responsibility of in-process message dispatching and providing working context for message processing.
 
In short the changes in 5.5.4 are:
 
* new helpers methods make_agent and make_agent_with_binder similar to make_shared/make_unique from C++11/14;
* private dispatchers which can be used only via direct references and are automatically destroyed when they are no more used;
* message limits as a simple but sometimes useful way for overload control;
* new type context_t and new constructor of agent_t for simplification of agents tuning in the case of inheritance;
* simple way for collecting and distributing run-time monitoring information from SObjectizer's internals;
* four new examples added to SObjectizer.
 
More details about the new release and references for downloading can be found on SourceForge.net:
 
https://sourceforge.net/p/sobjectizer/news/2015/04/sobjectizer-v554-released/
MikeCopeland <mrc2323@cox.net>: Apr 06 08:02PM -0700

In article <coggjrFhgfbU4@mid.individual.net>, ian-news@hotmail.com
says...
> > more efficient if the type for the key is declared as "unsigned
> > long"...or does it not matter? TIA
 
> Why would you represent a numeric key as a string?
 
No choice: that's the data I'm presented from the client; 8<{{
 
 
 
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
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)