473,322 Members | 1,314 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

type conversion

frs
See example below: Why does the output of 'a' work and the output of
'b' fails to compile? Is there a way to write class 'something' so that
'b' converts correctly by default? (include iostream, string, use
namespace std)
template <typename T>
struct something {
T x;
operator T();
};

int
main(int, char**)
{
something<int> a;
something<string> b;

a.x = 4711;
b.x = "hello world!";

cout << a << endl; // compiles fine!
cout << b << endl; // operator<< ... no match, compile fails!
}
compiler = gcc 3.3.5

Thanks for any Help.

Frank

Sep 3 '05 #1
16 2951
frs wrote:
See example below: Why does the output of 'a' work and the output of
'b' fails to compile? Is there a way to write class 'something' so that
'b' converts correctly by default? (include iostream, string, use
namespace std)
template <typename T>
struct something {
T x;
operator T();
};

int
main(int, char**)
{
something<int> a;
something<string> b;

a.x = 4711;
b.x = "hello world!";

cout << a << endl; // compiles fine!
cout << b << endl; // operator<< ... no match, compile fails!
}
compiler = gcc 3.3.5

Thanks for any Help.

Frank


It's probably got something to do with the fact that string itself is a
template.

For instance the following does compile

template <typename T>
struct something {
T x;
operator T();
};

struct S
{
};

ostream& operator<<(ostream&, const S&);

int main(int, char**)
{
something<int> a;
something<S> b;

a.x = 4711;
b.x = S();

cout << a << endl; // compiles fine!
cout << b << endl; // compiles fine!
}

I don't know the complete answer to your question but really my advice
would be to stay away from this stuff. I think even BS said stay away
from the obscure corners of the language.

John
Sep 3 '05 #2

"John Harrison" <jo*************@hotmail.com> wrote in message
news:TJ**************@newsfe7-win.ntli.net...
frs wrote:
See example below: Why does the output of 'a' work and the output of
'b' fails to compile? Is there a way to write class 'something' so that
'b' converts correctly by default? (include iostream, string, use
namespace std)
template <typename T>
struct something {
T x;
operator T();
};

int
main(int, char**)
{
something<int> a;
something<string> b;

a.x = 4711;
b.x = "hello world!";

cout << a << endl; // compiles fine!
cout << b << endl; // operator<< ... no match, compile fails!
}
compiler = gcc 3.3.5

Thanks for any Help.

Frank


It's probably got something to do with the fact that string itself is a
template.

For instance the following does compile

template <typename T>
struct something {
T x;
operator T();
};

struct S
{
};

ostream& operator<<(ostream&, const S&);

int main(int, char**)
{
something<int> a;
something<S> b;

a.x = 4711;
b.x = S();

cout << a << endl; // compiles fine!
cout << b << endl; // compiles fine!
}

I don't know the complete answer to your question but really my advice
would be to stay away from this stuff. I think even BS said stay away from
the obscure corners of the language.

John


Had that been the case then the line

something<string> b;

would have failed to compile.

One possibility is that the string used wasn't std::string and doesn't
provide output operation with streams.

Ben
Sep 3 '05 #3
hmm, it really didn't compile with std::string...I can't figure out what's
the cause...

Anyway the following will do what the OP might want to do:

template <typename T>
struct something
{
T x;
};

template <typename OStreamT, typename T>
OStreamT& operator << (
OStreamT& os, const something<T>& o)
{
return os << o.x;
}

int main(void)
{
something<int> a;
something<std::string> b;

a.x = 4711;
b.x = "hello world!";

std::cout << a << std::endl;
std::cout << b << std::endl;
}

ben
Sep 3 '05 #4
benben wrote:
"John Harrison" <jo*************@hotmail.com> wrote in message
news:TJ**************@newsfe7-win.ntli.net...
frs wrote:
See example below: Why does the output of 'a' work and the output of
'b' fails to compile? Is there a way to write class 'something' so that
'b' converts correctly by default? (include iostream, string, use
namespace std)
template <typename T>
struct something {
T x;
operator T();
};

