Saturday, March 14, 2015

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

Pallav singh <singh.pallav@gmail.com>: Mar 14 11:20AM -0700

Hi All,
 
 
We can have textual substitution inside ASM, but i am getting error only for first substitution. Please do let me know how to solve it.
 
template.cc:109:27: error: expected string-literal before 'right_string'
asm volatile ( right_string<T>::instr_str
^
 
////////////////////////////////////////////////////////////////////////////////////
template < >
struct right_string<signed char> {
static constexpr const char * instr_str = "mov %2, %%bh \n\tinc %%bh \n\tmov %%bh, %0 \n\tpushf \n\tpop %1\n\t;";
static constexpr const char * clobber_str = "%bh";
}
 
 
asm volatile ( right_string<T>::instr_str
: "=r"(result), "=r"(post_eflags)
: "r"(counter)
: right_string<T>::clobber_str);
 
 
////////////////////////////////////////////////////////////////////////////////////
 
Thanks
Pallav Singh
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 14 06:36PM -0400

On 3/14/2015 2:20 PM, Pallav singh wrote:
 
> template.cc:109:27: error: expected string-literal before 'right_string'
> asm volatile ( right_string<T>::instr_str
> ^
 
'asm' is implementation- and platform-specific. First, youi have never
mentioned what your platform or implementation was. Second, it is
better to post to the newsgroup that actually deals with your platform
or your compiler.
 
Also, see FAQ 5.8.
 
 
> ////////////////////////////////////////////////////////////////////////////////////
 
> Thanks
> Pallav Singh
 
V
--
I do not respond to top-posted replies, please don't ask
Richard Damon <Richard@Damon-Family.org>: Mar 13 11:03PM -0400

On 3/12/15 5:05 AM, Johannes Bauer wrote:
 
> seriously? What is going on? In any case, after implementing stubs for
> those, it links: 293 kB of binary! That is almost a FIVE FOLD increrase
> in code side fo doing pretty much nothing.
...
> Cheers,
> Johannes
 
This sounds like somebody provided a hosted library to the
implementation when they should have provided a freestanding library.
One issue with C++ is that a full feature version does add a lot of base
complexity to the library to handle the complexity of locales. An
implementation is allowed to decide to just support one locale, in which
case many things simplify (especially in strings and I/O), and a
freestanding version is allowed even more freedom as it doesn't even
need to provide the hooks to fake the locale support.
 
Your C environment is likely already using this fact to simplify the
library. It really sounds like your C++ library is expecting to be part
of a full featured hosted environment.
"Öö Tiib" <ootiib@hot.ee>: Mar 13 09:16PM -0700

On Friday, 13 March 2015 09:46:19 UTC+2, Christian Gollwitzer wrote:
> understans the inner workings of these beasts? Similarly, I've never
> hacked the Linux kernel or OpenOffice, when all I wanted was to install
> some hardware or to write a letter.
 
The things are made by quite normal people and not super-beings. Other
named (LLVM, g++ and OpenOffice) have issue trackers. Supplying patch
in issue tracker often speeds its fixing for wider public by my experience.
Linux kernel development is lead by charismatic asshole and I have no
experience of patching it. If you don't have time or skills to supply a
patch then just post the issue in tracker or comment existing issue, it
often helps. There's no much point to tell about any issues in clc++
thread about linus torwalds being sort of wrong or the like since most
developers do not read comp.lang.c++.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 14 06:26AM

On Thu, 2015-03-12, Ian Collins wrote:
>> On Wednesday, March 11, 2015 at 1:12:16 PM UTC-5, Johannes Bauer wrote:
 
>> Please don't swear here.
 
> He didn't....
 
Not that I care, but he did use the word "hell" as an interjection.
That counts as swearing around here (in that area, swedish and english
have the same architecture, so to speak, for curses).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 14 01:22PM

On Thu, 2015-03-12, Johannes Bauer wrote:
> On 11.03.2015 19:37, Wouter van Ooijen wrote:
...
 
>> to its C legacy, I am not gona take such insults from a C lover!
 
> That is definitely false, too. The parts that suck about C++ when people
> misuse it are exclusively "new" features.
 
You mean "new" as in "new compared to C 25 years ago".
 
IMO it's the C features, but also tbe early 1990s fads that suck.
People squeezing in virtual inheritance everywhere, creating a unique
kind of spaghetti. At the same time, without taking things like value
semantics, STL and RAII into account.
 
> Template metaprogramming (oh the horrors),
 
I might agree, if I'd encountered code which used it incorrectly.
Used wisely though (by someone smarter than me) it's a big asset.
 
> deeply nested weird inheritance hierarchies
 
Not really new but 20 years old and now fortunately unfashionable; see
above.
 
> and use of the
> STL which is unsuited for LOTS of tasks (space constrained, like
> embedded for example).
 
From where I'm looking, unsuited for surprisingly few tasks.
And every day, those tasks are getting fewer.
 
You're really complaining about the container part of the STL I guess,
because the algorithms carry no overhead. It would be stupid and
pointless to use C qsort() or memcpy() when you have std::sort and
std::copy.
 
> those features. As a "C with benefits", not as C++. You won't see any
> inheritance at all in my embedded C++ code (you will see interfaces,
> though).
 
I don't see a reason for a ban on inheritance -- it's just that I
rarely find a good reason to use it. Don't confuse these:
- My design doesn't need to use inheritance.
- Some people overuse inheritance in ways which make no sense at all.
- Inheritance sucks.
 
And, I see no conflict between enbedded programming and inheritance.
You may create twenty levels deep inheritance hierarchies, and not
waste a clock cycle or a word.
 
> My hope is that at least strongly typed enums ("class enums") will go
> into C at some point, that would be super cool. I think C11 already as
> static assertions, so that's definitely a plus.
 
It's a false hope. What you really want, I thinkm is to avoid
interaction with weird C++ programmers, but then you have to interact
with weird C programmers instead ... and they seem to typically refuse
to learn anything new, or use anything more recent than ANSI C from a
quarter of a century ago. Been there, tried that, failed to convince
more than two or three people that languages have improved since they
were in diapers in the 1980s.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
JiiPee <no@notvalid.com>: Mar 14 02:07PM

On 13/03/2015 19:15, Ian Collins wrote:
 
>> #include <iostream>
>> int main() { ::std::cout << "Hello, World" << "\n"; }
 
> Maybe the superfluous colons put them off :)
 
yes, C++ looks very strange for a beginner.... I remember first seeing
C++ thinking "what are those # s there??"
 
But I would also say, that after learning C++ syntax its not really
difficult, I think C++ syntax is more basic and easy than in others ,
like in Java or C#, i have difficulties to learn those!!
JiiPee <no@notvalid.com>: Mar 14 03:14PM

On 13/03/2015 14:04, Wouter van Ooijen wrote:
> someones subset, so to read and maintain code you will need to
> understand the whole language.
 
> Wouter
 
oh yes, if other people are involved.
But if i code myself. then...
JiiPee <no@notvalid.com>: Mar 14 03:19PM

On 13/03/2015 15:19, Johannes Bauer wrote:
> programmers, and were ACTUALLY just coding C. Because "real" C++
> programmers do everything right, of course.
 
> The problem is not that C++ is a bad language, it's a fantastic one.
 
yes
 
> it's much harder (but sure enough still happens on a daily basis).
 
> That said, both languages are nothing for beginners. I can only shake my
> head when people suggest C++ as a first language.
 
kind of agree.... but, I think it depends on how quickly and well the
student is able to learn. For example I was a quick learner when I
started C/C++. In couple of months I was doing pretty complex programs.
So I do not think that at that moment I would have had any problems
somebody teaching me C++, even new things. It depends on how motivated
and skillfull one is.
 
But for a class of students, yes I agree C++ would not be the best maybe
to start with.
BGB <cr88192@hotmail.com>: Mar 14 10:54AM -0500

On 3/12/2015 2:32 PM, Jorgen Grahn wrote:
>> I like indent-equals-structure, and in my experinece it is much esasier
>> to grab a library and do something simple with it in Python than in C++
 
> Yes.
 
not really much of a fan of Python personally.
it seems mostly like a good language for making code slow-as-hell and
prone to randomly crash.
 
 
> libraries are more practical and easier to use.
 
> Perhaps the C compatibility of C++ has a drawback here. You can catch
> both the C and C++ audience by making your library have a C interface.
 
though, C interfaces are also much more robust in the case of compiler
or version mismatches, as compilers can't seem to entirely agree on the
ABI, and the ABIs are prone to often change in subtle ways between
compiler versions (minor variations in class layout, name-mangling
behavior, ...).
 
but, a restricted subset of the C ABI is fairly stable across compilers
and compiler versions (*).
 
 
*: one of the main problem areas to be avoided is passing and returning
structures by value. some compilers will pass the whole structure on the
stack, others will pass a pointer and copy it later, and others will do
one or the other depending on the size of the structure.
 
the usual solution here is to only pass/return pointers to structures
(or, if the client code does not need to deal with their contents, treat
them as opaque pointers).
 
though, yes, in some cases, passing structures by value can be pretty
convenient, just not really safe at library boundaries.
 
 
likewise, with care, it is often possible to extend a struct without
breaking ABI compatibility with code built against a prior version of
the library, and likewise allow client code to be able to deal with
older library versions. but, things are not nearly so nice with classes.
 
 
> So I guess I'm arguing it's more a question of culture than of
> language support.
 
could be.
BGB <cr88192@hotmail.com>: Mar 14 02:23PM -0500

On 3/12/2015 11:32 AM, Wouter van Ooijen wrote:
 
> A modern jet fighter is (almost) impossible to fly by hand, and very
> costly and complex to develop and produce. Does that mean that we'd be
> better off fighting our enemies on bikes?
 
this is an issue I have with most current non-C-based languages:
too much of the whole "babies' first programming language" thing, and
not nearly enough "good for doing actual programming in".
 
even for loosely C based languages, Java went pretty far in that
direction, and is in some ways a very poor language to try to "actually
write code in" (as in, not just invoke some magic "do it for me" class
from the endless expanse of a standard class library).
 
 
C# is at least a little closer to being sane, but is rendered moot by
not really being a usable option for really anything I am doing.
 
 
so, I ended up with a few options in my case:
mostly C, with some C++ and ASM thrown in;
a custom scripting language (basically resembles ActionScript3), but is
sufficiently heavy-weight to thus far only really be usable on PC style
hardware (and in soft-real-time use cases, such as games or similar);
a VM for running a C variant.
 
 
the VM for running a C variant is more-or-less usable in some of my
ARM-based projects (on ARM11 class hardware), but has little hope of
being a viable option on a typical microcontroller (still too resource
heavy, but could be useable maybe on a higher-end Cortex-M or similar).
 
 
the language is basically C (most normal C code can be ported with
little or no modification), but with a few minor tweaks and some aspects
(in the parser/compiler/VM machinery) which are actually closer to C# in
some areas, and it is not exactly C standards conformant (and drops a
few rarely-used / legacy features).
 
