Monday, February 2, 2015

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

ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 12:01PM

>Is there any predefined function( not sizeof) in c++ that
>return the number of bytes on which is represented a decimal
>number.
 
No.
ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 06:03PM

> in a retina display with 5400 x 4800? Or even when considering the
> retina displays that will be available in 4 years with
> 10000 x 8000 ???
 
surface surface( COLOR_WHITE );
point start( 0.2, 0.2 );
point end( 0.8, 0.8 );
shape circle( SHAPE_CIRCLE, 0.001 );
pen pen( circle, COLOR_BLACK );
draw_line( surface, start, end, pen );
 
The resolution of the output device is an implementation
detail not visible in the source code.
 
(»0.001« will be scaled by the library. The width in pixels
on a low-resolution device might be
implementation-specified, but it will be about 1/1000th of
the width of the output surface on a high-resolution device.
»surface surface ( COLOR_WHITE)«, is short for »surface
surface( COLOR_WHITE, 0.0, 1.0, 0.0, 1.0 )«, which specifies
MIN_X, MAX_X, MIN_Y, and MAX_Y.)
ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 06:14PM

>and then dropped for a new technology as a failure. That's just the
>nature of everything we program up. Technology evolves and we get
>something new and better.
 
However, some interfaces manage to be kept. For example, we have
- according to TIOBE -:
 
Programming Language 1990 1995 2000 2005 2010 2015
C 1 2 1 1 2 1
C++ 2 1 2 3 3 4
 
That is, the interface »C« has managed to keep up with new
developments and is still on top in 2015, while »C++«, the
fad language of the 90s, slowly decays into oblivion.
ram@zedat.fu-berlin.de (Stefan Ram): Feb 02 06:46PM

>Yea, TIOBE has been discussed countless times. I trust what it says as
>much as a toothless hooker.
 
For something that is so untrustworthy, it's funny that its
results are very similar to other independent sources.
 
The Transparent Language Popularity Index
lang-index.sourceforge.net/ (most recent)
 
1 C 17.668% 15.868% 16.825%
2 Java 14.720% 15.450% 20.381%
3 Objective-C 8.230% 8.516% 9.221%
4 C++ 6.770% 7.544% 7.912%
 
TIOBE (2015-01)
 
1 1 C 16.703% -1.24%
2 2 Java 15.528% -1.00%
3 3 Objective-C 6.953% -4.14%
4 4 C++ 6.705% -0.86% 5 5
Juha Nieminen <nospam@thanks.invalid>: Feb 02 10:35AM

> Now C++ needs a standard user interface library.
 
The problem with a *standard* GUI library is that the standard evolves
very, very slowly. The standard is updated every 5 years or so. That's
an awfully long time in a rapidly evolving technological environemnt.
 
The vast majority of GUI libraries out there are constantly evolving.
With most of them not even a month goes by without a new version of
the library coming out.
 
Even when the GUI is an integral part of the language and/or the
environment where it's used (for example Apple's variant of
Objective-C and its UIKit library), it's usually continually
upgraded.
 
This is the main reason why the idea of a standard GUI library is
pretty unworkable for C++. It's actually better to leave it to
third-party libraries that are unbound by the strict admission
process of standardization. They can be upgraded at any time,
and mistakes can be corrected rapidly.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
jacob navia <jacob@spamsink.net>: Feb 02 06:40PM +0100

Le 02/02/2015 11:35, Juha Nieminen a écrit :
 
> The problem with a *standard* GUI library is that the standard evolves
> very, very slowly. The standard is updated every 5 years or so. That's
> an awfully long time in a rapidly evolving technological environemnt.
 
This is exactly the problem. Computer graphics is such a rapidly
evolving field that setting a fixed API for the whole language is
completely NONSENSE!
 
> The vast majority of GUI libraries out there are constantly evolving.
> With most of them not even a month goes by without a new version of
> the library coming out.
 
More than new versions that add some APIs is the problem of the
conceptual base for doing graphics changing. Even apparently simple
stuff like LineTo(x,y); can be quite difficult to do:
 
o Do you want dithering and pixel dithering using color? Or you want
no dithering, just black/white line?
 
o Do you want setting a MINIMUM width so that your line will be visible
in a retina display with 5400 x 4800? Or even when considering the
retina displays that will be available in 4 years with
10000 x 8000 ???
 
etc!
 
> environment where it's used (for example Apple's variant of
> Objective-C and its UIKit library), it's usually continually
> upgraded.
 
As far as I understood the proposal refers only to 2D drawing. But even
there (see above) there are problems!
 
> third-party libraries that are unbound by the strict admission
> process of standardization. They can be upgraded at any time,
> and mistakes can be corrected rapidly.
 
+1
 
jacob
Christopher Pisz <nospam@notanaddress.com>: Feb 02 12:02PM -0600

On 1/30/2015 10:38 PM, Stefan Ram wrote:
> read input from a user.
 
> We can draw with ASCII-Art for now, or output something like
> SVG or png.
 