int
main(int, char**)
{
something<int> a;
something<string> b;

a.x = 4711;
b.x = "hello world!";

cout << a << endl; // compiles fine!
cout << b << endl; // operator<< ... no match, compile fails!
}
compiler = gcc 3.3.5

Thanks for any Help.

Frank


It's probably got something to do with the fact that string itself is a
template.

For instance the following does compile

template <typename T>
struct something {
T x;
operator T();
};

struct S
{
};

ostream& operator<<(ostream&, const S&);

int main(int, char**)
{
something<int> a;
something<S> b;

a.x = 4711;
b.x = S();

cout << a << endl; // compiles fine!
cout << b << endl; // compiles fine!
}

I don't know the complete answer to your question but really my advice
would be to stay away from this stuff. I think even BS said stay away from
the obscure corners of the language.

John

Had that been the case then the line

something<string> b;

would have failed to compile.


Huh? That's a completely different situation.

John
Sep 3 '05 #5
benben wrote:
hmm, it really didn't compile with std::string...I can't figure out what's
the cause...


I don't know the reason either, what I do know is that the rules
governing this kind of thing are extremely complex (try reading the C++
standard) and often have non-intuitive effects. That is why the advice
is to stay away from obscure corners of the language.

John
Sep 3 '05 #6
> I don't know the reason either, what I do know is that the rules governing
this kind of thing are extremely complex (try reading the C++ standard)
and often have non-intuitive effects. That is why the advice is to stay
away from obscure corners of the language.

John


You are probably right on that the problem may originate from that fact that
string in itself is an instantiation of a class template because of the need
to instantiate a copy of the overloaded operator << function. I played
around with the code...like the one below:

#include <iostream>
#include <string>

template <typename T>
struct something
{
T x;
operator T(){return x;}
};

template <typename T>
class some_curious_stuff{};

template <typename T, typename OS>
OS& operator << (OS& os, const some_curious_stuff<T>&)
{
return os << "curious stuff";
}

// explicitly instantiate a copy of operator <<
template std::ostream& operator <<(std::ostream&, const
some_curious_stuff<int>&);

/*
Commented out operator overloading below:
if I uncomment the code below and comment out the explicit
instantiation the code gets compiled...
*/
//
//std::ostream& operator << (std::ostream& os, const
some_curious_stuff<int>&)
//{
// return os << "curious int stuff";
//}

int main(void)
{
some_curious_stuff<int> a;
std::cout << a;

something<some_curious_stuff<int> > b;
std::cout << b; // Still ERROR
}
My impression is the explicitly instantiated operator << is not
overloaded....somehow...

Ben
Sep 3 '05 #7

frs wrote:
See example below: Why does the output of 'a' work and the output of
'b' fails to compile? Is there a way to write class 'something' so that
'b' converts correctly by default? (include iostream, string, use
namespace std)
template <typename T>
struct something {
T x;
operator T();
};

int
main(int, char**)
{
something<int> a;
something<string> b;

a.x = 4711;
b.x = "hello world!";

cout << a << endl; // compiles fine!
cout << b << endl; // operator<< ... no match, compile fails!
}
compiler = gcc 3.3.5

Thanks for any Help.

Frank


user-defined conversion operators are not considered when the compiler
tries to deduce template arguments for the operator<< call. you could:

(1) provide operator<< and operator>> for your something class.

(2) derive from T instead of having a T member:

template<typename T>
struct something : T {};

then provide template specializations for primitive types, that perhaps
use composition like your original solution. This is definitely the
more questionable solution.

Sep 3 '05 #8
I think the problem is due to the fact that your are using templates
and overloading at the same time when you insert b into cout.

When you insert 'a' into cout you are calling a member function of cout
(although it is a template all the instantation can happen based on the
class which is obviously basic_ostream<char>).

template <typename T>
basic_ostream<T>&
baisc_ostream<T>::operator<<(int value);

All the compiler has to do here is realize that an implict cast to int
is possible and that one of the member functions of baisc_ostream takes
int.

When you try to insert 'b' you are calling a template function:

template < typename charT >
basic_ostream< charT >&
operator << ( basic_ostream < charT >& is,
basic_string< charT > )

In order for this function to be called two things would need to happen
1. the compiler would need to realize that an implicit conversion to
basic_string<char> is possible.
2. The template would need to be instantated for basic_string<char>

This doesn't happen because template resolution happens before the
compiler starts looking for implicit casts. This means that the
function for inserting basic_string<T> is never considered and you get
an error message saying an appropiate operator << cannot be found.

I hope this makes sense (and is correct).

Sep 3 '05 #9
frs
Thanks,

I think you hit it straight to the point.

Frank.

Sep 3 '05 #10
> user-defined conversion operators are not considered when the compiler
tries to deduce template arguments for the operator<< call. you could:

(1) provide operator<< and operator>> for your something class.

(2) derive from T instead of having a T member:

template<typename T>
struct something : T {};

then provide template specializations for primitive types, that perhaps
use composition like your original solution. This is definitely the
more questionable solution.


Then how do you explain that cout << a works where a is of type
something<int>?

Ben
Sep 4 '05 #11

"andy" <an********@runbox.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...
I think the problem is due to the fact that your are using templates
and overloading at the same time when you insert b into cout.

When you insert 'a' into cout you are calling a member function of cout
(although it is a template all the instantation can happen based on the
class which is obviously basic_ostream<char>).

template <typename T>
basic_ostream<T>&
baisc_ostream<T>::operator<<(int value);

All the compiler has to do here is realize that an implict cast to int
is possible and that one of the member functions of baisc_ostream takes
int.

When you try to insert 'b' you are calling a template function:

template < typename charT >
basic_ostream< charT >&
operator << ( basic_ostream < charT >& is,
basic_string< charT > )

In order for this function to be called two things would need to happen
1. the compiler would need to realize that an implicit conversion to
basic_string<char> is possible.
2. The template would need to be instantated for basic_string<char>

This doesn't happen because template resolution happens before the
compiler starts looking for implicit casts. This means that the
function for inserting basic_string<T> is never considered and you get
an error message saying an appropiate operator << cannot be found.

I hope this makes sense (and is correct).


This certainly makes sense! Thanks Andy!

Ben
Sep 4 '05 #12

andy wrote:
I think the problem is due to the fact that your are using templates
and overloading at the same time when you insert b into cout.

When you insert 'a' into cout you are calling a member function of cout
(although it is a template all the instantation can happen based on the
class which is obviously basic_ostream<char>).

template <typename T>
basic_ostream<T>&
baisc_ostream<T>::operator<<(int value);

All the compiler has to do here is realize that an implict cast to int
is possible and that one of the member functions of baisc_ostream takes
int.

When you try to insert 'b' you are calling a template function:

template < typename charT >
basic_ostream< charT >&
operator << ( basic_ostream < charT >& is,
basic_string< charT > )

In order for this function to be called two things would need to happen
1. the compiler would need to realize that an implicit conversion to
basic_string<char> is possible.
2. The template would need to be instantated for basic_string<char>

This doesn't happen because template resolution happens before the
compiler starts looking for implicit casts. This means that the
function for inserting basic_string<T> is never considered and you get
an error message saying an appropiate operator << cannot be found.

I hope this makes sense (and is correct).


No, the templates are irrelevant. The actual explanation for why a
something<int> object works with ostream's << operator while a
something<std::string> does not, is far more simple.

The reason is that the compiler will apply at most one user-defined
conversion when looking for a function declaration to match a function
call in the source code. Passing a something<std::string> object to
ostream's << operator requires at least two conversions: the first to
convert the something<std::string> object to a std::string and a second
to convert the std::string to some other type for which ostream has
defined the << operator.

Were ostream to define the << operator for a std::string type, then
only one user-defined conversion would be needed in this case. And in
fact ostream defines the << operator for the type int - which explains
why you can call it with a something<int> object.

Greg

Sep 4 '05 #13
Greg wrote:
andy wrote:
I think the problem is due to the fact that your are using templates
and overloading at the same time when you insert b into cout.