a hope is to eventually support a C++ subset with it, but this is not
currently a high priority. another possibility (what I had originally
imagined it for early on) would be a more performance-oriented version
of the scripting language.
 
it uses green-threading and mostly runs in time that would otherwise be
spent waiting in the delay loop (however, the code does run a fair bit
slower than native).
 
there is some hackery in the interpreter to try to keep maximum running
times within about 1us of the target (and typically is run up to 2us
short of the target delay, with any remaining time spent it in the delay
loop).
 
technically, it is loosely similar to the Dalvik VM (statically typed
3-address bytecode), just more designed to run C. it is also able to
(reasonably easily) call into and share data with native code.
 
 
note that this was used mostly because traditional OS threading wasn't
really an option in this case (for example, the Linux scheduler couldn't
really get much more accurate than around 1ms or so), so pretty much
needed to run everything single threaded in a custom scheduler for this
stuff.
 
 
or such...
ram@zedat.fu-berlin.de (Stefan Ram): Mar 07 07:31PM

>So is it possible to return different type with different function
>parameter index? The point being that I want to use templates and I also
>want to have as simple call as possible, rather without no casts.
 
First make up your mind whether you want to bind
at compile time or a run time. Then, you can use
templates for compile-time polymorphism; but you
can't use them for run-time polymorphism.
ram@zedat.fu-berlin.de (Stefan Ram): Mar 14 05:53PM