Well, I guess I see it differently. I don't see anything used for years
and then dropped for a new technology as a failure. That's just the
nature of everything we program up. Technology evolves and we get
something new and better.
 
Graphics evolves faster and just like all the technologies mentioned, it
should be part of the "language" itself, it should be a standardized
library that you may or may not link with.
 
OpenGL was just that imo. Unfortunately, MS took measures to make it
difficult on Windows.
Christopher Pisz <nospam@notanaddress.com>: Feb 02 12:11PM -0600

On 2/2/2015 12:02 PM, Christopher Pisz wrote:
 
> OpenGL was just that imo. Unfortunately, MS took measures to make it
> difficult on Windows.
 
should be part of the "language" itself -> shouldn't be part of the
"language" itself.
 
Typo. Sorry.
Christopher Pisz <nospam@notanaddress.com>: Feb 02 12:37PM -0600

On 2/2/2015 12:14 PM, Stefan Ram wrote:
 
> That is, the interface »C« has managed to keep up with new
> developments and is still on top in 2015, while »C++«, the
> fad language of the 90s, slowly decays into oblivion.
 
Yea, TIOBE has been discussed countless times. I trust what it says as
much as a toothless hooker.
 
For a language that is "a fad language falling into oblivion" it sure is
ironic that I have never had to spend more than 4 hours searching for a
job to get employed using it, locally at that, with less than a 10
minute drive from home, and almost always with a salary increase of 15%
or more from the last employer, for the last 2 decades.
Christopher Pisz <nospam@notanaddress.com>: Feb 02 12:09PM -0600

On 1/31/2015 2:09 AM, Jorgen Grahn wrote:
> On Fri, 2015-01-30, Christopher Pisz wrote:
SNIP
> with a std::sprintf(), wrapped with a std::string. Or any of the
> other obvious solutions which don't require duplicating that logic
> manually.
 
Evidently, the OP wanted to print each byte seperately, rather than the
contents of a variable, but nothing is wrong with sprintf or
stringstream for the task if you set it up first.
 
The topic got sidetracked when this Rosario person posted numerous
horrible solutions, tried to fix the, and posted more horrible solutions.
ghada glissa <ghadaglissa@gmail.com>: Feb 02 03:39AM -0800

Dear all,
 
Is there any predefined function( not sizeof) in c++ that return the number of bytes on which is represented a decimal number.
 
exp:
 
56791 --> binary 1101110111010111 ---> represented on 2 bytes
56700911 --> binary 11011000010010111111101111 ----> represented on 4 bytes
 
Regards.
scott@slp53.sl.home (Scott Lurndal): Feb 02 03:06PM


>exp:
 
>56791 --> binary 1101110111010111 ---> represented on 2 bytes
>56700911 --> binary 11011000010010111111101111 ----> represented on 4 bytes
 
size_t bytes = (log2(56791) + 8)/8;
 
 
$ printf '%u\n' $(( (log2(56791) + 8)/8 ))
2
$ printf '%u\n' $(( (log2(56700911) + 8)/8 ))
4
$
 
scott
Vlad from Moscow <vlad.moscow@mail.ru>: Feb 02 08:54AM -0800

What about negative numbers?
 
On Monday, February 2, 2015 at 2:40:08 PM UTC+3, ghada glissa wrote:
Christopher Pisz <nospam@notanaddress.com>: Feb 02 11:55AM -0600

On 2/2/2015 5:39 AM, ghada glissa wrote:
 
> 56791 --> binary 1101110111010111 ---> represented on 2 bytes
> 56700911 --> binary 11011000010010111111101111 ----> represented on 4 bytes
 
> Regards.
 
So, to clarify your question, are you asking what is the theoretical
minimum number of bytes that could be used to represent a given floating
point number?
 
If that's the case, no, there is no standard function for that, that I
know of.
 
However, a double is a double regardless of what it contains at the
time. If you are on Window's it will always be 8 bytes. Float - 4, and
so on. sizeof tells you this.
DSF <notavalid@address.here>: Feb 01 11:04PM -0500

On Sun, 01 Feb 2015 16:47:26 -0600, Paavo Helde
>stage, not in linker stage).
>hth
>Paavo
 
The problem *IS* in the compile stage. The only reason it is a
linker error is that the compiler does not create an instance for
FAList<HashIndex>. As I stated before, I compiled this TU to
assembler and there is an instance of assembly code for every use of
FAList<CLASS> used in the file except for the class HashIndex.
 
In header:
 
class CopyDirectory
{
...
FAList<HashIndex> hindex;
...
};
 
In CPP:
 
void CopyDirectory::DoSomething(int something)
{
...
HashIndex hi;
...
hindex.Add(hi); // add object hi to list
...
}
 
When linked, hindex.Add(hi) produces an "unresolved external
FAList<HashIndex>::Add(const HashIndex&)" error because the template
class code for FAList<HashIndex> is never created.
 
Thanks,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
Ian Collins <ian-news@hotmail.com>: Feb 02 12:37PM +1300

Paul wrote:
> I am trying to rewrite text-handling code involving char* and const char* in terms of boost::scoped_array<char>
 