When you insert 'a' into cout you are calling a member function of cout
(although it is a template all the instantation can happen based on the
class which is obviously basic_ostream<char>).

template <typename T>
basic_ostream<T>&
baisc_ostream<T>::operator<<(int value);

All the compiler has to do here is realize that an implict cast to int
is possible and that one of the member functions of baisc_ostream takes
int.

When you try to insert 'b' you are calling a template function:

template < typename charT >
basic_ostream< charT >&
operator << ( basic_ostream < charT >& is,
basic_string< charT > )

In order for this function to be called two things would need to happen
1. the compiler would need to realize that an implicit conversion to
basic_string<char> is possible.
2. The template would need to be instantated for basic_string<char>

This doesn't happen because template resolution happens before the
compiler starts looking for implicit casts. This means that the
function for inserting basic_string<T> is never considered and you get
an error message saying an appropiate operator << cannot be found.

I hope this makes sense (and is correct).

No, the templates are irrelevant. The actual explanation for why a
something<int> object works with ostream's << operator while a
something<std::string> does not, is far more simple.

The reason is that the compiler will apply at most one user-defined
conversion when looking for a function declaration to match a function
call in the source code. Passing a something<std::string> object to
ostream's << operator requires at least two conversions: the first to
convert the something<std::string> object to a std::string and a second
to convert the std::string to some other type for which ostream has
defined the << operator.

Were ostream to define the << operator for a std::string type, then
only one user-defined conversion would be needed in this case. And in
fact ostream defines the << operator for the type int - which explains
why you can call it with a something<int> object.

Greg


Sorry but there is an overload of the << operator defined for ostream
and string.

john
Sep 4 '05 #14
> Sorry but there is an overload of the << operator defined for ostream
and string.

john


Let's see whether such a operator exists in the Standard Library. Below
is the list of operator << overloads that a conforming C++ Standard
Library must implement for a std::ostream:

// as member functions:
ostream& operator<< (bool& val );
ostream& operator<< (short& val );
ostream& operator<< (unsigned short& val );
ostream& operator<< (int& val );
ostream& operator<< (unsigned int& val );
ostream& operator<< (long& val );
ostream& operator<< (unsigned long& val );
ostream& operator<< (float& val );
ostream& operator<< (double& val );
ostream& operator<< (long double& val );
ostream& operator<< (void*& val );
ostream& operator<< (streambuf& sb );
ostream& operator<< (ostream& ( *pf )(ostream&));
ostream& operator<< (ios& ( *pf )(ios&));
ostream& operator<< (ios_base& ( *pf )(ios_base&));

// as external functions:
ostream& operator<< (ostream& os, char ch );
ostream& operator<< (ostream& os, signed char ch );
ostream& operator<< (ostream& os, unsigned char ch );
ostream& operator<< (ostream& os, const char* str );
ostream& operator<< (ostream& os, const signed char* str );
ostream& operator<< (ostream& os, const unsigned char* str );

Source:
http://www.cplusplus.com/ref/iostrea...ratorltlt.html.

As I explained in my earlier post, the fact that the Standard Library
does not define such an operator means that the compiler would have to
perform two user-defined conversions to find a matching function to
compile the code in question - one more than the Standard allows.

Of course, there is nothing stopping anyone from writing the "missing"
overloaded operator << to verify this fact:

std::ostream&
operator<<( std::ostream& lhs, const std::string& rhs )
{
lhs.write( rhs.c_str(), rhs.length());

return lhs;
}

As expected, adding this function to the program does fix the compiler
error because the compiler now needs to perform only one user-defined
conversion to find a matching function.

Greg

Sep 5 '05 #15
Greg wrote:
Sorry but there is an overload of the << operator defined for ostream
and string.

john

Let's see whether such a operator exists in the Standard Library. Below
is the list of operator << overloads that a conforming C++ Standard
Library must implement for a std::ostream:

// as member functions:
ostream& operator<< (bool& val );
ostream& operator<< (short& val );
ostream& operator<< (unsigned short& val );
ostream& operator<< (int& val );
ostream& operator<< (unsigned int& val );
ostream& operator<< (long& val );
ostream& operator<< (unsigned long& val );
ostream& operator<< (float& val );
ostream& operator<< (double& val );
ostream& operator<< (long double& val );
ostream& operator<< (void*& val );
ostream& operator<< (streambuf& sb );
ostream& operator<< (ostream& ( *pf )(ostream&));
ostream& operator<< (ios& ( *pf )(ios&));
ostream& operator<< (ios_base& ( *pf )(ios_base&));

// as external functions:
ostream& operator<< (ostream& os, char ch );
ostream& operator<< (ostream& os, signed char ch );
ostream& operator<< (ostream& os, unsigned char ch );
ostream& operator<< (ostream& os, const char* str );
ostream& operator<< (ostream& os, const signed char* str );
ostream& operator<< (ostream& os, const unsigned char* str );

Source:
http://www.cplusplus.com/ref/iostrea...ratorltlt.html.

As I explained in my earlier post, the fact that the Standard Library
does not define such an operator means that the compiler would have to
perform two user-defined conversions to find a matching function to
compile the code in question - one more than the Standard allows.

Of course, there is nothing stopping anyone from writing the "missing"
overloaded operator << to verify this fact:

std::ostream&
operator<<( std::ostream& lhs, const std::string& rhs )
{
lhs.write( rhs.c_str(), rhs.length());

return lhs;
}

As expected, adding this function to the program does fix the compiler
error because the compiler now needs to perform only one user-defined
conversion to find a matching function.

Greg


OK come on, use a little common sense. I think you have been mislead
because the operator<< for string is not part of the iostream library
which seem to be the only part of the STL that your reference covers.
Instad it can be found with the string class.

Try looking at the real standard section 21.3.7.9 where operator<< for
string is defined.

Or is you don't have the standard available try here

http://msdn.microsoft.com/library/de...ML/STRING2.asp

or here

http://www.sgi.com/tech/stl/basic_string.html

or here

http://www.dinkumware.com/manuals/re...operator%3C%3C

Andy's explanation was the correct one.

john
Sep 5 '05 #16
Greg wrote:
Sorry but there is an overload of the << operator defined for ostream
and string.

john
Let's see whether such a operator exists in the Standard Library. Below
is the list of operator << overloads that a conforming C++ Standard
Library must implement for a std::ostream:

// as member functions:
ostream& operator<< (bool& val );
ostream& operator<< (short& val );
ostream& operator<< (unsigned short& val );
ostream& operator<< (int& val );
ostream& operator<< (unsigned int& val );
ostream& operator<< (long& val );
ostream& operator<< (unsigned long& val );
ostream& operator<< (float& val );
ostream& operator<< (double& val );
ostream& operator<< (long double& val );
ostream& operator<< (void*& val );
ostream& operator<< (streambuf& sb );
ostream& operator<< (ostream& ( *pf )(ostream&));
ostream& operator<< (ios& ( *pf )(ios&));
ostream& operator<< (ios_base& ( *pf )(ios_base&));

// as external functions:
ostream& operator<< (ostream& os, char ch );
ostream& operator<< (ostream& os, signed char ch );
ostream& operator<< (ostream& os, unsigned char ch );
ostream& operator<< (ostream& os, const char* str );
ostream& operator<< (ostream& os, const signed char* str );
ostream& operator<< (ostream& os, const unsigned char* str );

Source:
http://www.cplusplus.com/ref/iostrea...ratorltlt.html.


The standard says the following:

1) Clause 27.2 declares that std::ostream is a typedef for

basic_ostream<char>

which stems from the template

basic_ostream< class CharT,
class traits=char_traits< CharT > >

2) By 21.2/2, std::string is a typedef for

basic_string<char>

which arises from

basic_string< class CharT,
class traits=char_traits<CharT>,
class Allocator=allocator<CharT> >

3) Clause 21.3.7/4-5 says that through the header <string> the following
template becomes visible:

template < class CharT, class traits, class Allocator >
basic_ostream< CharT, traits > &
operator<< ( basic_ostream< CharT, traits > & os,
const basic_string< CharT, traits, Allocator & str );
As I explained in my earlier post, the fact that the Standard Library
does not define such an operator means that the compiler would have to
perform two user-defined conversions to find a matching function to
compile the code in question - one more than the Standard allows.
I would like to ask which type it is that std::string is converted to,
according to your two-conversion theory, in a call like

std::string x = "hello world!\n";
std::cout << x;

Maybe, I am missing something, but I did not find a user-defined conversion
from std::string to anywhere specified by the standard.

Your explanation is bogus: according to the standard, there is a template
that provides the operator<< for piping std::string to std::ostream, but
there is no user-defined conversion from std::string to anything printable
in your list above.

Of course, there is nothing stopping anyone from writing the "missing"
overloaded operator << to verify this fact:

std::ostream&
operator<<( std::ostream& lhs, const std::string& rhs )
{
lhs.write( rhs.c_str(), rhs.length());

return lhs;
}

As expected, adding this function to the program does fix the compiler
error because the compiler now needs to perform only one user-defined
conversion to find a matching function.


This code actually does not provide something missing. It is a little more
subtle. The standard, as quoted above, provides for:

template < class CharT, class traits, class Allocator >
basic_ostream< CharT, traits > &
operator<< ( basic_ostream< CharT, traits > & os,
const basic_string< CharT, traits, Allocator & str );

Now, this does not match a call to

operator<<( std::ostream&, something<std::string> )

because of the rules of template deduction. The second parameter in

template < class CharT, class traits, class Allocator >
basic_ostream< CharT, traits > &
operator<< ( basic_ostream< CharT, traits > & os,
const basic_string< CharT, traits, Allocator & str );

is templated. Therefore *no* user-defined conversions will be considered
[14.8.2.1]

Your code provides a non-templated overloaded version that will match since
in non-templated function arguments, user-defined conversion kicks in.
Best

Kai-Uwe Bux
Sep 5 '05 #17

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Mark Oliver | last post by:
Hi, I want to put a type conversion in my class, but I don't want the conversion to be usable in a passed parameter because it makes no sense. class cData { string s; public cData(string s)...
7
by: Madhu Gopinathan | last post by:
Hi, I hope this is the right forum for this question. I am extending ICollection to create a Collection Type (say MyCollection) wherein I can control the types of objects being added to the...
27
by: Yuriy Solodkyy | last post by:
Hi VS 2005 beta 2 successfully compiles the following: using System; using System.Collections.Generic; using System.Text; namespace ConsoleApplication1 { class Program {
3
by: pgconnolly | last post by:
/* foreach does implicit type conversion on elements of a params argument or Generic.List. * This is not good. * Examples of evil follow... */ using System; // I love it when C# is strict...
16
by: Enekajmer | last post by:
Hi, 1 int main() 2 { 3 float a = 17.5; 4 printf("%d\n", a); 5 printf("%d\n", *(int *)&a); 6 return 0; 7 }
2
by: Martin v. Löwis | last post by:
I've been working on PEP 353 for some time now. Please comment, in particular if you are using 64-bit systems. Regards, Martin PEP: 353 Title: Using ssize_t as the index type Version:...
1
by: lovecreatesbeauty | last post by:
There is a warning/(error? I remember it is an error for line 10 on some compilers before. At least on g++, it is an error.) for line 10. I first read a similar example from `Expert C Programming...
669
by: Xah Lee | last post by:
in March, i posted a essay “What is Expressiveness in a Computer Language”, archived at: http://xahlee.org/perl-python/what_is_expresiveness.html I was informed then that there is a academic...
4
by: zaeminkr | last post by:
I got a good answer here I have still confusing part. I have two very simple classes class DRect { private : double x0, y0, x1, y1; public : DRect(double a, double b, double c, double d) :...
8
by: Smithers | last post by:
Are there any important differences between the following two ways to convert to a type?... where 'important differences' means something more profound than a simple syntax preference of the...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shćllîpôpď 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.