>- Inheritance sucks.
 
Is anything wrong with:
 
ostream
^
.-------------------------'-------------------------.
| | |
ostringstream | ofstream
::std::cout
 
?
ram@zedat.fu-berlin.de (Stefan Ram): Mar 14 06:03PM

Supersedes: <inheritance-20150314185313@ram.dialup.fu-berlin.de>
[new quotation from Jorgen][modified diagram]
 
>I don't see a reason for a ban on inheritance -- it's just that I
>rarely find a good reason to use it.
 
Is anything wrong with:
 
ostream
^
|
.--------------'--------------.
| |
ostringstream ofstream

?
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 06 02:56PM -0500

On 3/6/2015 12:06 PM, Christopher Pisz wrote:
> definition intended?)" and cannot seem to use the string afterward
> without compiler errors that claim it isn't a compatible type. I don't
> follow. Using msvc 2012.
 
Change that line to read
 
std::string textToParse(std::istream_iterator<char>{file},
std::istream_iterator<char>{});
 
(note the curly braces), and don't use pre-C++11 compiler :-)
 
(actually I'm not sure it's going to work with VC++ 2012, I used 2013
and got this result:
 
Method 1 :498549
Method 2 :305819
Method 3 :110364
 
(with an 18K file, and those are the processor ticks, using the Windows
QueryPerformanceCounter)
 
How big is your file?
 
Another note: make sure the optimizer does not throw away the result of
the Method1. It's quite possible that since you're not returning it
anywhere, the optimizer might change the code to never create the object
in the first place. Think of returning the string from those functions
(as in 'std::string Method1(...')
 
Here is my (corrected) code:
//--------------------------------------------------------------------------------------------------
// Standard Includes
#include <iostream>
#include <fstream>
#include <sstream>
#include <string>
#include <vector>
#include <cstdio>
#include <Windows.h>
 
const unsigned int NUM_ITERATIONS = 100;
 
//--------------------------------------------------------------------------------------------------
std::string Method1()
{
std::ifstream file("test.txt");
if (!file)
{
// Error
throw 1;
}
 
std::string textToParse(std::istream_iterator < char > {file},
std::istream_iterator < char > {});
 
file.close();
 
return textToParse;
}
 
//--------------------------------------------------------------------------------------------------
std::string Method2()
{
std::ifstream file("test.txt");
if (!file)
{
// Error
throw 22;
}
 
std::string textToParse;
 
file >> std::noskipws;
std::copy(std::istream_iterator<char>(file),
std::istream_iterator<char>(),
std::inserter(textToParse, textToParse.begin()));
 
file.close();
 
return textToParse;
}
 
//--------------------------------------------------------------------------------------------------
std::string Method3()
{
std::ifstream file("test.txt");
if (!file)
{
// Error
throw 333;
}
 
std::stringstream textToParse;
textToParse << file.rdbuf();
 
file.close();
 
return textToParse.str();
}
 
//--------------------------------------------------------------------------------------------------
int main()
{
Method1();
Method2();
Method3();
 
LARGE_INTEGER t0, t1;
QueryPerformanceCounter(&t0);
for (unsigned count = 0; count < NUM_ITERATIONS; ++count)
{
Method1();
}
QueryPerformanceCounter(&t1);
std::cout << "Method 1 :" << t1.QuadPart - t0.QuadPart << std::endl;
 
QueryPerformanceCounter(&t0);
for (unsigned count = 0; count < NUM_ITERATIONS; ++count)
{
Method2();
}
QueryPerformanceCounter(&t1);
std::cout << "Method 2 :" << t1.QuadPart - t0.QuadPart << std::endl;
 
QueryPerformanceCounter(&t0);
for (unsigned count = 0; count < NUM_ITERATIONS; ++count)
{
Method3();
}
QueryPerformanceCounter(&t1);
std::cout << "Method 3 :" << t1.QuadPart - t0.QuadPart << std::endl;
}
//--------------------------------------------------------------------------------------------------
 
V
--
I do not respond to top-posted replies, please don't ask
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 07 07:44PM

On Tue, 2015-03-03, Scott Lurndal wrote:
> bilsch <king621@comcast.net> writes:
...
 
>> error: range-based ???for??? loops are not allowed in C++98 mode
 
> man pages are your friend:
 
> bash$ man g++ | col -b | grep -i c++11
 
Yes, but with GCC you really need the info pages. Not my favorite
documentation format, but that's where the full compiler documentation
is, so you need to have it and be able to navigate it.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 14 05:47AM

On Fri, 2015-03-13, Christopher Pisz wrote:
>> I understand right?
 
>> I don't know this
 
> Tis true.
 
99% true. If you have a hacker mind (which you can have without being
an actual programmer) you can try to work around the obstacles and
using trial and error and, using all kinds of ugly tricks, accomplish
what you want.
 
It's nothing I can help with, but I wanted to point it out since
astro.del.cielo seems to show some trace of promise. Great things
sometimes start with someting absurd.
 
Linus Torvalds: "Hey, I have a PC with a MMU here. I could
theoretically write a Unix clone for it. I'd probably have to learn
C programming first ..."
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <myfirstname@osa.pri.ee>: Mar 14 01:28AM -0500

"astro.del.cielo" <vedi@lasignature.com> wrote in
> with my ipcam.
> I think the solution is to make a small program that invoke
> ZSP_SetImageColor
 
Yes, in order to invoke some function there must be a program that does
the invoking.
 
There are actually numerous existing programs which can load arbitrary
dll-s and call arbitrary functions in them. For example LabView, but I
think many script language interpretators can do this as well. You still
need to write something resembling a program, but not in C or C++.
 
Now if what you actully want is to attach to an already running program
and call a function in this running process, then this is already much
harder (but also doable in principle).
 
hth
Paavo
Richard Damon <Richard@Damon-Family.org>: Mar 07 08:28PM -0500

On 3/7/15 7:25 PM, JiiPee wrote:
> repeat all 5 functions 10 times for different types as they all were
> very similar. So wanted to make one template class and create different
> instances by changing the type.
 
But you don't need 5x10 functions. You have a "dummy" copy of each
function in AnimalBase (to give the error for using the wrong type), and
you over ride in each animal the type that matches the type of animal,
so dog<int> only needs to define speak(int). You need that second
definition anyways to define what it is supposed to do, so the only
"extra" code is the dummy versions in AnimalBase. You also need to
decide what speak(int) should do in something based on Animal<string>.
>> have the cast in the template. This seems to be what you are looking for.
 
>> The issue is that you can't overload on return type or make the static
>> return type of a function determined at run time.
 
I will say that something seems a bit strange to have a collection of
objects with this type of differing APIs.
JiiPee <no@notvalid.com>: Mar 07 08:10PM

On 07/03/2015 19:31, Stefan Ram wrote:
> at compile time or a run time. Then, you can use
> templates for compile-time polymorphism; but you
> can't use them for run-time polymorphism.
 
yes true, I guess its kind of mix now... am doing both. without
templates there is more code and I have to copy a lot of code, so I kind
of prefer template approach. But I just dont like that casting :).
 