What's wrong with std::string?
 
--
Ian Collins
Paul <pepstein5@gmail.com>: Feb 01 04:59PM -0800

On Sunday, February 1, 2015 at 11:38:09 PM UTC, Ian Collins wrote:
> Paul wrote:
> > I am trying to rewrite text-handling code involving char* and const char* in terms of boost::scoped_array<char>
 
> What's wrong with std::string?
 
Thanks for your reply.
I'm trying to solve a problem from a boost book. (No, it's not homework for an academic course). Please don't give too much help.
 
The problem is below:
 
Optimize the following program by using an appropriate smart pointer.
 
#include <iostream>
#include <cstring>
 
char *get(const char *s)
{
int size = std::strlen(s);
char *text = new char[size + 1];
std::strncpy(text, s, size + 1);
return text;
}
 
void print(char *text)
{
std::cout << text << std::endl;
}
 
int main(int argc, char *argv[])
{
if (argc < 2)
{
std::cerr << argv[0] << " <data>" << std::endl;
return 1;
}
 
char *text = get(argv[1]);
print(text);
delete[] text;
}
"Öö Tiib" <ootiib@hot.ee>: Feb 01 03:39PM -0800

On Monday, 2 February 2015 00:59:48 UTC+2, JiiPee wrote:
 
> Again, I am talking about logic here. Yes, its possible the standard has
> not been written totally logically here... true, and that is another
> issue. But anyway, thats what I am discussing here.
 
Nothing is wrong with your logic so far. In some programming
languages (Javascript, Objective-C) you can override all methods
of base class and in others (C++, C#, Delphi) you can override only
functions that are marked as virtual.
 
> In a court of law so far there is no evidence that "override" belongs
> only to polynorphism :).
 
That logic I do not understand.
Modifying and extending behavior of a class *is* polymorphism.
JiiPee <no@notvalid.com>: Feb 01 11:43PM

On 01/02/2015 23:22, Paavo Helde wrote:
 
> For C++ standard, see http://lmgtfy.com/?q=latest+c%2B%2B+standard+download
 
> Cheers
> Paavo
 
how about at page 1053 where it says "309) Classes derived from
basic_streambuf can provide more efficient ways to implement xsgetn()
and xsputn() by **overriding**
these definitions from the base class."
 
My ** .... So seems like there is an example where they are talking
about overriding a base class non-virtual function in a derived class.
The header of xsputn () is (i think):
 
streamsize xsputn (const char_type* s, streamsize n);
 
so its not a virtual function.
JiiPee <no@notvalid.com>: Feb 01 11:49PM

On 01/02/2015 23:43, JiiPee wrote:
 
> streamsize xsputn (const char_type* s, streamsize n);
 
> so its not a virtual function.
 
heh, sorry I ll take this back... it is actually a virtual function :),
checked from the code (cplusplus site did not show this). Ok, I will
sleep night over and will think about this :) ...
"Öö Tiib" <ootiib@hot.ee>: Feb 01 03:50PM -0800

On Monday, 2 February 2015 01:44:04 UTC+2, JiiPee wrote:
> The header of xsputn () is (i think):
 
> streamsize xsputn (const char_type* s, streamsize n);
 
> so its not a virtual function.
 
You said you did download standard?
http://www.cplusplus.com/reference/streambuf/streambuf/xsgetn/
"protected virtual member function"
JiiPee <no@notvalid.com>: Feb 01 11:52PM

On 01/02/2015 23:22, Paavo Helde wrote:
 
> For C++ standard, see http://lmgtfy.com/?q=latest+c%2B%2B+standard+download
 
> Cheers
> Paavo
 
yes, I checked also.... ok then, I accept this as its never used on
non-virtual functions there.
JiiPee <no@notvalid.com>: Feb 01 11:53PM

On 01/02/2015 23:50, Öö Tiib wrote:
> You said you did download standard?
> http://www.cplusplus.com/reference/streambuf/streambuf/xsgetn/
> "protected virtual member function"
 
yes I just corrected it.... the site I referred did not mention that
JiiPee <no@notvalid.com>: Feb 01 11:58PM

On 01/02/2015 23:39, Öö Tiib wrote:
> languages (Javascript, Objective-C) you can override all methods
> of base class and in others (C++, C#, Delphi) you can override only
> functions that are marked as virtual.
 
ok, let it be like that then.
 
Some of those websites then are confusing by using override with
non-virtual functions. Maybe they are former Java programmers :)
 
>> only to polynorphism :).
> That logic I do not understand.
> Modifying and extending behavior of a class *is* polymorphism.
 
ok but now I have more evidence , because I checked the whole standard.
 
JiiPee <no@notvalid.com>: Feb 02 12:06AM

On 01/02/2015 23:22, Paavo Helde wrote:
 
> For C++ standard, see http://lmgtfy.com/?q=latest+c%2B%2B+standard+download
 
> Cheers
> Paavo
 
heh, that standand pdf seems to be pretty readable and
understandable.... maybe best to read it to learn C++ :). That way one
can be sure is learning the right things.
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)