But I guess I am trying to take best of the both worlds ...
JiiPee <no@notvalid.com>: Mar 08 01:48PM

On 08/03/2015 10:33, Öö Tiib wrote:
> types of unrelated hierarchies. The technique is like adding narrow
> virtual interface from outside. It is complex technique and so I have
> seen people misunderstanding and misusing it and screwing all up.
 
Thanks, I think I chose this Visitor thing. in the other post I describe
how it work with my code quite well...
JiiPee <no@notvalid.com>: Mar 08 12:55PM

On 08/03/2015 10:33, Öö Tiib wrote:
> get knowledge of the full type through base class pointer and for that
> you need either double dispatch (visitor pattern) or RTTI
> ('dynamic_cast'/'typeid').
 
but how would you implement the visitor (the idea)? I tried:
 
class AnimalBase
{
..
virtual void accept(Farm* farm) = 0;
}
;;;;
template <typename T>
void Dog<T>::accept(Farm* farm)
{
farm->visit(this);
}
 
then :
farm.getAnimal(0)->accept(&farm);
 
But how does this help to return the Dog? I dont understand how will
that return Dog. Is this what you meant? Where would the dog be returned?
 
 
 
 
Stuart Redmann <DerTopper@web.de>: Mar 06 04:28PM

JiiPee wrote:
 
[snip]
 
> private:
> float f;
> };
 
Actually, that's a Really Good Idea (TM). That's what Ada95 has in
advantage of C++, you can create real number types quite easily. Lot's of
bugs would never have occurred had the program been written in Ada, like
the infamous bug in libTIFF, where the number of bytes to be copied from a
section was computed as int variable. Since the size of the section is
stored in the TIFF file including the 4 bytes of the section header, the
int variable had to be decreased by 4. If a malicious attacker created a
TIFF file, where the section size was stored with a value <4, the int
variable became negative, so that it got interpreted as UINT_MAX. LibTIFF
would then try to copy that many bytes from the TIFF file, which could lead
to stack corruption and privilege escalation.
 
This would never have happened in an Ada95 program, because the data type
"Integer" is always the last choice for a variable. Unfortunately, C++ did
not offer an equally easy way to define numeric data types (typedef is
insufficient there) :-(
 
Another thing is the source of many (avoidable) errors is implicit type
conversions. More than one time I shot myself in the foot by passing
inadvertently a float into a parameter that should actually be a bool. That
passes compilation totally unnotized. Had I tried to pass a Float for a
Bool, my folly would have been recognized on the spot.
 
I know that it is easily possible to create a matching type system in C++,
but unfortunately the C++ "mindset" has already been poisoned with the
wide-spread usage of the native data types like int and float.
 
Just my 2cents.
Stuart
 
PS: Please don't mistake me for a C++ hater. I love it heartily. I just
wish that it wouldn't spring so many traps.
"Lőrinczy Zsigmond" <zsiga@nospam.for.me>: Mar 11 05:22PM +0100

In CGI, the POST-data comes from the standard input,
so simply use fgets/fread/etc on standard input.
Christopher Pisz <nospam@notanaddress.com>: Mar 13 06:30PM -0500

On 3/13/2015 6:15 PM, Melzzzzz wrote:
> http://tech.co/highest-paying-programming-languages-2015-03
 
Well, I need a raise I think :P
 
 
 
--
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
---
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)